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

Discloses irreversibility, that order quantities and total become zero, canceled flag becomes true, points and payments are automatically refunded, and sales fee becomes zero if not yet determined. This adds significant context beyond annotations, which only indicate mutability and idempotency.

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 a single paragraph efficiently covering the main action, consequences, limitations, and alternatives. Every sentence adds value, and the most important information is front-loaded.

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?

Despite no output schema, the description fully explains outcomes (quantities zero, canceled flag, automatic refunds), unsupported cases, and irreversibility. Parameters are well-covered, and sibling tools are mentioned for related operations.

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 covers 50% of parameters with descriptions (only restock). The description adds meaning: restock specifies whether to automatically restock inventory. sale_id is identified as the target, compensating for its lack of schema description.

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?

Description clearly states it cancels an existing order and triggers returns/refunds, specifying the target via sale_id and the restock parameter. It distinguishes itself from sibling tools like updateSale and getSale by noting updates and details are handled elsewhere.

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?

Explicitly describes when to use (cancel orders), when not to use (split orders, credit card with cancel linkage), and lists alternatives (updateSale for updates, getSale for details). Also mentions unsupported 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 indicate destructiveHint=true and readOnlyHint=false, so the description's claim of creating a coupon aligns. It adds value by explaining the return includes id, but does not cover authentication or rate limits. Still effective.

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, starting with purpose, then required fields, unit details, optional fields, and references to related tools. It is slightly verbose but informative.

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 CRUD context and annotations, the description covers creation logic, required/optional fields, unit semantics, and links to other tools. It does not mention error handling or output format beyond ID, but is sufficiently complete.

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?

The description explains the unit of discount_amount based on coupon_type and that delivery_charge does not require discount_amount, adding meaning beyond the schema's descriptions. However, the schema already has detailed descriptions, so the added value is moderate.

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 it creates a new shop coupon and returns the coupon object with id. It distinguishes from sibling tools by explicitly mentioning updateCoupon, deleteCoupon, getCoupons, and getCoupon for other operations.

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 specifies required fields (code, coupon_type, starts_at, ends_at) and optional fields, and explicitly tells when to use alternative tools: '変更は updateCoupon、削除は deleteCoupon、参照は getCoupons / getCoupon'.

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?

Discloses URL expiration of 72 hours and reissuance requirement. Covers disallowed conditions. However, annotations include destructiveHint: true but description does not address destructive behavior beyond 'issuing URLs', leaving a slight ambiguity. Overall, good behavioral context beyond 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?

Description is well-structured with front-loaded purpose, followed by expiration, disallowed cases, and alternative tools. Efficient without unnecessary words, though could be slightly shorter.

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 tool with no output schema and given annotations, the description covers all necessary aspects: purpose, usage, constraints, expiration, and alternatives. It is self-contained and addresses likely agent questions.

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?

Only parameter sale_id is described as identifying the target order, but no additional details on format or constraints beyond what schema provides (integer range). Schema description coverage is 0%, so description compensates minimally.

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 creates payment URLs for unpaid orders, using sale_id to identify the order. It distinguishes from sibling tools like getSale, getSales, and sendSalesMail by specifying their alternative purposes.

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?

Explicitly states when to use (unpaid orders), provides conditions under which issuance is not possible (paid, cancelled, unsupported payment methods), and mentions reissuance after expiration. Also names alternative tools for related tasks.

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 claims the tool 'creates' a category, which is a non-destructive operation, but the annotation destructiveHint=true indicates it is destructive, creating a contradiction. No other behavioral traits are disclosed beyond what annotations imply.

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 relatively concise, front-loading the purpose and then listing parameters and alternatives. Could be further structured with bullet points for clarity.

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?

Provides purpose, parameters (partial), and alternatives. However, lacks return value info, error handling, and contradicts annotations on destructiveness. Adequate but with 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?

The description explains the main parameters (name, sort, meta_tag with constraints) but omits expl and display_state. With 0% schema description coverage per context, the description only partially compensates.

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?

States clearly that the tool creates a new top-level product category in the hierarchy, and distinguishes from siblings by naming specific tools for subcategories, editing, listing, and product groups.

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?

Explicitly lists when to use this tool (create top-level category) and when to use alternative tools (createProductCategoryChild, updateProductCategory, getProductCategories, createProductGroup).

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 states 'create' (non-destructive), but the annotation destructiveHint=true indicates the tool may be destructive. This is a direct contradiction. Additionally, openWorldHint=true is not explained. Therefore, the description fails to accurately convey behavioral traits, scoring 1 per contradiction rule.

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 and well-structured, front-loading the purpose and then moving to parameters, constraints, and alternatives in a logical order. No unnecessary information is present.

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?

While the description covers the main purpose and constraints, it fails to address the destructiveHint and openWorldHint annotations, which are critical for an AI agent to understand side effects. Additionally, it omits parameters like expl and display_state. These gaps reduce 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?

The description adds marginal value beyond the schema: it mentions category_id, name, sort, and meta_tag fields, but does not cover expl or display_state. Schema coverage is 50%, and the description repeats schema details without significant new meaning. A score of 3 is appropriate as it partially compensates but is not extensive.

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 that the tool creates a new child category under a specified parent category, specifying the verb 'create', the resource 'child category', and the parent constraint. It distinguishes from siblings by mentioning alternative tools for editing and creating parent categories.

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 explicitly provides usage guidelines, including that child categories are at the second level and cannot have further subcategories, and recommends sibling tools for other operations (updateProductCategoryChild for editing, createProductCategory for new parent categories, getProductCategories for listing).

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 destructiveHint=true, but description does not elaborate on side effects. It adds that the created object is returned, but overall behavioral transparency is adequate but not enhanced beyond 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?

Front-loaded with purpose and return, then parameter details, then sibling differentiation. Slightly lengthy but all sentences add value; no redundancy.

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?

No output schema, but description specifies returned object includes id. Covers purpose, parameters, and alternatives fully. Given simple tool, completeness is high.

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?

Despite schema having field descriptions, summary highlights required fields (name, display_state) and explains optional ones (parent_group_id for hierarchy, meta_tag for SEO, expl for description), adding context beyond raw 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?

Description clearly states the tool creates a product group, provides examples ('セール対象', '新作コレクション'), and distinguishes from siblings by naming updateProductGroup for editing and createProductCategory for categories.

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?

Explicitly says when to use (creating groups) and when not to (assign products via updateProduct, edit groups via updateProductGroup, categories via createProductCategory), with clear 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?

Beyond annotations (destructiveHint=true, idempotentHint=true), the description adds that deletion is permanent, customers cannot use the code afterward, and there is no undo API, which is useful 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?

Concise yet information-dense: first states action, then effect, then warnings and alternatives. Every sentence adds value, no redundancy.

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 deletion tool with no output schema, the description covers purpose, effect, and alternatives well. Lacks mention of error handling for non-existent coupon, but overall 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?

The single parameter coupon_id is fully described in the schema; the description adds minimal context (identify target with coupon_id), so baseline 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 action (delete the shop coupon by coupon ID) and distinguishes it from sibling tools like updateCoupon (for temporary disable) and other CRUD operations (getCoupon, createCoupon, getCoupons).

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?

Explicitly provides when to use and when not to: advises to use updateCoupon for temporary disable, notes the lack of undo API, and directs to other tools for checking/creating/listing.

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 destructive and idempotent hints. The description adds crucial behavioral context: the app requirement, the revert to no-rank state, and error behavior. No contradictions.

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?

Three sentences with key information front-loaded. No redundancy. Efficient and well-structured.

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 simple one-parameter delete operation and no output schema, the description covers purpose, parameter, prerequisites, error conditions, and sibling alternatives. 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 has 100% coverage with a clear description for customer_id. The tool description integrates the parameter into the narrative, explaining its role in the operation, adding slight value over schema alone.

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 it removes the membership rank association from a customer, reverting to no rank. It distinguishes from updateCustomerMembership, getCustomer, and updateCustomers, providing a specific verb and resource scope.

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?

It explicitly states when to use (removing rank) and when not (use alternatives for other operations). It also mentions the prerequisite of the Member Rank app and error condition if not installed, providing clear usage 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?

The description discloses that the tool only removes the pickup registration, not the product itself, and references the idempotent and destructive nature, which aligns with the annotations (idempotentHint: true, destructiveHint: true). No contradictions.

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?

Three sentences, front-loaded with the main action, each sentence adds necessary information without redundancy.

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 two-parameter tool with no output schema, the description fully covers the purpose, identification, side effects, and related tools.

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 having descriptions. The description adds context that product_id and pickup_type identify the target and that pickup_type uses the same enum as postProductPickup, but adds limited additional meaning 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 it removes a specified product from a specific pickup frame, using precise verbs and referencing the key parameters product_id and pickup_type, which distinguishes it from sibling tools like postProductPickup and putProductPickup.

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?

It explicitly states the tool removes a product from a pickup frame, clarifies that the product itself is not deleted, and mentions sibling tools for registration and modification, providing clear context on when to use this tool versus 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 declare readOnlyHint, idempotentHint, and non-destructive. The description adds detail on returned fields, consistent with annotations. No hidden behaviors or contradictions.

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 a concise paragraph with clear structure: action, input, output, use cases, sibling references. No unnecessary words, but slightly longer than minimal.

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 no output schema, the description fully compensates by listing all important returned fields. Usage context and sibling relationships are provided. Complete for a simple read tool with one parameter.

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 coverage is 100% for the single parameter. Description adds value by enumerating returned fields and explaining the parameter's role, going beyond the schema's brief description.

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 tool retrieves a single shop coupon by ID, lists key returned fields, and distinguishes itself from siblings like getCoupons, updateCoupon, deleteCoupon, and createCoupon.

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?

It mentions use cases: checking details of issued coupons and checking current values before updateCoupon. Sibling tools are listed for alternatives, but no explicit 'when not to use' 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, openWorldHint, idempotentHint, and destructiveHint, indicating safe read-only behavior. The description adds that it returns non-deleted coupons, no query parameters are required, and explains coupon_type values. 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 concise, well-structured, and front-loaded. It states the main purpose first, then details output fields, and ends with references to sibling tools. Every sentence adds value without 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?

For a simple list tool with no parameters, the description is complete. It explains output fields, coupon types, and references sibling tools. No output schema exists, but the description covers essential return values.

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 coverage is 100% (dummy parameter described as 'Not used'). The description adds that no query parameters are required, clarifying the dummy parameter's irrelevance. This adds value 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 it retrieves a list of coupons, specifying no query parameters needed and that it returns all non-deleted coupons. It lists the fields included, making the tool's 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 provides clear context for when to use this tool (list all coupons) and explicitly names sibling tools for specific operations (getCoupon, createCoupon, updateCoupon, deleteCoupon). However, it does not mention when not to use it or any specific prerequisites.

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, idempotentHint=true, destructiveHint=false, confirming it's a safe read-only operation. The description adds context about the returned customer object, enhancing transparency without contradicting 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 concise, front-loaded with the primary action, and each sentence serves a purpose: stating what it does, listing return fields, specifying usage context, and providing alternatives.

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 no output schema, the description adequately describes the return fields. It also covers usage context and alternatives, making it complete for a single retrieval tool.

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?

The input schema has one parameter (customer_id) with 0% description coverage. The description explains that it uniquely identifies a customer and returns their details, adding value despite the parameter's self-explanatory name.

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 that the tool retrieves a single customer by customer_id, listing the fields returned (name, contact, address, points, member rank). It distinguishes itself from sibling tools like getCustomers, postCustomerPoints, and updateCustomerMembership, making its 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 explicitly states when to use this tool (to view details of a specific customer from a list) and when to use alternatives: getCustomers for conditional search, postCustomerPoints for point operations, updateCustomerMembership for membership changes, and getCustomers with member parameter for filtering by membership status.

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. The description adds detailed behavioral context about pagination (limit max 100, default 10, offset) and filtering capabilities, complementing 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 a single paragraph but efficiently covers purpose, filters, pagination, and siblings. Could be more structured (e.g., bullet points) but is clear and concise enough.

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 complexity (16 parameters, no required, no output schema), the description provides a comprehensive overview including member filtering, partial matches, date ranges, pagination, and references to related tools. Fully compensates for missing 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 baseline is 3. The description adds value by grouping parameters into functional categories (partial match, date range, sex, etc.) and summarizing capabilities beyond the individual 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 it retrieves a list of customers including both members and guests, with various filtering options. It distinguishes itself from siblings like getCustomer (single customer), postCustomers (create), and updateCustomers (update).

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?

Explicitly mentions when to use this tool and references alternatives: getCustomer for a specific customer, postCustomers for creation, updateCustomers for updates. Provides clear context for tool selection.

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 read-only, idempotent behavior. The description adds context by stating no arguments are required and listing return fields. No contradictions.

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?

Three efficient sentences: purpose, return details, and usage guidance with sibling reference. No redundant information; every sentence adds value.

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 tool with no parameters and no output schema, the description is fully adequate. It covers what the tool does, what it returns, when to use it, and references related tool for adjacent functionality.

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 coverage is 100% with a dummy parameter. The description clarifies that no arguments are needed, directly addressing the dummy parameter's purpose. This adds meaning 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 tool retrieves a list of shipping methods, specifying the returned fields (ID, name, fee calculation rules, applicable areas) and explicitly differentiates from the sibling getDeliveryDateSetting.

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?

Provides explicit usage scenarios: presenting shipping options before order creation and matching delivery_id in existing orders. Also advises using getDeliveryDateSetting for delivery date/time, effectively setting when not to use this tool.

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 readOnly and idempotent. Description adds key behavioral context: 'setting is common to entire shop,' 'no arguments required,' and 'returns current values.' While not exhaustive, it supplements annotations well.

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?

Four sentences, front-loaded with purpose and key information. Every sentence serves a purpose: what, scope, arguments, usage, sibling reference. No fluff.

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 simplicity and existing annotations, the description covers purpose, scope, usage, and alternatives. It mentions return fields in parentheses but lacks explicit return structure details. Still adequate for selection and 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?

Input schema has a dummy parameter with description 'Not used.' The description reinforces 'no arguments required,' clarifying that the dummy parameter is irrelevant. Schema coverage is 100%, so description adds marginal extra clarity.

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 it gets delivery date/time settings, defines the scope (shop-wide, not per delivery method), and distinguishes from sibling tool getDeliveries by directing users there for delivery methods.

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 usage scenarios: referencing before presenting options in cart, or matching with order data. Also notes no arguments required and provides alternative getDeliveries for delivery method listings.

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. The description adds that no arguments are needed and it returns current values, but does not disclose additional behaviors like error cases or rate limits. This is adequate but not exceptional.

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?

Two sentences with no fluff: first defines the tool's action, second gives practical use cases. Efficient and front-loaded.

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 getter with no output schema, the description explains the broad content (gift settings) and mentions it returns current values. While it lacks detail on the exact structure, it is sufficient given the tool's simplicity and the presence of annotations.

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?

The input schema has a dummy parameter with full coverage. The description states 'no arguments needed' which aligns with the schema. No additional parameter meaning is provided beyond what the schema already conveys.

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 it retrieves the shop's gift settings (wrapping, noshi, message cards, fees, etc.) with a specific verb and resource, and distinguishes it from sibling get* tools like getProduct or getShop.

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 usage context: no arguments needed, returns current values, and specific use cases (determining gift applicability in orders, referencing before adding fees). However, it does not explicitly mention when not to use it or suggest 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 declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by detailing the contents of the response (IDs, names, fee rules, conditions) and the absence of query parameters, enhancing transparency beyond 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 two sentences long, front-loading the main purpose and then elaborating on the output and use cases. No filler or redundant 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?

Given the tool's simplicity (no output schema, one dummy param, rich annotations), the description fully covers what, how, and when to use. It is complete for an agent to select and invoke the 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?

The input schema has a single dummy parameter with description 'Not used'. Schema coverage is 100%, so the description does not add significant meaning beyond the schema. The description omits any discussion of parameters, which is acceptable given its trivial nature.

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 retrieves a list of valid payment settings in the shop, specifying the result includes IDs, names, fee rules, and conditions. It distinctively defines its purpose among sibling tools like getSales.

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 context for use cases: before presenting payment options in cart or matching with payment_id in order data. However, it does not explicitly mention when not to use or list alternative tools, leaving room for improvement.

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 and destructiveHint=false, establishing a safe read operation. The description adds value by detailing the return object structure (name, price, stock, etc.) and usage context (current value reference before update), which helps the agent understand what to expect.

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 yet comprehensive, packing purpose, return fields, usage context, and sibling alternatives into a few sentences. It is front-loaded with the core action and efficiently extends with necessary details without redundancy.

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 read tool with no output schema, the description fully compensates by enumerating key return fields (name, price, stock, etc.), stating usage scenarios, and listing sibling tools. This enables the agent to understand what the tool returns and when to use alternatives.

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 for the single parameter 'product_id', the baseline is 3. The description does not add additional meaning beyond the schema for the parameter itself, as it merely restates that product_id is passed. However, it does clarify the return result, which indirectly adds context.

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 '取得します' (retrieves) and the resource '商品詳細' (product details) for a specific product ID. It distinguishes from siblings by explicitly naming alternative tools (getProducts, getStocks, getProductVariants, getProductImages) for different use cases.

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 explicitly states when to use this tool ('特定商品の詳細確認' and 'updateProduct前の現在値参照') and provides clear alternatives for list search, stock info, option details, and image lists, guiding the agent on proper tool selection.

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, openWorldHint, idempotentHint, and destructiveHint. The description adds pagination details (limit, offset) and filtering by product_ids and display_state, which is useful but not extensive beyond 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 a single sentence but covers all necessary information clearly. It uses semicolons for structure. It is efficient, though could be broken into multiple sentences for 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?

Given the tool has 4 parameters and no output schema, the description provides sufficient context: purpose, filtering, pagination, and alternative tool. It does not describe the response format, but that is acceptable for a list retrieval tool.

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 coverage is 100%, so parameters are well-defined. The description adds extra context such as default limit (50), maximum (250), and that product_ids can be comma-separated, which goes 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 it retrieves a list of additional attributes for product advertising/feed (Google product categories, GTIN, MPN, brand, etc.). It distinguishes from getProduct by specifying that getProduct is for product 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 explains when to use this tool (to get advertising attributes) and directs to getProduct for product details. It also details filtering options and pagination, but does not explicitly list when not to use other sibling tools.

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, etc. The description adds behavioral context beyond annotations by specifying the return structure (hierarchical with children array), the fields (id_big, id_small, name, sort, display_state, meta_tag, image_url), and that it is a no-parameter read operation. This is valuable but not fully comprehensive.

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 two sentences. The first sentence clearly states the tool's purpose. The second sentence, while informative, is somewhat long and could be broken into shorter sentences for readability. Overall, it is reasonably concise and does not waste 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?

There is no output schema, so the description compensates by explaining the return value structure, hierarchy, and common fields. It also references sibling tools for related actions, providing complete context for the tool's usage. Given the tool's simplicity, the description 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?

The input schema has a single dummy parameter described as 'Not used', and the description reinforces that no parameters are required. Schema description coverage is 100%, so the schema already conveys the parameter purpose. The description adds marginal value by explicitly stating 'パラメータ不要' (no parameters needed).

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 that the tool retrieves a list of product categories in a 2-level hierarchy (big and small categories) without parameters. It lists the fields returned and distinguishes itself from sibling tools like createProductCategory and updateProductCategory by specifying their purposes.

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 explicitly states that no parameters are needed and provides alternatives for other operations: createProductCategory for creating big categories, createProductCategoryChild for small categories, and updateProductCategory/updateProductCategoryChild for editing. This guides the agent on when to use this tool versus its siblings.

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, openWorldHint, idempotentHint, destructiveHint. Description adds value by specifying returned fields (name, display_state, parent_group_id, etc.) and explicitly noting '所属商品の一覧は含まれません' (list of belonging products not included). No contradictions.

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?

Single paragraph packs action, return fields, and sibling references with no wasted words. Every sentence earns its place.

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 simple ID lookup, annotations cover safety, and no output schema required, description fully covers purpose, inputs, outputs, and sibling relationships. Also notes exclusion of product list.

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 has 100% coverage with description '商品グループID'. Description adds meaning by explaining that passing group_id returns a group object with specific fields, exceeding schema detail.

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?

Description clearly states verb ('取得'), resource ('商品グループ'), and scope ('1 件'), and distinguishes from siblings like getProductGroups (list), createProductGroup, updateProductGroup, and getProducts for filtering.

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?

Explicitly lists when to use alternative tools: listing with getProductGroups, creation with createProductGroup, editing with updateProductGroup, checking products with getProducts, and linking with updateProduct.

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, idempotentHint=true, destructiveHint=false. Description adds useful response field details (id, name, display_state, etc.), which complements 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?

Two sentences: first states purpose and returns all groups, second lists fields then sibling tools. Every sentence is informative and there is no fluff.

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?

No output schema exists, so description compensates by listing fields. Tool is simple (no parameters, returns all groups), and the description covers purpose, fields, and sibling references completely.

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?

Input schema has only a dummy parameter with description 'Not used'. Schema coverage is 100%. The description confirms parameters are unnecessary, adding clarity 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?

Description clearly states it retrieves list of product groups, specifies the resource (商品グループ), and differentiates from siblings like getProductGroup, createProductGroup, updateProductGroup, and getProductCategories.

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?

Explicitly states no parameters needed, returns all groups, and provides alternatives for single retrieval, creation, editing, and hierarchical categories.

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, idempotentHint, and destructiveHint. Description adds details about return structure (array of objects with position and URL) and the maximum of 50 images. No contradictions.

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?

Two sentences, front-loaded with purpose and usage. 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?

Given no output schema, description explains return structure and limits. Differentiates from sibling. Complete for a simple read tool.

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% for product_id. Description reinforces usage by mentioning product_id, but doesn't add significant extra meaning 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 it 'gets all image information for a specified product' and distinguishes from the sibling 'getProduct' by specifying when to use each.

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?

Explicitly says when to use this tool ('when you want to refer to images only') and when not ('to get the product body, use getProduct'). Also mentions the position range (0-49, max 50).

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 read-only, open-world, idempotent, and non-destructive behavior. Description adds practical behavioral details like pagination limits (max 50, default 10), field selection, sorting options, and filtering, which are valuable beyond annotations. No contradictions.

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?

Description is concise but comprehensive: front-loaded with purpose, then lists capabilities and pagination, ends with sibling differentiation. No redundant sentences, though slightly long due to many options.

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 25 parameters, full schema coverage, and annotations, the description effectively covers main use cases, pagination, sorting, and filtering. It differentiates from siblings and avoids explaining return values (no output schema). Adequately complete for a listing tool.

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 covers all 25 parameters with descriptions; description references schema for specifics ('具体的なパラメータと指定方法はスキーマを参照'). It adds context for limit, offset, and fields, but does not significantly enhance meaning beyond schema. Baseline 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?

Description clearly states '商品を一覧取得します' (list products) and identifies specific sibling tools for distinct purposes (getProduct, getStocks, postProducts, updateProduct). This makes the tool's purpose unambiguous and distinct.

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?

Description explicitly tells when to use this tool vs alternatives (e.g., '特定商品は getProduct、在庫のみは getStocks'), and provides details on pagination, sorting, and filtering options, guiding appropriate 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?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by specifying return of empty array for non-variant products, pagination limits (max 100, default 10), and available query parameters, enhancing transparency beyond 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 a single sentence that front-loads the main purpose and flows logically through parameters and return behavior. While dense, it covers key information without redundancy.

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 no output schema, the description explains the return structure (variant object array), empty array case, and parameter usage. It omits error handling but is sufficient for a simple read tool with sibling references.

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 coverage is 100% but descriptions are basic. The tool description provides useful context like default/max for limit and fields usage, but contains an inconsistency: description says limit max 100, while schema description says max 50. This contradiction reduces reliability.

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 retrieves a list of product options (variants) for a specified product, using specific verb '取得' and resource. It distinguishes itself from sibling tools like getProduct or getProducts by focusing on variants.

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 mentions filtering by model_number and pagination parameters, providing implicit usage context. It also references updateProduct for stock updates, but lacks explicit when-to-use vs. alternatives or when-not-to-use 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 and destructiveHint. The description adds value by explaining that deleted reviews are excluded, all statuses are included, and lists fields. No 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?

Concise, front-loaded with purpose, every sentence adds value. No unnecessary 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?

Without output schema, the description adequately lists fields and behaviors (paging, status, reference to getProduct). Annotations provide safety info, making it fairly complete.

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 covers 100% of parameters. Description adds meaning by specifying limit maximum (100) and default (10), which is not in 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 it retrieves a list of product reviews for a shop, using specific verbs and resources. It distinguishes from siblings like getProduct, which is for product 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?

Provides context on paging with limit/offset, and specifies that all non-deleted reviews are returned regardless of status. However, it does not explicitly state when not to use it or compare to other tools.

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, idempotentHint, destructiveHint, so description does not need to add much. It adds context about return content but that is not behavioral. 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?

Description is a single paragraph, front-loaded with purpose, and efficiently lists alternatives. Could be slightly shorter but well-structured.

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 tool with one parameter and no output schema, the description adequately covers purpose, parameter explanation, and return fields. Alternatives are listed, making it complete.

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 has no description (0% coverage), but the description explains sale_id as an integer ID assigned at order creation, adding meaning beyond the raw schema constraints.

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?

Description clearly states the verb 'get' and resource 'sale detail' (受注詳細), lists return fields, and differentiates from sibling tools by naming specific alternatives.

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?

Explicitly states when to use (individual check of a specific order) and provides alternatives for other use cases: getSales for multiple orders, statSale for aggregation, updateSale/cancelSale/sendSalesMail for writes.

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, idempotentHint, and non-destructive behavior. The description adds context: default time range (1 week), pagination limits (max 100, default 10), and various filtering capabilities. This provides additional behavioral detail beyond 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 concise (three sentences) yet packs all key information: purpose, default behavior, filter types, pagination, and sibling references. It is well-structured, front-loading the core function and efficiently covering details without redundancy.

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 complexity (22 parameters, multiple filters), the description covers the main use cases, default behavior, and relationships to other tools. It lacks output structure details, but as a list operation with readOnlyHint, this is acceptable. Overall, it provides sufficient context for effective tool selection and usage.

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 each parameter is documented. The description groups filters (customer, status, email state) and mentions pagination and fields selection, adding high-level context. However, it doesn't provide details not already in schema; it references the schema for specifics.

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 retrieves a list of order data (受注データを一覧取得), specifies default behavior (last week if no params), and distinguishes from siblings like getSale (specific order), statSale (aggregation), and update tools. This provides excellent clarity.

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 explicitly outlines when to use this tool (listing orders) and provides alternatives: getSale for a specific order, statSale for sales totals, updateSale/cancelSale/sendSalesMail for modifications. It also explains default date ranges and filtering options, offering comprehensive usage 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. Description adds value by listing what data is retrieved (shop name, URL, operator info, tax settings), beyond what structured fields convey.

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?

Two sentences: first states purpose and details, second provides usage context. No filler, front-loaded, every sentence earns its place.

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?

No output schema, but description lists categories of returned info. Annotations cover safety. Sufficient for a read-only, no-argument tool; could mention rate limits or response size but not critical.

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 coverage is 100% with 1 dummy parameter fully described. Description adds '引数は不要です' (no arguments needed), clarifying that the dummy param is irrelevant. Baseline 3, plus 1 for added clarity.

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?

Description specifies exact verb '取得します' (retrieve) and concrete resources: shop name, URL, operator info, tax settings. It distinguishes from sibling tools by positioning itself as a foundational context-checking tool before other calls.

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?

Explicitly states no arguments required and advises using before other tools to grasp shop settings and operator info, or to verify the connected shop. Provides clear when-to-use 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 indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds useful behavioral details like pagination and filtering, with no contradictions.

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 front-loaded purpose and logical grouping of filters, pagination, and alternatives. It is slightly verbose but still efficient.

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 11 parameters and no output schema, the description covers filtering and pagination but does not specify return value format. It is adequate but could be more complete.

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 baseline is 3. The description adds some context (e.g., limit max 50, stocks filter meaning) but does not 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 it retrieves stock information for products with inventory management enabled. It distinguishes from sibling tools by explicitly mentioning updateProduct and getProductVariants for related tasks.

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 good usage context, including when to use it, filtering options, and pagination. It also references alternative tools for updating stock and checking variant stock, though it does not explicitly state when not to use it.

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, and idempotentHint=true. The description adds context that it returns current source code and is used for confirmation and backup, which aligns with the annotations. No contradictions; the description reinforces the safe, non-destructive nature.

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: it starts with the main purpose, then details parameters, then explains use cases and alternatives. It is slightly verbose but every sentence adds value. Could be made more concise, but overall effective.

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 that parameters are fully documented in the schema, annotations cover safety, and the description covers usage context and alternatives, the description is complete. Though no output schema exists, the description states what is returned ('current template source code'), which is sufficient.

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 coverage is 100% with descriptions for both parameters. The description adds value by providing a clear list of page_type values with Japanese explanations (e.g., 'index(共通)'), which is more intuitive than the schema's enum descriptions. This helps an agent understand the mapping.

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 that the tool gets HTML and CSS source for a specified template page type, using the verb '取得する' (get) and the resource 'template page'. It distinguishes from siblings by mentioning updateTemplatePage for editing, getTemplatePreview for preview, and getTemplates for 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 explicitly states when to use this tool (for checking current value before editing or backup) and provides explicit alternatives: updateTemplatePage for editing, getTemplatePreview for preview, getTemplates for listing. This gives clear guidance on tool selection.

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 readOnly, openWorld, idempotent, non-destructive. Description adds crucial behavioral details beyond annotations: URL expiration, output format (a URL), and that it shows the current shop with the template. No contradictions.

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?

Description is concise yet comprehensive: few sentences cover action, return type, expiration, use cases, and alternatives. Information is front-loaded with the primary function.

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 simplicity (one parameter, no output schema), the description is complete. It explains what the tool does, what it returns, expiration, use cases, and provides cross-references to related tools. No gaps for the agent to make incorrect guesses.

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?

Input schema has 100% coverage with a description for template_id. The description adds context by explaining that providing template_id returns a URL displaying the current shop with that template, clarifying the parameter's role beyond the schema's brief label.

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: issuing a temporary preview URL for templates in the browser. It distinguishes from sibling tools by explicitly noting getTemplatePage (source retrieval), updateTemplatePage (editing reflection), and getTemplates (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?

Provides explicit usage context: for checking appearance before editing or after applying updateTemplatePage. Mentions URL expiration (1 hour) and need to reissue. Directly names alternative tools for related tasks.

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, idempotentHint=true, destructiveHint=false. The description adds that no query is needed and specifies the return fields, aligning with and complementing the 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 two concise sentences that front-load the purpose and return fields, then provide sibling differentiation. Every sentence adds value without 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?

For a simple list-all tool with no required parameters and no output schema, the description covers everything: purpose, return fields, and alternatives. No gaps are present.

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 has one dummy parameter with 'Not used' description; the description states 'クエリ不要' (no query needed), confirming the parameter is irrelevant. This fully explains the parameter semantics.

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 it retrieves a list of all templates (shop page HTML/CSS designs, used or unused) without query, returning specific fields. It explicitly distinguishes from sibling tools getTemplatePage, getTemplatePreview, and updateTemplatePage.

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 when-to-use: for listing all templates, and contrasts with alternatives for specific actions (getTemplatePage for HTML/CSS, getTemplatePreview for preview URL, updateTemplatePage for updates). This gives clear 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?

The description explains the additive behavior (points added to current balance, negative for subtraction) and that the new balance is returned. Annotations indicate readOnlyHint=false and destructiveHint=true, which align with the mutation described. No 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 three concise sentences, front-loading the core action, then parameter details, then sibling differentiation. No extraneous 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?

For a simple mutation tool with two required parameters and no output schema, the description fully explains operation, parameters, effect, and alternatives. No 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?

The description provides full semantics for both parameters: customer_id selects target, points is integer for addition (negative for subtraction). This compensates for the schema's 50% description 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 adds or subtracts shop points for a specified customer, using customer_id and points. It distinguishes from siblings like getCustomer, updateCustomers, and updateCustomerMembership.

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: use for point adjustment, and names alternative tools for other customer operations (getCustomer, updateCustomers, updateCustomerMembership).

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=false and destructiveHint=true. The description confirms creation and return of the customer object, but adds no additional behavioral context (e.g., idempotency, side effects). It does not contradict annotations, but the value added beyond annotations is limited.

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 two concise sentences in Japanese, with no redundant information. It front-loads the core purpose and immediately adds sibling tool references. Every sentence serves a clear 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 complexity (1 nested parameter with many sub-properties, no output schema), the description is moderately complete. It explains the return value and references sibling tools, but does not cover all parameters, error handling, or idempotency. More detail on optional fields and potential duplicates would improve 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?

Schema description coverage is 0% for the top-level parameter, placing the burden on the description. The description explains required fields (name, mail, pref_id, postal, address1, tel) and the add_member flag, but omits many optional fields like fax, busho, hojin, address2, furigana, etc. The schema’s nested descriptions help, but the description should be more comprehensive.

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 and resource: '新規顧客をショップに登録し' (register a new customer in the shop). It also distinguishes from sibling tools by explicitly mentioning updateCustomers, getCustomer, and getCustomers for other operations, 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 provides explicit alternatives: updateCustomers for updates, getCustomer for retrieval, getCustomers for search. It also explains how to register as a member vs non-member via the add_member parameter. It lacks a clear 'when not to use' statement but the context is well-defined.

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 destructiveHint=true, and description clarifies that it creates a new pickup entry, adding context about the four pickup types and independent ordering. No contradiction, though missing details on return values.

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?

Concise, front-loaded with purpose, and no unnecessary words. Every sentence adds value, and structure is logical.

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 complexity and absence of output schema, the description covers purpose, parameters, usage context, and sibling tools. Lacks return value details but is otherwise complete for a creation tool.

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 coverage is 100%, and the description adds significant meaning beyond schema: defines enum-like values for pickup_type (0-4 with labels), explains order_num as display order within same type. Provides crucial semantic context.

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 registers a pickup setting for a specified product, enumerates parameters with their meanings, and distinguishes sibling tools (putProductPickup, deleteProductPickup). It is specific with verb+resource.

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?

Explicitly states when to use (add new product to store pickup slots) and when not to (use putProductPickup for changes, deleteProductPickup for removal). Provides clear context and 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 indicate destructiveHint=true (creating is a state change) and readOnlyHint=false. Description adds that the created object (with id) is returned, which is useful behavioral context beyond 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?

Two concise sentences covering purpose, return value, key parameters, and sibling references. No wasted words; front-loaded with essential info.

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 (many fields, nested object) and no output schema, the description adequately covers the core function and return. It mentions the most important parameters and points to siblings for other actions. Lacks error handling details but sufficient for an 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?

Description highlights key fields (name, price, sales_price, category_id_big, display_state) and explains their meanings (e.g., price=定価). Even though the schema has detailed descriptions per field, the description adds value by grouping and contextualizing the most important parameters.

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?

Description clearly states it creates a new product and returns the created object. It specifies verb (register), resource (product), and distinguishes from siblings by naming getProducts and updateProduct for other operations.

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?

Explicitly provides alternatives: listing uses getProducts, editing uses updateProduct. This guides the agent on when to use this tool vs siblings.

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 destructiveHint=true, suggesting destructive behavior, but the description only mentions changing display order, which is non-destructive. This contradiction misleads the agent. The description does not disclose any destructive effects beyond what annotations imply, and 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 a single paragraph, concise and front-loaded. Every sentence adds value: purpose, identification method, immutability of pickup_type, and links to sibling tools. 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?

Given schema coverage is 100% and no output schema, the description covers tool purpose, parameters, identification, and related tools. However, the destructiveHint annotation is not explained, leaving a gap in behavioral context. Still largely complete for a simple update tool.

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 provides 100% coverage with descriptions for all three parameters. The description adds key context that pickup_type is an identifier and cannot be changed, enhancing semantics beyond schema. This justifies above baseline of 3.

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 changes display order of existing pickup settings. It specifies the verb '変更する' and resource '既存ピックアップ設定の表示順', and differentiates from sibling tools postProductPickup (new) and deleteProductPickup (deletion).

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 explains when to use this tool (modify order for existing pickups) and mentions alternatives for create and delete. It also clarifies that pickup_type is an identifier and cannot be changed, guiding correct usage. Lacks explicit 'when not to use' but context is clear.

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 destructiveHint=true. The description confirms this by stating that after sending, the corresponding mail state is updated to 'sent'. It also adds constraints about split orders, which annotations do not cover.

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) and well-structured: purpose first, then parameter guidance, then post-condition, then constraints. No unnecessary 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?

Given the tool's complexity (2 parameters, nested object, no output schema, relevant siblings, and annotations), the description covers purpose, parameters, behavioral effects, and constraints completely.

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%, but the description explains that sale_id identifies the target order and the mail object specifies the type and options. It also suggests using getSales/getSale for listing/details, compensating for the lack of parameter 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 tool sends notification emails for orders (specifically 受注メール, 入金確認メール, 商品発送メール). It distinguishes from sibling tools like getSales (listing) and getSale (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 explains when to use the tool (to send emails for an order) and provides a constraint: for split orders, emails can only be sent to the parent order, not child orders. No direct alternative is mentioned, but the context is clear.

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 read-only, idempotent, non-destructive behavior. The description adds valuable context about the output structure (three aggregation groups) and the parameter's role, enhancing transparency beyond 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 concise (3 sentences) and front-loaded with the key output. Every sentence adds value: output summary, parameter usage, and limitations.

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 no output schema, the description explicitly details the return structure (amount_today, count_today, etc.) and covers parameter format, default, and limitations. It is complete for the tool's complexity.

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 coverage is 100% with detailed parameter description. The description adds extra context about using past dates and the default value, improving understanding of the parameter's flexibility.

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 aggregates sales into three periods (today, last 7 days, current month) based on a reference date. It explicitly mentions what it does not support (arbitrary ranges, breakdowns) and distinguishes from sibling tool getSales.

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 scenarios (progress check, yesterday's results, monthly sales) and clearly states when not to use it (when arbitrary date ranges or breakdowns are needed), directing users to getSales instead.

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 destructiveHint=true and idempotentHint=true, but the description adds critical context about the partial update (differential merge) behavior and the unit change for discount_amount with coupon_type. 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 front-loaded with the core purpose and efficiently conveys key usage constraints in a few sentences. While slightly dense, every sentence adds value and there is no redundancy.

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 with a nested object and multiple parameter interdependencies, the description addresses the most critical behavioral nuance (discount_amount-coupon_type coupling) and provides clear sibling differentiation. It does not cover return values (no output schema), but that is acceptable. The description is sufficiently complete for an update tool.

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?

The schema covers 50% of parameters with descriptions, but the description adds essential semantics beyond the schema: explaining that discount_amount units depend on coupon_type (yen vs %), that delivery_charge does not require discount_amount, and that group_ids are used only when group_limit_type is not 'none'. This compensates for the schema's lack of explicit dependency explanation.

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 performs a differential merge of existing coupon settings, specifying that only keys included in shop_coupon are updated while omitted keys remain unchanged. It also references sibling tools for creation, deletion, and retrieval, distinguishing itself effectively.

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?

Explicitly provides when-to-use guidance by naming createCoupon for new coupons, deleteCoupon for deletion, and getCoupon for current values. Also warns about the dependency between coupon_type and discount_amount when changing types, offering a clear exclusion.

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 a write operation (readOnlyHint=false, destructiveHint=true). The description adds context about the app dependency and the specific fields to update. No contradiction with annotations; the description effectively supplements them by detailing the required app setup.

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 a single paragraph with information front-loaded: purpose first, then parameters, then condition, then alternatives. Every sentence adds value, and there is no redundant 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?

The description lacks details about the response or error handling. For a mutation tool with no output schema, it would be helpful to know what the successful response looks like or whether updates are immediate. This gap prevents a higher score.

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 baseline is 3. The description explains the role of each parameter (customer_id for target, membership.membership_id for new rank ID) but does not add substantial meaning beyond what the schema already provides.

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: updating a customer's membership rank. It specifies the required parameters (customer_id and membership.membership_id) and distinguishes this tool from related siblings (deleteCustomerGroupMembership, getCustomer, updateCustomers) by mentioning their uses.

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: it only works for shops with the '会員ランク' app installed, and it directs users to alternative tools for removing membership or accessing other customer data. This helps the agent decide when to use this tool versus 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 indicate destructive, idempotent, and open world hints. The description adds behavioral details: partial patch (only included keys replaced) and scope (both members and non-members). No contradiction with annotations. The additional context is valuable but not exhaustive.

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 two sentences in Japanese, front-loaded with the main action, then provides behavioral details and sibling references. Every sentence earns its place with 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?

Given no output schema, the description lacks explicit return value information. However, it covers the key behavioral aspect (partial update) and references related tools for other operations. Adequate for a patch tool with good annotations.

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?

The input schema has descriptions for all parameters (though context says 50% coverage, the provided schema shows 100%). The description adds that customer_id identifies the target and only keys in 'customer' are replaced, but this is already implied by the schema structure. Minimal additional meaning 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 tool applies a partial patch to customer attributes, specifying the resource (existing customers, members and non-members) and the action (differential update). It also distinguishes from sibling tools like updateCustomerMembership and postCustomerPoints.

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 explicitly provides when to use this tool (for attribute updates) and when to use alternatives: membership rank changes -> updateCustomerMembership, point balance changes -> postCustomerPoints, viewing -> getCustomer, searching -> getCustomers. It also clarifies that only provided keys are updated, guiding correct 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 informs about the differential update behavior (only passed fields updated) and the ability to increment stocks via 'increment' field. These add value beyond annotations. However, annotations already indicate destructiveHint=true and readOnlyHint=false, and the description does not elaborate on potential side effects or data loss, leaving some behavioral aspects opaque.

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 a single paragraph that front-loads the main purpose and covers critical aspects (differential update, stock handling, category change, sibling tools) without verbosity. It could be structurally improved with bullet points, but remains efficient.

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 complexity with nested objects and no output schema, the description adequately explains core functionality and stock handling. However, it lacks details on response format, error conditions, permissions, or pagination (if any), which leaves some gaps for an agent invoking the tool.

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?

The description adds meaningful context for key parameters: stocks can be absolute or incrementable, category_id fields change category membership, and stock behaviour with variants is noted. The schema already has detailed descriptions for many parameters, but the description clarifies essential usage patterns 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 that this tool performs differential updates of product attributes identified by product_id. It explicitly distinguishes from sibling tools such as postProducts (create), updateProductCategory (category editing), and updateProductGroup (group configuration), providing a clear scope and avoiding ambiguity.

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 alternative tools for creation, category editing, and group updates. It explains how to change category membership via category_id fields. However, it does not specify prerequisites, restrictions, or when NOT to use this tool, which slightly reduces clarity.

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 discloses partial update semantics, meta tag HTML restrictions, and sort integer constraints, adding value beyond annotations. However, it does not mention permissions or reversibility, which are relevant for a destructive operation (destructiveHint=true). 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 concise, with every sentence serving a purpose. It front-loads the main action and uses clear structure.

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 nested parameter structure and lack of output schema, the description adequately covers input behavior (partial update), constraints, and references sibling tools. It could briefly mention error handling or return value structure but is otherwise complete.

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?

The description explains the partial update mechanism (only keys in 'category' are overwritten), which is critical for correct usage and not fully captured by the schema. It also reiterates constraints on meta tags and sort. Schema description coverage is 50%, so the description compensates well.

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 (partial update), resource (main category), and behavior (only specified keys overwritten). It also explicitly references sibling tools for child updates, creation, and listing, distinguishing its purpose.

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 when-to-use and when-not-to-use guidance by directing to sibling tools for child category updates, creation, and listing. This helps an agent avoid incorrect tool selection.

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 annotations already indicate readOnlyHint=false and destructiveHint=true, so the description does not need to restate those. However, it adds valuable behavioral context by explaining the differential update nature (only changed keys needed) and the HTML tag restriction on meta tags. This enhances transparency beyond what annotations provide.

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 a single well-structured paragraph in Japanese. It covers purpose, identification, call pattern, constraints, and sibling tool references in a compact form. Every sentence serves a purpose without redundancy.

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 there is no output schema, the description doesn't cover return values, but for an update tool, that is acceptable. It thoroughly documents input semantics, constraints, and alternatives. It is complete enough for an AI agent to understand how and when to invoke the 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?

The input schema provides descriptions for all parameters and nested fields, but the description adds crucial context: it explains that the category parameter should only contain the keys to be updated (differential update pattern). This is not evident from the schema alone. The schema coverage is high, so the description provides moderate additional value.

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 performs differential updates on child categories (small categories under a large parent category) for fields like name, sort, display_state, meta_tag. It specifies how to identify the target using category_id and id, and mentions constraints such as HTML tags not allowed in meta tags. This distinguishes it from sibling tools like createProductCategoryChild and updateProductCategory.

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 explicitly tells when to use alternatives: for new creation use createProductCategoryChild, for parent updates use updateProductCategory, and for listing use getProductCategories. It also advises to pass only the keys you want to update in the category object, providing clear usage 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 indicate readOnlyHint=false and destructiveHint=true; the description adds that updates are partial (only keys passed in group are affected) and that product membership is excluded. This provides useful behavioral context beyond the 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 concise, using multiple sentences to front-load purpose and scope, with no wasted words. It efficiently includes alternative tool references.

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 partial update nature and lack of output schema, the description comprehensively covers what the tool does, what it doesn't do (product membership), and directs to related tools for other actions.

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 coverage is 50% (group object lacks top-level description); the description compensates by explaining partial update semantics and listing the updatable fields. It clarifies that only keys in 'group' are updated, which is not evident from the schema alone.

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 performs partial updates to product group settings (name, display_state, meta_tag, expl) and explicitly distinguishes from sibling tools: createProductGroup for creation, getProductGroup for reading, and updateProduct for managing product membership.

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: use this tool only for group attributes, not product membership; for product membership, refer to updateProduct. Also mentions creation and reading tools.

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 behavioral details beyond annotations: it explains that only specified fields are updated (partial update) and that updating noshi, message card, or wrapping fee may trigger automatic payment adjustments. Annotations already indicate destructive and idempotent behavior, so the description supplements well.

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 with three sentences, front-loading the main purpose, then specific behaviors, and finally alternative tools. Every sentence adds value without redundancy.

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 complex nested schema and multiple sibling tools, the description covers the primary use cases, important behaviors (auto-charge), and links to alternative tools. It lacks some detail on parameters like point_state or sale_deliveries, but provides sufficient context for an AI to decide when to use this tool.

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?

The description adds meaning to parameters: it explains that sale_id identifies the target and that only fields in the `sale` object are replaced. It specifically mentions that updating noshi, card, and wrapping fields can trigger auto-charge/refund. While the schema has descriptions for nested properties, the top-level parameters lack descriptions, but the description compensates well.

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 is for updating sale information after order confirmation, listing specific use cases like address correction, memo addition, status transition, and fee adjustment. It explicitly distinguishes from siblings by mentioning cancelSale for cancellation, getSale for details, and sendSalesMail for email.

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 context: used after order confirmation, target identified via sale_id, and only passed fields are replaced. It warns about automatic charges for certain payment methods and gives clear alternatives for related tasks.

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 destructiveHint=true and idempotentHint=true. The description adds valuable context about automatic history recording and parent template update_date being updated, enhancing understanding of side effects beyond what annotations provide.

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 three well-structured sentences, front-loaded with the main purpose. It is concise but covers necessary details without redundancy.

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?

The description explains the outcome (source update, history, parent update) but does not mention the return value or success indicator. Since there is no output schema, the description could be more complete by stating what the tool returns upon success or failure.

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 schema coverage at 67%, the description adds meaningful context: it specifies that template_page contains new HTML/CSS content, page_type uses the same enum as getTemplatePage, and template_id identifies the template. This adds value 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 it updates HTML/CSS source for a specified template page type, and distinguishes from related tools like getTemplatePage, getTemplatePreview, and getTemplates by explicitly mentioning them as alternatives for different operations.

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?

It provides clear context for when to use this tool (to update template page source) and mentions viewing alternatives. However, it does not explicitly state when not to use it or provide exclusion criteria beyond referencing siblings.

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