list_recipes

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

With no annotations provided, the description carries the behavioral disclosure burden. It conveys that the tool is a read-only listing operation (implicitly safe, non-destructive) and frames recipes as 'verified parsers' with a speed/confidence advantage. It doesn't explicitly state return format, but the presence of an output schema partially covers return-value disclosure. For a simple list op with no annotations, this is solid.

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?

Two sentences deliver complete value with zero waste. The first sentence states the purpose with concrete examples, and the second provides actionable usage guidance that ties into a sibling tool (extract). Every clause earns its place; no filler 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?

Given the tool is parameterless with a clean purpose and an output schema present, the description is complete. It explains what the tool returns (registered extraction recipes) and how to use it in the workflow (before extract with manual schema). The presence of an output schema relieves the description from detailing return structure. Nothing meaningful is missing.

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?

This tool has 0 parameters, so per the rubric the baseline is 4. There is no schema info to add value beyond, and the tool genuinely doesn't need parameters. The description focuses entirely on output semantics rather than inputs, which is appropriate for a parameterless list operation.

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 states the specific purpose: 'List every registered extraction recipe (platform-specific, verified parsers — e.g. Greenhouse, Lever, Ashby job boards).' The verb 'List' clearly identifies the action and the resource (extraction recipes) is precisely scoped. It distinguishes from siblings by naming the resource type and examples, making it unambiguous what this tool returns.

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 usage guidance: 'Check this before calling `extract` with a manual schema: a matching recipe is faster and higher-confidence than LLM extraction.' This tells the agent exactly when to use this tool (before extract) and explains the rationale, effectively framing it as a prerequisite decision step.

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