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

Beyond the readOnly/idempotent/destructive hints, the description adds important behavioral context: it is deterministic, free, calls no model, costs nothing, never runs out of quota, and can return multi-step recipes. These traits are not in the annotations and materially affect invocation expectations.

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 core action, then adds the multi-step recipe behavior, then the free/deterministic guarantee, and ends with a clear 'call first' directive. Every sentence adds value; no fluff or repetition.

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?

For a simple one-parameter tool with an output schema available, the description covers the purpose, usage trigger, behavioral guarantees, and special capabilities. Nothing important is missing for an agent to decide when and how to invoke it.

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 already fully documents the single 'task' parameter with a clear description and examples. The description adds useful semantic context ('plain language (any language)') and reinforces the purpose, but the schema already carries most of the burden.

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 that the tool maps a plain-language task to the exact tools on this server that can do it, with ready-to-run examples and multi-step recipes. This is a distinct meta/routing function and clearly distinguishes it from sibling tools like build_app or project_status.

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?

Explicitly instructs 'Call this FIRST when you are not sure what this server offers,' and frames it as an alternative to 'reading the whole catalogue and guessing.' This gives the agent a clear decision rule and when-to-use guidance.

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