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

Annotations already declare readOnlyHint=true, and the description adds useful behavior beyond that: each recipe contains a scene plus verified React Native Reanimated code, and the tool returns slugs for get_recipe. This gives an agent meaningful expectations about the tool's output and content, though it doesn't cover edge cases like empty results or search matching semantics.

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 concise: two sentences, front-loaded with the core purpose and enriched with useful examples. Every clause adds value, and the 'Returns slugs for get_recipe' clause efficiently ties the tool to its sibling workflow.

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 simple search endpoint, the description covers the key elements: what is searched, what a result contains, and what the output is for. There is no output schema, so the explicit 'Returns slugs for get_recipe' is especially helpful. It could be more complete by noting behavior when no recipes match or how limit interacts with results, but these are minor gaps.

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 33%, covering just query. The description does not compensate for the unexplained limit and category parameters, nor does it add meaning beyond the schema's query example. An agent would need to inspect the schema to understand limit bounds and category options, leaving a notable 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 states a specific verb ('Search') and a specific resource ('150+ free Keyframer recipes'), and lists concrete examples like bounce, carousels, and shaders. It also clearly differentiates the tool by noting it returns slugs for get_recipe, so an agent can understand its role versus siblings.

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 clearly implies the workflow: search recipes to find candidates, then use get_recipe with the returned slugs. It does not explicitly state when not to use this tool or compare it to siblings like generate_code, but the 'Returns slugs for get_recipe' line provides solid use-context.

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