CookUnity MCP

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

Annotations indicate this is a non-read-only, non-destructive, non-idempotent operation with open-world data. The description adds valuable behavioral context beyond annotations: it explains that cart items are not locked in without confirmation, CookUnity auto-fills at cutoff, and returns order confirmation with ID/payment status or error with out-of-stock meal IDs. This provides practical implementation details not covered by 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 with clear sections (overview, prerequisites, args, returns, important note). Every sentence adds value: the first states the core purpose, prerequisites list essential conditions, args/returns provide outcome details, and the final note explains critical behavioral consequences. No wasted words.

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 an order confirmation tool with no output schema, the description provides comprehensive context: it explains prerequisites, parameters, return values (confirmation with ID/payment status or error details), and important behavioral notes (auto-fill at cutoff). This adequately compensates for the lack of structured output documentation.

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%, providing complete parameter documentation. The description adds minimal semantic value beyond the schema: it mentions 'date' must be a delivery date (implied by context) and restates parameter purposes briefly. Since the schema already fully describes parameters, the baseline score of 3 is appropriate.

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 specific action ('confirm/place the order') and resource ('current cart contents'), distinguishing it from siblings like cookunity_add_to_cart (adds items) or cookunity_list_orders (lists existing orders). It explicitly mentions submitting cart contents as an order, which is distinct from cart management tools.

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 provides explicit prerequisites (meals in cart, before cutoff, meeting plan minimum) and references alternative tools (cookunity_add_to_cart, cookunity_list_deliveries). It also states when NOT to use it ('Without confirming, cart items are NOT locked in'), offering clear guidance on usage context.

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