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

Annotations cover basic hints (readOnly=false, destructive=false, etc.), but the description adds valuable behavioral context: it specifies error conditions (invalid inventory_id, past cutoff), mentions the API response format ('Confirmation with updated quantity'), and references prerequisites ('check cutoff with cookunity_list_deliveries first'). This goes beyond what annotations provide without contradiction.

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, followed by organized sections (Args, Returns, Examples, Error Handling). Every sentence adds value, with no wasted words, making it efficient for an agent to parse.

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 mutation tool with no output schema, the description does well by explaining the return value ('Confirmation with updated quantity') and error handling. It references related tools (cookunity_list_deliveries) and data sources. However, it could slightly improve by clarifying idempotency or side-effects more explicitly, given the annotations don't cover everything.

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?

With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description adds minimal extra semantics (e.g., 'default 1 (max 10)' for quantity, which is also in the schema). It provides examples that clarify usage but doesn't significantly enhance parameter understanding beyond the schema.

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 ('Add a meal to the cart') and resource ('for a specific delivery date'), distinguishing it from siblings like cookunity_remove_from_cart (removal) and cookunity_get_cart (viewing). It precisely defines the tool's function without being tautological.

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 guidance on when to use alternatives, stating 'check cutoff with cookunity_list_deliveries first' to avoid errors. It also implies usage context by referencing data sources ('from menu/search results') and error conditions, though it doesn't explicitly name all sibling alternatives.

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?

Annotations provide hints (destructive, idempotent, not read-only, open-world), but the description adds valuable context: it clarifies that this action 'removes ALL meals' (reinforcing destructive nature), mentions error handling for 'Past cutoff,' and specifies the return as a 'Confirmation message.' This enhances transparency beyond annotations without contradiction.

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 front-loaded with the core action, followed by structured sections for Args, Returns, and Error Handling. Each sentence earns its place by providing essential information without redundancy, making it highly efficient and well-organized.

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 complexity (destructive action with one parameter) and rich annotations, the description is mostly complete. It covers purpose, parameters, returns, and error handling, but lacks details on prerequisites (e.g., authentication) or output specifics beyond 'Confirmation message,' which could be more detailed since there is no 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 schema fully documenting the 'date' parameter's format and default behavior. The description adds minimal semantics by restating the format and requirement, but does not provide additional meaning beyond the schema. Baseline 3 is appropriate given high schema coverage.

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 ('Clear all items from the cart') and resource ('for a specific delivery date'), distinguishing it from sibling tools like 'cookunity_remove_from_cart' which removes individual items. The phrase 'removes ALL meals' emphasizes the scope, making the purpose unambiguous.

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 implies usage context by specifying 'for a specific delivery date' and mentioning error handling for 'Past cutoff,' but it does not explicitly state when to use this tool versus alternatives like 'cookunity_remove_from_cart' or 'cookunity_skip_delivery.' It provides clear context but lacks explicit sibling differentiation.

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?

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.

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, covering safety and idempotency. The description adds valuable context beyond annotations: the 'Always call fresh' warning about caching, the note about empty carts for confirmed orders, and the 'Date not found' error condition. No contradiction with annotations exists.

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 (Args, Returns, Note, Error Handling) and front-loaded key information. While slightly verbose due to repeating schema details, every sentence adds value (e.g., caching warning, error handling). No wasted content.

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 (2 parameters, read-only operation), the description provides complete context: purpose, usage guidelines, parameter details (via schema), behavioral notes (caching, confirmed orders), error handling, and return structure. With annotations covering safety and no output schema needed, this is fully adequate.

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 both parameters (date and response_format) fully documented in the schema. The description's Args section repeats this information without adding significant semantic value beyond what the schema provides, such as explaining why the date defaults to next Monday or the practical difference between markdown and json formats.

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 ('Get cart contents') and resource ('for a specific delivery date'), distinguishing it from siblings like cookunity_list_deliveries (which shows confirmed orders) and cookunity_add_to_cart (which modifies the cart). It precisely defines the scope of retrieval.

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 on when to use this tool ('Always call fresh — NEVER use cached results') and when not to use it ('If the order is already confirmed, cart may be empty — use cookunity_list_deliveries or cookunity_next_delivery instead'). It clearly names alternative tools for different scenarios.

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?

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the core behavioral traits. The description adds valuable context beyond annotations: it explains the default date behavior ('Defaults to next Monday'), describes the different return formats (JSON vs Markdown), and provides error handling guidance. It doesn't contradict annotations and adds useful operational 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?

The description is well-structured with clear sections (description, args, returns, examples, error handling) and front-loads the core purpose. While comprehensive, some information (like the detailed parameter descriptions) could be considered redundant given the 100% schema coverage. However, the structure helps readability and all content serves a purpose.

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 complexity (multiple parameters, different output formats) and the absence of an output schema, the description provides excellent completeness: it explains both return formats in detail, provides parameter requirements and defaults, includes practical examples, and offers error handling guidance. The annotations cover safety and idempotency, making this description complete for agent use.

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%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema: it restates the parameter requirements ('At least one of meal_id or inventory_id is required') and provides examples, but doesn't add significant semantic context that isn't already in the schema descriptions. This meets the baseline for high schema coverage.

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 ('Get full details') and resource ('for a specific meal'), distinguishing it from sibling tools like cookunity_search_meals (which searches) or cookunity_get_menu (which lists multiple meals). It enumerates the detailed information returned (allergens, ingredients, nutrition facts, diet tags, chef info), making the purpose highly specific and differentiated.

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 guidance on when to use this tool vs alternatives: it specifies that at least one of meal_id or inventory_id is required, mentions the default date behavior, and in the Error Handling section explicitly suggests using cookunity_search_meals when a meal is not found. This gives clear context for when to use this tool and when to consider alternatives.

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?

The description adds valuable behavioral context beyond annotations: it explains pagination behavior (limit/offset), output format options (JSON vs Markdown), default values (next Monday, limit 20), and error handling specifics. While annotations cover safety (readOnly, non-destructive), the description provides practical implementation details that help the agent use the tool correctly.

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 perfectly structured and front-loaded: the first sentence captures the core functionality, followed by logically organized sections (Args, Returns, Examples, Error Handling). Every section adds value with zero redundancy. The examples are specific and illustrative without being verbose.

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 complexity (8 parameters, filtering, pagination, dual output formats) and absence of an output schema, the description provides complete context. It explains return formats for both JSON and Markdown, documents error handling, provides practical examples, and covers all behavioral aspects needed for effective use. The annotations complement this with safety information.

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?

With 100% schema description coverage, the baseline is 3. The description adds meaningful context by grouping parameters logically (optional filters, pagination, output format), providing concrete examples of parameter values (e.g., 'vegan', 'gluten-free', $12), and explaining the relationship between parameters in the examples. This enhances understanding beyond the schema's technical specifications.

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 with specific verb ('Browse') and resource ('available meals'), distinguishing it from siblings like 'cookunity_get_meal_details' (single meal) and 'cookunity_search_meals' (different search approach). It explicitly mentions delivery date and optional filters, making the scope unambiguous.

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 clear context for when to use this tool (browsing meals for a delivery date with filters), and the examples illustrate common use cases. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'cookunity_search_meals' for different search approaches, which would be helpful for sibling differentiation.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds valuable context beyond this: it explains error handling (empty cart returns error, invalid IDs cause API errors), describes the two output formats, and provides practical examples. While it doesn't mention rate limits or authentication needs, it adds meaningful behavioral information.

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 (Args, Returns, Examples, Error Handling) and every sentence earns its place. It's front-loaded with the core purpose, then provides necessary details without redundancy. The examples are practical and illustrative without being verbose.

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, rich annotations, and 100% schema coverage, the description provides complete context. It covers purpose, parameters, outputs, examples, and error handling. While there's no output schema, the description thoroughly documents both JSON and Markdown return formats with specific field listings.

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%, so the schema already fully documents all three parameters. The description adds minimal additional semantic context beyond what's in the schema descriptions - it mentions the default date behavior and clarifies that omitting meals uses current cart contents, but these details are already covered in the schema. 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 verb 'Get' and resource 'full price breakdown for a delivery' with specific components listed (subtotal, taxes, delivery fee, discounts, total). It distinguishes from siblings like cookunity_get_cart (which shows cart contents) and cookunity_confirm_order (which finalizes purchase) by focusing specifically on pricing calculations.

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 clear context about when to use it: to price either specific meals or current cart contents. It mentions the default behavior (next Monday) and error conditions. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings for different pricing scenarios.

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?

Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds value by specifying the return structure (JSON with fields like id, name, email, etc.) and output format options, which aren't covered by annotations. However, it doesn't disclose additional behavioral traits like rate limits, authentication needs, or error conditions.

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: a summary sentence, Args, Returns, and Examples. It's appropriately sized, but the 'Returns' section could be more concise by integrating with the summary. Every sentence adds value, though minor trimming is possible.

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 low complexity (1 parameter, no output schema), rich annotations, and 100% schema coverage, the description is mostly complete. It covers purpose, parameters, and return values adequately. However, it lacks explicit usage guidelines compared to siblings and doesn't mention authentication or error handling, which could be beneficial for an AI agent.

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 (enum values, default, description). The description adds minimal value beyond the schema by mentioning the parameter in the 'Args' section and examples, but doesn't provide additional semantic context or usage nuances. Baseline 3 is appropriate given high schema coverage.

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 verb 'Get' and enumerates the exact resources retrieved: user profile, subscription plan, delivery schedule, addresses, and credits. It distinguishes from sibling tools like 'cookunity_get_cart' or 'cookunity_list_orders' by focusing exclusively on comprehensive user information rather than cart, orders, or meal details.

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 implies usage context by listing the types of user data retrieved, suggesting it's for viewing user account details. However, it doesn't explicitly state when to use this tool versus alternatives like 'cookunity_get_cart' or 'cookunity_list_orders', nor does it provide exclusions or prerequisites for usage.

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?

The description adds valuable behavioral context beyond annotations: it emphasizes the importance of fresh data retrieval (addressing potential caching issues), mentions that users may have made changes between calls, and includes error handling guidance for auth errors. Annotations already cover read-only, open-world, idempotent, and non-destructive traits, so the description appropriately supplements rather than contradicts them.

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 (description, important note, args, returns, examples, error handling) and front-loads the core purpose. It's appropriately sized for the tool's complexity, though the 'IMPORTANT' section is somewhat lengthy. Every sentence adds value, but minor trimming could improve conciseness.

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, rich annotations (readOnlyHint, openWorldHint, etc.), and detailed return structure documentation in the description, the description is complete. It covers purpose, usage guidelines, behavioral context, parameters, return format, examples, and error handling—providing everything needed for effective tool use despite the lack of a formal 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%, so the schema already fully documents the single parameter (response_format). The description repeats the parameter in the Args section but doesn't add meaningful semantic context beyond what's in the schema. The baseline score of 3 reflects adequate but not enhanced parameter documentation.

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 with specific verbs ('List upcoming delivery weeks') and resources ('deliveries'), and distinguishes it from siblings by specifying it provides 'full details' including confirmed orders, cart contents, auto-picks, skip/pause status, and deadlines. This is more comprehensive than tools like 'cookunity_list_orders' or 'cookunity_get_cart'.

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 usage guidelines: 'Always call this tool to get FRESH data before answering any question about delivery status, meals, or orders. NEVER rely on cached or previously returned data.' It also implicitly distinguishes from alternatives by emphasizing comprehensive data retrieval, though it doesn't explicitly name specific sibling tools as alternatives.

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?

Annotations already provide comprehensive safety information (readOnlyHint, destructiveHint, idempotentHint, openWorldHint). The description adds valuable behavioral context about pagination and the specific data returned (delivery dates), which goes beyond what annotations provide. No contradictions 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 perfectly structured and concise: a clear purpose statement followed by organized Args and Returns sections. Every sentence serves a purpose with zero wasted words, and key information is front-loaded effectively.

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 read-only list tool with comprehensive annotations and no output schema, the description provides good context about pagination, response format options, and return structure. However, it doesn't explain the relationship with the similar 'cookunity_order_history' tool, which creates a minor gap in completeness.

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?

With 100% schema description coverage, the schema already fully documents all three parameters. The description's Args section repeats parameter information without adding significant semantic context beyond what's in the schema. 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 with specific verb ('Get') and resource ('order history'), including key attributes ('with delivery dates, paginated'). It distinguishes from sibling tools like 'cookunity_order_history' by emphasizing pagination and delivery dates.

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 implies usage context for retrieving paginated order history with delivery dates, but doesn't explicitly state when to use this versus the similar 'cookunity_order_history' sibling tool. It provides clear operational context but lacks explicit alternative 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?

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.

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, covering safety and idempotency. The description adds valuable context beyond annotations: it specifies that this is the only way to see past meal details, includes error handling guidance ('Auth errors suggest checking credentials', 'Empty results if no invoices'), and emphasizes fresh data calls. No contradictions 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 with clear sections (purpose, important note, args, returns, examples, error handling) and front-loaded key information. It's appropriately sized but could be slightly more concise by integrating the 'Args' details into the main text or reducing redundancy with the schema. Every sentence adds value, but the formatting as a bulleted list makes it slightly verbose.

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 complexity (5 parameters, no output schema, rich annotations), the description is complete. It covers purpose, usage guidelines, behavioral context (fresh data, error handling), parameter examples, and return structure. With annotations handling safety and idempotency, and the description adding meal details and data freshness, there are no significant gaps for an agent to invoke this tool correctly.

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%, so the schema already fully documents all 5 parameters. The description adds minimal value beyond the schema: it restates that 'from' and 'to' are required date ranges and provides examples, but doesn't explain parameter semantics like what 'offset' means in practice or how 'response_format' affects output. Baseline 3 is appropriate given high schema coverage.

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 with specific verbs ('Get past order invoices') and resources ('with full meal details, prices, reviews, and billing breakdown'). It explicitly distinguishes this tool from siblings by stating 'This is the only way to see what meals were in past deliveries,' differentiating it from tools like cookunity_list_orders or cookunity_list_deliveries that might not include meal details.

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 usage guidance with 'Always call this tool FRESH when the user asks about past orders or meals. NEVER rely on cached or previously returned data.' It also implies when to use it (for past orders with meal details) versus alternatives like cookunity_list_orders (which might not include meals) or cookunity_get_meal_details (for current meals).

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?

Annotations already indicate this is a destructive, non-idempotent, non-readonly operation. The description adds valuable context beyond annotations: it specifies the return format ('Confirmation with updated quantity') and error handling ('Meal not in cart: API returns error'), which are not covered by annotations. However, it doesn't mention rate limits, authentication needs, or other behavioral traits.

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 appropriately sized and front-loaded with the core purpose in the first sentence. The 'Args' and 'Returns' sections are structured but slightly verbose; for example, repeating parameter details already in the schema adds minor redundancy. Overall, it's efficient with minimal waste.

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 (destructive mutation with 3 parameters), annotations cover safety aspects, and schema covers parameters fully. The description adds return and error details, but lacks output schema. It's mostly complete, though could benefit from more behavioral context like idempotency implications or side effects.

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%, so the schema already fully documents all parameters. The description adds minimal value beyond the schema: it repeats parameter names and basic semantics but doesn't provide additional context like why 'date' must be a Monday or how 'inventory_id' is obtained. With high schema coverage, 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 ('Remove a meal from the cart') with the resource ('for a specific delivery date'), distinguishing it from siblings like 'cookunity_clear_cart' (which removes all items) and 'cookunity_add_to_cart' (which adds items). The verb+resource combination is precise and unambiguous.

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 clear context about when to use this tool ('Remove a meal from the cart for a specific delivery date'), but does not explicitly state when NOT to use it or name alternatives. For example, it doesn't contrast with 'cookunity_clear_cart' for removing all items at once. The context is sufficient but lacks explicit exclusions.

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?

Annotations already provide important behavioral hints (readOnlyHint: true, destructiveHint: false, etc.), but the description adds valuable context beyond these. It specifies the search scope across multiple fields, mentions default behavior for the date parameter ('Defaults to next Monday'), and includes error handling information ('Empty query returns validation error'), which are not covered by annotations. No contradictions with annotations exist.

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, followed by organized sections (Args, Returns, Examples, Error Handling). Every sentence serves a clear purpose, with no wasted words, and the examples efficiently illustrate practical applications.

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 (5 parameters, search functionality) and rich annotations, the description is largely complete. It explains the search scope, provides examples, and includes error handling. However, without an output schema, the description could benefit from more detail on the return structure (e.g., what fields are in 'meals[]'), though it does specify the JSON format.

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?

With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description adds minimal value beyond the schema, mainly by reinforcing the query's search scope and providing example usage. It doesn't introduce new parameter semantics or clarify ambiguities not already addressed in the schema descriptions.

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 ('Search meals by keyword') and resource ('meals'), with explicit scope ('across name, description, cuisine, chef, ingredients, and diet tags'). It distinguishes from siblings like 'cookunity_get_menu' (which likely lists without search) and 'cookunity_get_meal_details' (which focuses on specific meals).

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 clear context for when to use this tool (keyword-based searching across multiple fields) and includes examples that illustrate different use cases (finding dishes by ingredient, diet, or chef). However, it doesn't explicitly state when NOT to use it or mention alternatives among the sibling tools, such as when to use 'cookunity_get_menu' instead for browsing without specific search terms.

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?

The description adds valuable behavioral context beyond annotations. While annotations indicate it's not read-only, not destructive, idempotent, and open-world, the description provides practical constraints: the date must match actual delivery dates from list_deliveries, and it describes error handling scenarios (invalid date, past cutoff, already skipped). This gives the agent crucial operational knowledge not captured in 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 perfectly structured and front-loaded: the core purpose is stated first, followed by critical usage guidance, then parameter semantics, return value, and error handling. Every sentence serves a distinct purpose with zero redundancy. The formatting with clear sections (Args, Returns, Error Handling) enhances readability.

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 single-parameter mutation tool with good annotations but no output schema, the description provides complete context. It covers purpose, prerequisites, parameter semantics, return value, and error scenarios. The agent has everything needed to use this tool correctly, including integration with the cookunity_list_deliveries sibling.

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?

With 100% schema description coverage, the baseline is 3. The description adds meaningful context: it emphasizes that the date 'must match an actual delivery date from cookunity_list_deliveries' and provides error handling details for invalid dates. This goes beyond the schema's technical validation to explain the semantic requirement and consequences.

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 ('Skip a delivery week') and resource ('delivery'), distinguishing it from siblings like cookunity_unskip_delivery (reverse action) and cookunity_list_deliveries (read-only). It uses precise language that leaves no ambiguity about the tool's function.

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 guidance on when to use this tool: 'Always call cookunity_list_deliveries first to get valid delivery dates — do NOT guess or calculate dates manually.' It names the specific alternative tool (cookunity_list_deliveries) and clearly states when not to use this tool (without first calling that sibling).

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?

The description adds valuable behavioral context beyond annotations: it specifies the prerequisite of calling another tool first, describes error handling behaviors (returns available dates for invalid dates, returns API error for unskipped weeks), and mentions the confirmation message return. Annotations cover read/write status, idempotency, and open-world nature, but the description provides practical implementation details.

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 perfectly structured: the core purpose is stated first, followed by critical usage instructions, then parameter semantics, return value, and error handling. Every sentence serves a distinct purpose with zero redundancy, and information is logically organized for quick comprehension.

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 single-parameter mutation tool with comprehensive annotations but no output schema, the description provides complete context: clear purpose, explicit usage guidelines, parameter constraints, return information, and error behaviors. It addresses all necessary aspects for safe and effective tool invocation.

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?

With 100% schema description coverage, the baseline is 3. The description adds meaningful context by emphasizing that the date 'must match an actual delivery date from cookunity_list_deliveries' and warning against manual calculation, which provides crucial semantic guidance beyond the schema's format specification and default value note.

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 explicitly states the verb 'Unskip' and the resource 'delivery week', making the purpose immediately clear. It distinguishes from sibling tools like 'cookunity_skip_delivery' by specifying the opposite action, and from 'cookunity_list_deliveries' by focusing on modification rather than listing.

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 guidance on when to use this tool: 'Always call cookunity_list_deliveries first to get valid delivery dates — do NOT guess or calculate dates manually.' It also implicitly distinguishes from 'cookunity_skip_delivery' by handling the reverse operation, and from other cart/order tools by focusing on delivery scheduling.

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