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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds valuable behavior not in annotations: it is deterministic, calls no model, costs nothing, and never runs out of quota. It also explains that output includes ready-to-run example calls and multi-step recipes, giving a clear picture of 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 three sentences, front-loaded with the main function, then adding behavioral details and usage guidance. Every sentence adds unique value; there is no redundancy or filler. It is appropriately sized for the tool's simplicity.

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 tool is simple with one parameter, the schema covers 100% of parameters, and an output schema exists. The description covers purpose, usage, behavior, and output characteristics. It even addresses cost and determinism. There are no significant gaps for an agent to understand when and how to invoke this tool.

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 describes the 'task' parameter with an example, but the description adds important semantic detail: the task can be in any natural language, and it clarifies the expected input format ('Describe a task in plain language'). It also implies that the parameter drives both tool selection and recipe generation, going beyond the schema's basic description.

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: given a task in plain language, it returns the exact tools on this server that perform it, with example calls. It also distinguishes itself from sibling data-processing tools by being a meta-tool for tool discovery, and it contrasts with browsing the catalogue and guessing.

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 guidance to call this tool first when unsure what the server offers, and frames it as an alternative to reading the catalogue and guessing. It also notes when multi-step recipes are returned. However, it does not explicitly state when not to use it (e.g., if the user already knows the exact tool), which would make it a 5.

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