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

Goes well beyond the annotations by disclosing the pagination contract ('Follow next_cursor until null, even for an empty page: the cursor tracks scanned revisions') and the return shape. Annotations already cover read-only/idempotent/no-destructive, and the description adds cost ('Costs nothing, writes nothing and starts no run') and revision semantics for current_only.

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?

Front-loaded with purpose, then pagination, then cost, then next step — no filler sentences. The 'Costs nothing, writes nothing and starts no run' clause partly restates the readOnly/idempotent annotations, which is the only mild redundancy in an otherwise dense passage.

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?

There is no output schema, so the description supplies the return shape ({recipes: [...], next_cursor}) and the exact loop termination rule. Combined with the explicit next-step tool, an agent has everything needed to call and consume this tool correctly.

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?

With 0% schema description coverage the description carries the burden and does so for three of four params: table_id (source and purpose), current_only (default true, false includes older revisions), and cursor (next_cursor). limit is never mentioned, though its schema bounds (1-20) make it fairly self-evident.

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?

States a specific verb and resource ('Lists immutable recipe coordinates in this workspace') plus scope ('optionally for one table_id'). It is clearly distinguishable from get_recipe, explain_recipe, and register_recipe, which the description references or implies.

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?

Gives explicit routing: use get_my_dataset to obtain a table_id, and 'Next: get_recipe with a returned recipe_id to inspect the actual document before editing it.' The when-to-use and the alternative are both named, not left to inference.

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