Introduce Dynamic Tools

Problem/Motivation

Choosing the right granularity for base tools is hard. If tools are too generic (e.g. field_set_value with a single value argument), definitions are loose(value is file?, string?, address?, email?), models hallucinate, planning is brittle, and validation only happens at runtime. If tools are too specific (e.g. per-field-instance field_set_value:node:article:field_description or per‑field‑type field_set_value:text_long), tools are reliable but we quickly exceed LLM/MCP tool limits and overwhelm selection UIs (Agents, ECA, etc.).

We need a design that keeps the tool surface area small while still giving the model highly structured, deterministic, self‑describing inputs per concrete use case.

• MCP constraints: ~40 exposed tools, prompt‑injection surface, need for reliable/typed inputs.
• AI Agents: too many tools overwhelm UI ; short‑term memory/token limits; reliability vs. count trade‑off.
• ECA: too many tools overwhelm UI; too few generic tools → unintuitive forms.

Goals

• Keep the public tool list small and comprehensible.
• Provide deterministic, strongly‑typed inputs tailored to the chosen context.
• Offer consistent tools across MCP, Agents, and ECA.
• Provide path forward for MCP, but not necessarily full solution(separate issue)

Proposed resolution

More to come.