bind_field_parameter

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral burden and does a strong job: it discloses the active=true dynamic-projection marker, the prototypeQuery Select swap, and the dependency on add_field_parameter. It does not cover reversibility, permissions, or return values, but for this technical tool the core mechanics are well explained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose and distinguishes the tool early. It is dense and jargon-heavy, but every sentence earns its place by explaining the mechanism, dependency, and defaults. Slightly long, but appropriate for this complex operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high complexity, no annotations, and no output schema, the description provides substantial context: side effects, ordering, defaults, and relationship to add_field_parameter. It is largely complete for an agent to select and invoke correctly, with minor omissions around session-id semantics and failure scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 83% of parameters with descriptions, and the tool description adds extra meaning for role (default Y/Values), parameterColumn (defaults to table name), and parameterTable (comes from add_field_parameter). This goes beyond the raw schema, though reportSessionId remains without any explanatory context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Bind') and resource ('FIELD PARAMETER to a visual'), states the outcome ('actually swaps fields when opened in Desktop'), and explicitly distinguishes itself from the model-side add_field_parameter. This makes the tool's purpose immediately clear and differentiates it from its sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly names the alternative add_field_parameter, explains the division of labor ('model-side pieces... come from add_field_parameter'), and instructs to run that tool first. It also provides the role default ('Y, else Values'), giving clear when and how to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.