infer_recipes

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

With no annotations, the description carries the full burden. It discloses the output form ('ready-to-paste loader code'), target semantics ('all' vs single flavor), and output size ('small'), which are the key behavioral traits of this code generator. It could add prerequisites (e.g., source must exist), but it does not hide side effects or mislead.

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?

Three sentences, each provides distinct information: the main action, target usage/behavior, and output size. No filler, repetition, or unnecessary detail. The structure front-loads the core purpose and keeps the details compact.

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 small code-generation tool with an output schema, the description covers the main action, language flavors, target behavior, and output footprint. It does not explicitly explain how to obtain source_id (e.g., via list_sources), but that is a common cross-tool dependency and does not leave a critical gap for this complexity level.

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 has no parameter descriptions, so the description must compensate. It adds real value for target by explaining the 'all' behavior and the accepted single values. source_id is only implied as 'the source' from the opening sentence, but the parameter name and overall context make it understandable.

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?

Description opens with a specific verb ('Generate') and resource ('ready-to-paste loader code'), enumerates four language flavors (Python/DuckDB, Polars, Pandas, SQL), and differentiates itself from siblings like load_source by noting it lets users reproduce loading without the MCP. This is a precise action on a clear deliverable.

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 states the primary use case ('reproduce loading without the MCP') and explains how to select flavors with target. It does not explicitly name alternative tools or state exclusions, but the context clearly signals that this is for generating external code rather than performing an in-session load.

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