Bot Recipes

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

With no annotations, the description carries the full behavioral burden and does real work: it discloses that this is a paid, non-idempotent flow requiring a human or wallet, that the immediate return is a payment link rather than the recipes, and that a redirect to the download follows payment. Remaining gaps (link expiration, failure modes) are minor.

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 tight sentences with no filler. The core deliverable (payment link for the full pack) is front-loaded, followed immediately by the human/wallet constraint and the post-payment outcome.

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?

With no output schema or annotations, the description must stand alone, and it explains what the call yields, the payment precondition, and what happens after payment. It is nearly sufficient for an agent to know what it will get back and that it must hand off to a human.

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 tool takes zero parameters, so there is no parameter semantics to document and the baseline is 4. The description correctly implies no inputs are needed.

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 concrete verb (Get) and resource (the $7 payment link for the full pack) with scope made explicit: all 263 recipes as one markdown and one JSON file. The 'full pack' framing implies contrast with the sibling tools that return individual recipes, but no sibling is named outright.

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 clear context for when this tool applies (obtaining the payment link for the complete bundle) and adds a decisive constraint: 'Payment needs a human or a wallet,' telling an agent it cannot complete the transaction autonomously. It stops short of naming when to prefer get_recipe or search_recipes instead.

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

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

With no annotations, the description carries the disclosure burden and does useful work by explaining that return content varies by recipe type: free samples yield full steps, others yield only a summary plus a paid unlock link. It omits read-only/auth guarantees and error behavior, but the output-shape disclosure is genuinely valuable context.

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 tight sentences with the core action front-loaded and the return-value nuance second. No filler, though it could be marginally tighter.

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?

With no output schema and no annotations, the description must cover returns, and it does explain the two return shapes and the monetization gate. It does not cover invalid-id handling or rate limits, but for a simple single-id lookup it is largely sufficient.

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?

Schema coverage is 0% and the sole parameter is documented only as a bare string. The description compensates by stating the id originates from search_recipes, which tells the agent where a valid value comes from. It adds real meaning over the schema, hence above the low-coverage baseline.

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 ('Get one recipe by id') and ties it to the pipeline by naming search_recipes as the id source, which separates it from that sibling. It does not explicitly distinguish itself from buy_pack or list_directory, so it falls short of a full 5.

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 phrase 'by id from search_recipes' implies the intended workflow: search first, then fetch a specific recipe. However, there is no explicit when-to-use/when-not guidance and no routing to alternatives like buy_pack when the full pack is wanted.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses data provenance ('seeded from the official MCP Registry, moderated'), which is useful context, but it does not state whether the operation is read-only, whether auth is required, rate limits, pagination, or return 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 one tight sentence with a parenthetical, front-loading the action and directory before listing the optional filters. Every part earns its place with no filler.

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?

With no annotations and no output schema, the description should explain return values, pagination, and operational behavior. It covers purpose and filter names but leaves these invocation-critical details unstated, so it is not complete enough for an agent to call confidently.

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?

Schema description coverage is 0%, so the description must compensate for the schema's lack of parameter documentation. It names all three filters and the kind enum values, but adds no meaning for 'query' or 'category' beyond their names, leaving the 0% coverage largely unaddressed.

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 gives a specific verb ('List') and resource ('MCP servers and bots in the botrecipe.com directory') with scope and provenance. It is clear what the tool does, but it does not explicitly differentiate itself from siblings like search_recipes, buy_pack, or get_recipe, so it falls short of a 5.

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?

It mentions optional filters but gives no guidance on when to use this tool versus alternatives or what prerequisites exist. There is no when-to-use, when-not-to-use, or sibling comparison, matching a score of 2 (no real guidance).

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

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

With no annotations, the description carries the full burden; it usefully discloses the corpus size, the nature of the records, and the returned fields (valuable given no output schema). It says nothing about the limit cap of 25, default result count, pagination, or whether matching is exact or fuzzy.

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 compact clauses, front-loaded with what is searched and followed by what comes back. No filler or repetition of the tool name.

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?

Listing the return fields partly compensates for the missing output schema, and the corpus description is helpful. But the undocumented limit parameter and unstated pagination/cap behavior leave gaps for a search tool an agent must call correctly on the first try.

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?

Schema description coverage is only 50% ('query' is documented as 'words to match'; 'limit' has no description at all). The description adds no parameter meaning — no matching semantics for query and no explanation of how limit affects results — so it fails to compensate for the coverage gap.

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 plus the exact corpus ('263 bot recipes') and what a recipe contains, so the agent knows the scope precisely. It does not name the sibling get_recipe or otherwise disambiguate searching from direct retrieval, which keeps it below a 5.

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?

Usage is implied rather than stated: an agent can infer you search when you don't have an id, but there is no explicit when-to-use, when-not, or pointer to get_recipe for fetching a full recipe. No exclusions or prerequisites are given.

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