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

Annotations provide readOnlyHint=false, openWorldHint=false, destructiveHint=false, but the description goes well beyond these by explaining that the tool 'records a future improvement and does not change the current call.' It also tells the agent to mention that it suggested the improvement, making the side effect (recording) transparent. This is consistent with annotations and adds valuable context about non-mutating behavior.

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 a single dense paragraph but is well-structured and front-loaded with the core purpose. Every sentence provides necessary instruction, from when to use it to what to avoid and how to mention the suggestion. While it is longer than minimal, the length is justified by the amount of critical operational guidance it conveys.

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?

The description is complete for an agent to call this tool correctly. It covers the trigger condition, alternative tool routing (ReportProblem), constraints on scope (no new tools, no duplicates), data privacy (redaction), and expected interaction flow (answer user first, mention the suggestion). Since there is no output schema, the description appropriately covers the behavioral contract without needing to explain return values.

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?

Schema description coverage is 100%, so all parameters are documented. The description adds extra semantic guidance beyond the schema: it tells the agent to redact user-provided values in the 'arguments' field, to avoid placeholder-only text in 'limitation' and 'suggestedChange', and to reference the existing tool called. This enhances parameter usability, earning a score above the baseline of 3.

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 clearly states the tool's purpose: to suggest a small actionable contract improvement to an existing Equibles tool that was actually called and worked as documented but lacked an operation, filter, parameter, or output option. It distinguishes itself from ReportProblem explicitly ('Use ReportProblem for wrong data') and from other siblings by its focus on improvement suggestions for existing tools.

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 gives explicit when-to-use (when a tool worked but lacked something) and when-not-to-use guidance (do not request new tools, do not duplicate existing options, do not report non-Equibles ideas). It also directs the agent to answer the user first and provides instructions on how to present the suggestion (describe the call, not the person, redact private values, mention briefly that it was suggested).

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