test_parse_recipe_url

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

No annotations are provided, so the description carries the full burden and delivers nothing: no statement of whether the scrape persists a recipe, whether auth is required, what the response contains, or whether useOpenAI triggers an external call. The 'create/add recipe' keywords actively suggest a write side effect that the endpoint name ('test-scrape-url') does not clearly support.

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 first two fragments are compact and front-loaded, but the trailing keyword list is pure SEO filler that repeats 'recipe', 'create', 'post' and near-duplicate phrases, adding noise rather than information.

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, no output schema, 0% schema description coverage, and a misleading keyword block, the description leaves an agent without enough information to call this tool correctly or safely — especially given a near-identical sibling it must be chosen over.

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% for the single nested body parameter, and the description only loosely hints at a URL via 'test scrape url'. It never mentions the useOpenAI boolean, nor the nested body shape or the required 'url' field, 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?

The description restates the tool name ('Test Parse Recipe Url') and adds only 'Recipe: CRUD. Test recipe.', which is vague and largely tautological; the useful signal comes from the embedded endpoint path '[POST /api/recipes/test-scrape-url]'. Worse, the keyword block claims 'create recipe, add recipe, new recipe, write recipe', which mischaracterizes a test-scrape endpoint as a recipe-creation tool. An agent would struggle to distinguish this from parse_recipe_url.

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?

No guidance whatsoever on when to use this versus the obvious siblings parse_recipe_url and parse_recipe_url_bulk, both of which appear in the sibling list. The word 'test' hints at a non-production/diagnostic role but the description never states that, nor any precondition or exclusion.

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