CookUnity MCP

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable behavioral context beyond annotations: it clarifies that 'next delivery' includes today's delivery unless completed, specifies to always call fresh (never cache results), and explains what data sources are used (confirmed order items, cart items, or auto-picks). No contradiction with annotations.

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 well-structured and front-loaded with the core purpose. Every sentence adds value: purpose statement, usage guidelines, important clarifications, and return details. No wasted words, and key points are emphasized with 'IMPORTANT' formatting.

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's moderate complexity (retrieving dynamic delivery data), rich annotations (readOnly, openWorld, idempotent), and 100% schema coverage, the description is complete. It explains behavioral nuances (fresh calls, inclusion of today's delivery), usage context, and return content, compensating for the lack of an output schema.

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 100%, with the parameter 'response_format' fully documented in the schema. The description mentions the parameter in the 'Returns' section but doesn't add meaningful semantics beyond what the schema already provides (output format options). Baseline 3 is appropriate when schema does the heavy lifting.

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 clearly states the tool's purpose: 'Get the nearest upcoming delivery with full details' and specifies it includes today's delivery if not yet delivered. It distinguishes from sibling tools like cookunity_list_deliveries by focusing on the single next delivery rather than listing all deliveries.

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?

Explicit guidance is provided: 'This is the recommended tool when the user asks about "my next delivery", "upcoming meals", "what's coming", etc.' It also distinguishes from alternatives by specifying it returns the closest scheduled (non-skipped) delivery, unlike cookunity_list_deliveries which might show all deliveries.

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