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

Annotations already cover key behavioral traits (read-only, non-destructive, idempotent, closed-world), but the description adds valuable context beyond this. It clarifies the tool's role in a workflow ('Standalone analysis tool'), its output scope ('bird's-eye view'), and that it's for market intelligence rather than supplier details. No contradictions with annotations are present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (e.g., 'USE WHEN', 'WORKFLOW', 'RETURNS', 'NOTE'), front-loading key information. Every sentence adds value, such as usage scenarios, workflow integration, and output details, with no redundant or verbose content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (market analysis with one parameter) and the absence of an output schema, the description provides comprehensive context. It details the return structure, usage guidelines, workflow integration, and distinctions from sibling tools, making it complete enough for an AI agent to understand and invoke the tool effectively.

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 100% description coverage for its single parameter ('product'), so the baseline is 3. The description adds semantic context by specifying the parameter's purpose ('Product category to analyze') and providing examples ('e.g. sportswear, denim, underwear') in the schema, which enhances understanding beyond the basic schema definition.

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: 'Market overview and analysis for a product category in China.' It specifies the verb ('analyze'), resource ('market'), and scope ('product category in China'), distinguishing it from sibling tools like search_suppliers or recommend_suppliers that focus on specific suppliers rather than market intelligence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidelines in the 'USE WHEN' section, listing scenarios like user queries for market overviews or pre-sourcing intelligence. It also distinguishes when to use this tool versus alternatives, explicitly stating to use it 'BEFORE search_suppliers' and noting it's for 'an overview, not specific suppliers,' with clear alternatives named (search_suppliers, recommend_suppliers).

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, indicating a safe, non-destructive operation. The description adds valuable behavioral context beyond annotations: it explains the return structure, error conditions (supplier_id not found), and important nuance about incomplete compliance data ('Missing data = "not confirmed", not "non-compliant"'). This goes 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 well-structured with clear sections (purpose, usage guidelines, prerequisite, workflow, returns, errors, note). Every sentence earns its place by providing essential information without redundancy. It's appropriately sized for a tool with complex behavioral nuances.

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 (compliance checking with data completeness issues), the description provides excellent contextual completeness despite no output schema. It explains the return structure, error conditions, and important behavioral nuances about incomplete data. Combined with comprehensive annotations, this gives the agent everything needed to use 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?

Schema description coverage is 100%, with both parameters clearly documented in the schema. The description doesn't add significant parameter semantics beyond what the schema provides (e.g., it doesn't explain format of supplier_id beyond 'from search_suppliers' or elaborate on enum values). Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verb ('Check') and resource ('supplier compliance requirements for a target export market'). It distinguishes from siblings like search_suppliers (which finds suppliers) and get_supplier_detail (which provides general info) by focusing specifically on export compliance verification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidelines with 'USE WHEN' examples (e.g., user asks about export eligibility), a clear prerequisite ('MUST have a valid supplier_id from search_suppliers'), and a workflow sequence ('search_suppliers → check_compliance'). It also distinguishes when NOT to use it (when you don't have a supplier_id).

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable behavioral context beyond annotations: it specifies the return format ('{ count: number, data: [full cluster objects with all fields] }'), error handling ('Returns 400 if more than 10 IDs. Missing IDs are silently skipped'), and constraints ('Max 10 cluster IDs per call'). This enriches the agent's understanding of the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose. Each section (PREREQUISITE, USE WHEN, RETURNS, ERRORS, CONSTRAINT) adds essential information without redundancy. The Chinese translation at the end is concise and does not detract from clarity. Every sentence earns its place by providing actionable guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (one parameter, no output schema), the description is complete. It covers purpose, prerequisites, usage context, return format, error handling, constraints, and includes a workflow example. With annotations providing safety and idempotency hints, and the schema fully documenting the parameter, no critical information is missing for effective tool use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'cluster_ids' fully documented in the schema. The description adds minimal semantic value beyond the schema, only reiterating 'max 10' and noting IDs must come from 'search_clusters'. Since the schema already covers parameter details adequately, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Compare multiple Chinese apparel industrial clusters side-by-side on key metrics.' It specifies the verb ('compare'), resource ('industrial clusters'), scope ('Chinese apparel'), and distinguishes it from siblings like 'search_clusters' (which finds clusters) or 'analyze_market' (which analyzes markets rather than comparing clusters).

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 WHEN user wants to evaluate or choose between 2-10 specific clusters' and 'PREREQUISITE: You MUST first call search_clusters to obtain valid cluster_ids.' It also names the alternative ('search_clusters') and outlines a workflow ('search_clusters → collect cluster_ids → compare_clusters'), clearly differentiating when to use this tool versus others.

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

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

The description adds valuable behavioral context beyond annotations. Annotations indicate read-only, non-destructive, idempotent, and closed-world operations, but the description details constraints ('Max 10 supplier IDs per call'), error handling ('Missing IDs are silently skipped'), and return format ('{ count, data: [full supplier profiles with all fields] }'), enhancing the agent's understanding of tool behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and concise, using bullet points and clear sections (e.g., USE WHEN, PREREQUISITE, WORKFLOW, RETURNS, ERRORS, CONSTRAINT, DIFFERENCE). Each sentence adds essential information without redundancy, making it easy to scan and understand.

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 and lack of output schema, the description provides comprehensive context: it explains the purpose, usage, prerequisites, workflow, return format, error handling, constraints, and differentiation from sibling tools. This compensates for the missing output schema and ensures the agent has sufficient information to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'supplier_ids' fully documented in the schema. The description reinforces this by mentioning 'supplier_ids from search_suppliers' and the max limit of 10, but does not add significant semantic details beyond what the schema provides, aligning with the baseline score for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Compare multiple suppliers side by side on all dimensions.' It specifies the verb ('compare'), resource ('suppliers'), and scope ('multiple', 'side by side', 'all dimensions'), distinguishing it from sibling tools like get_supplier_detail, which returns a single supplier with verified_dimensions breakdown.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidelines: it lists example user queries (e.g., 'compare these 3 factories'), specifies prerequisites ('MUST have valid supplier_ids from search_suppliers'), outlines the workflow ('search_suppliers → collect supplier_ids → compare_suppliers'), and distinguishes when to use this tool vs. alternatives ('Use this instead of calling get_supplier_detail in a loop').

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable behavioral context beyond annotations: it explains the data source ('every record is enriched with AATCC / ISO / GB lab test data'), return limits ('Returns up to 50 records'), error behavior ('Returns count=0 if no discrepancies above threshold'), and the constraint about requiring both declared and tested 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 well-structured with clear sections (core feature, usage examples, data context, returns, workflow, errors, constraints, Chinese translation). Most sentences earn their place by providing specific guidance or context. Some redundancy exists between the English and Chinese versions, but overall it's efficiently organized with front-loaded key 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 (discrepancy detection across multiple data types), the description provides comprehensive context despite no output schema. It fully explains what the tool does, when to use it, behavioral characteristics, return format with examples, error conditions, and important constraints. The annotations cover safety and idempotency, and the description adds necessary operational context about data availability and limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, providing full documentation of both parameters. The description adds minimal parameter semantics beyond the schema: it lists the four field types in the returns section and mentions 'threshold' in the workflow note. However, it doesn't provide additional context about parameter usage or implications beyond what's already in the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Surface supplier specifications that deviate from independent lab measurements.' It specifies the verb ('detect/surface discrepancies') and resource ('supplier specifications vs lab measurements'), and distinguishes from siblings by emphasizing this is MRC Data's 'moat' feature with lab-test enrichment, unlike unaudited directory listings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance with a 'USE WHEN' section listing five specific query patterns, including multilingual examples. It states 'Standalone tool — does not require prior search' and clarifies when it won't work: 'Only works when both declared AND tested values exist for the same record. Many records have only one or the other.'

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 it's read-only, non-destructive, and idempotent. The description adds valuable context beyond this: it clarifies that estimates are based on database averages (not binding), mentions accuracy improvements with fabric_id, and describes the return structure. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, use cases, workflow, returns, constraints, notes). Each sentence adds value without redundancy, and key information is front-loaded. It efficiently covers multiple aspects in a compact format.

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 (cost estimation with multiple inputs), the description provides comprehensive context: purpose, usage guidelines, workflow integration, return values, constraints, and accuracy notes. With no output schema, the description effectively explains the return structure, and annotations cover safety aspects, making it complete for agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters well. The description adds some context by mentioning 'fabric price' and 'supplier pricing' as inputs, but doesn't provide additional syntax or format details beyond what the schema offers. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('estimate sourcing cost') and resources ('product based on fabric price, supplier pricing, and order quantity'). It distinguishes from siblings like 'search_fabrics' or 'get_fabric_detail' by focusing on cost estimation rather than data retrieval or analysis.

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 'USE WHEN' section provides explicit scenarios for when to use this tool (e.g., user asks for cost estimates, budgeting needs, or specific Chinese phrases). It also includes guidance on when to use alternatives ('Optionally use search_fabrics first') and clarifies constraints ('NOT binding quotes'), making it highly actionable.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it specifies that results exclude the original supplier, returns error if supplier_id not found, returns empty alternatives if none exist, and has a constraint of max 10 alternatives per call. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, USE WHEN, prerequisite, workflow, differences, returns, errors, constraint). Each sentence adds value without redundancy. It's front-loaded with the core purpose and usage scenarios, making it efficient for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (finding alternatives based on similarity), the description is complete. It covers purpose, usage, workflow, differentiation from siblings, prerequisites, return format (reference_supplier, alternatives, attribution), error handling, and constraints. With annotations providing safety hints and schema covering parameters fully, no output schema is needed as the description explains returns adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters (supplier_id, reason, province, limit) thoroughly. The description adds some context by mentioning 'optionally in a different province or with different attributes' (hinting at province parameter usage) and 'Max 10 alternatives per call' (relating to limit), but doesn't provide significant additional semantics beyond the schema. Baseline 3 is appropriate given high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool's purpose: 'Find alternative suppliers similar to a given supplier.' It distinguishes from siblings by specifying it starts from a known supplier_id (vs. recommend_suppliers which starts from product requirements, and search_suppliers which filters by criteria). The verb 'find' and resource 'alternative suppliers' are clear and specific.

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 under 'USE WHEN:' (e.g., user says supplier is too expensive/slow/far, needs backup options), a prerequisite (must have valid supplier_id from specific tools), workflow integration (search_suppliers → identify candidate → find_alternatives → compare_suppliers), and clear differentiation from recommend_suppliers and search_suppliers. This covers when to use, prerequisites, and alternatives comprehensively.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable context beyond annotations: it specifies the return structure (including sorting by quality_score), pagination behavior (has_more), and error handling (empty data if no suppliers). 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?

Well-structured with clear sections (purpose, use cases, prerequisite, workflow, returns, errors). Every sentence adds value—no redundancy or fluff. Front-loaded with the core purpose, followed by actionable details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (list operation with pagination), rich annotations (safety and idempotency covered), and 100% schema coverage, the description is complete. It adds necessary context like sorting, pagination indicators, and error cases, compensating for the lack of output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents cluster_id, limit, and offset. The description does not add parameter-specific details beyond what the schema provides (e.g., no extra syntax or format explanations). Baseline 3 is appropriate as the schema handles 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 the specific action ('List all suppliers') and resource ('in a specific industrial cluster'), distinguishing it from siblings like get_supplier_detail (individual supplier) or search_suppliers (general search). The title reinforces this with 'Get Cluster's Suppliers'.

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 examples (user queries about factories/suppliers in clusters), a prerequisite (must have cluster_id from search_clusters), and a workflow (search_clusters → pick cluster_id → get_cluster_suppliers). This clearly guides usage versus alternatives like search_suppliers or get_supplier_detail.

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 cover read-only, non-destructive, idempotent, and closed-world hints, but the description adds valuable behavioral context beyond this. It details the return structure (30+ fields with specific examples like 'lab-tested weight'), error conditions ('Returns error if fabric_id not found'), constraints ('Do not call in a loop'), and data availability ('Unverified fabrics return "not available"'). This enriches the agent's understanding 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 well-structured with clear sections (PREREQUISITE, USE WHEN, RETURNS, etc.) and front-loaded key information. However, it includes some redundancy (e.g., repeating 'lab-tested' and listing many field examples) and a duplicate Chinese translation at the end, slightly reducing efficiency. Most sentences earn their place by adding context or constraints.

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 (retrieving detailed fabric records) and lack of output schema, the description provides comprehensive context. It outlines the return data structure, error handling, usage constraints, and integration with sibling tools. This compensates for the missing output schema and aligns well with the rich annotations, making it complete enough for an agent to use effectively.

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 100% description coverage, clearly documenting the single required parameter 'fabric_id' as a string from search_fabrics. The description reinforces this by stating 'Fabric ID from search_fabrics results' and providing an example ('e.g. FAB-W007'), but adds no significant semantic details beyond what the schema already provides. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool retrieves 'the complete lab-tested record of a single fabric by ID,' specifying the verb ('get'), resource ('fabric'), and scope ('complete lab-tested record'). It distinguishes from sibling tools like search_fabrics (which lists fabrics) and get_fabric_suppliers (which focuses on suppliers), making the purpose highly specific and clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: 'USE WHEN user wants full specs on a specific fabric after search_fabrics identified it.' It also includes prerequisites ('MUST first call search_fabrics'), alternatives ('present search_fabrics summary results instead' for multiple fabrics), and workflow integration ('search_fabrics → pick fabric_id → get_fabric_detail'), leaving no ambiguity about proper 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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it specifies sorting by quality score, details the return structure (including fields like quality_score, price_rmb, moq), and notes that it returns count=0 if no suppliers are linked. This enhances 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 well-structured with clear sections (purpose, usage examples, prerequisite, workflow, returns, errors, and a Chinese summary). It is front-loaded with the core purpose and avoids redundancy. However, the inclusion of both English and Chinese versions slightly reduces conciseness, though each sentence earns its place by adding value (e.g., error handling details).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (one parameter, no output schema), the description is highly complete. It covers purpose, usage guidelines, prerequisites, workflow integration, return structure, and error conditions. With annotations providing safety and idempotency hints, and the description adding sorting behavior and output details, it leaves no significant gaps for an AI agent to understand 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?

Schema description coverage is 100%, with the single parameter 'fabric_id' fully documented in the schema as 'Fabric ID from search_fabrics, e.g. FAB-W007'. The description reinforces this by mentioning the prerequisite of having a fabric_id from search_fabrics, but does not add significant semantic details beyond what the schema provides. Thus, it meets the baseline of 3 for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'List all suppliers offering a specific fabric, sorted by quality score, with price comparison.' It specifies the verb ('List'), resource ('suppliers'), and scope ('offering a specific fabric'), and distinguishes it from siblings like 'get_supplier_detail' or 'compare_suppliers' by focusing on fabric-specific supplier listings with quality-based sorting and price comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidelines with 'USE WHEN' examples (e.g., user asks about suppliers for a fabric or price comparisons) and 'PREREQUISITE' (must have a valid fabric_id from search_fabrics). It also includes a 'WORKFLOW' section that outlines the sequence (search_fabrics → pick fabric_id → get_fabric_suppliers), clearly indicating when and how 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 already provide safety profile (readOnly, non-destructive, idempotent, closed-world). The description adds valuable behavioral context beyond annotations: it explains the ranking logic ('ranked by supplier count'), that it's a 'standalone discovery tool', and provides concrete examples of return format. 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?

Well-structured with clear sections (description, usage guidelines, workflow, returns, note). Every sentence adds value: the first sentence establishes core purpose, subsequent sections provide practical guidance without redundancy. Front-loaded with the most important 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 moderate complexity (1 parameter, no output schema), the description provides complete context. It covers purpose, usage scenarios, workflow sequencing, return format, and behavioral details. The combination of good annotations and comprehensive description makes this fully adequate for agent understanding.

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 the single parameter (province). The description doesn't add parameter-specific information beyond what's in the schema, but the baseline is 3 when schema coverage is high. The description does mention province_filter in the returns section, which reinforces the parameter's purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verb ('List') and resource ('product categories'), and distinguishes it from siblings by mentioning it's for discovery before using search_suppliers. It explicitly differentiates from search tools by stating it's for when users don't know what to search for.

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 guidance on when to use this tool ('USE THIS FIRST when: User doesn't know what to search for...') and when not to use it (implied: when user has specific search criteria). The WORKFLOW section explicitly names the alternative tool (search_suppliers) and describes the sequencing.

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, covering safety and idempotency. The description adds valuable context beyond annotations: it specifies the ranking order (provinces ranked by supplier count with typical leaders), describes the return structure in detail, and clarifies this is for discovery purposes. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, USE WHEN, WORKFLOW, RETURNS, NOTE), each sentence adds value, and it's front-loaded with the core purpose. No redundant information or wasted words, making it efficient for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (one optional parameter), rich annotations covering safety and idempotency, and no output schema, the description provides excellent completeness. It explains the purpose, usage scenarios, workflow integration, detailed return format, and behavioral notes like ranking, which compensates for the lack of output schema and gives the agent full context.

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 the single parameter (product_type), with the schema already documenting it as a filter for product type. The description doesn't add any additional parameter semantics beyond what's in the schema, but with high coverage, the baseline is 3. The description focuses more on output and usage 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's purpose with specific verb ('show') and resource ('supplier distribution across Chinese provinces'), distinguishing it from siblings like search_suppliers (which filters by province) or get_supplier_detail (which focuses on individual suppliers). It explicitly identifies the geographic scope and data type.

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 with a 'USE WHEN' section listing three specific scenarios (including Chinese phrases), a 'WORKFLOW' section explaining this is a standalone discovery tool to identify provinces before using search_suppliers, and clear differentiation from alternatives. It tells both when to use it and how it fits into a broader workflow.

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, non-destructive, idempotent, and closed-world behavior. The description adds valuable context beyond this: it notes that only verified + partially_verified records are included (unverified reserve data excluded), and clarifies the dynamic nature versus static resources. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (DESCRIPTION, USE WHEN, WORKFLOW, RETURNS, NOTE, DIFFERENCE, 中文). It is front-loaded with the core purpose and efficiently covers key points without redundancy, though slightly longer due to bilingual content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 0 parameters, rich annotations, and no output schema, the description provides comprehensive context: it explains what the tool does, when to use it, behavioral details (e.g., record inclusion rules), output structure, and differentiation from alternatives. This fully compensates for the lack of 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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on usage and output, not parameters, earning a high baseline score for not adding unnecessary information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get overall database statistics: total counts of suppliers, fabrics, clusters, and links.' It specifies the exact resources (suppliers, fabrics, clusters, supplier_fabrics) and distinguishes from siblings like database-overview resource by noting this provides dynamic counts versus static metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance is provided: 'USE WHEN user asks: "how big is your database", "what's the coverage", "data overview", "get_stats".' It also specifies when not to use it (e.g., for static metadata use database-overview, for per-product distribution use get_product_categories) and names alternatives clearly.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable context beyond this: it specifies the return structure (60+ fields, including verified_dimensions breakdown), error handling ('Returns error object if supplier_id not found'), and constraints ('Unverified suppliers return "not available for public access"'). It does not contradict annotations, but could mention rate limits or auth needs for a perfect score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (PREREQUISITE, USE WHEN, RETURNS, ERRORS, CONSTRAINT, WORKFLOW) and front-loaded key information. It is appropriately sized but includes some redundancy (e.g., repeating 'Chinese apparel supplier' and the Chinese translation adds length without critical value), preventing a perfect score.

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 (detailed supplier profile), the description is highly complete: it explains the return structure in detail (60+ fields, verified_dimensions), error cases, constraints, and workflow integration. With no output schema, this compensates fully. Annotations cover safety, and the single parameter is well-documented in the schema, making the description comprehensive for agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the single parameter 'supplier_id' well-documented in the schema. The description adds minimal semantics beyond this, only implying the ID comes from search results. Baseline 3 is appropriate since the schema does the heavy lifting, and the description does not add syntax or format details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'get' and resource 'complete profile of a single Chinese apparel supplier by ID,' distinguishing it from siblings like search_suppliers (which lists multiple) or compare_suppliers (which compares). It specifies the scope as 'single' and 'by ID,' making the purpose explicit 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?

The description provides explicit usage guidelines: 'USE WHEN user wants full details on a specific supplier already identified from search results,' with prerequisites ('MUST first call search_suppliers or recommend_suppliers'), workflow steps, and clear exclusions ('Do not call this for multiple suppliers in a loop — use compare_suppliers instead'). It names alternatives like compare_suppliers and get_supplier_fabrics.

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, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it specifies the return structure in detail, mentions the count=0 behavior for empty results, and clarifies that prices are supplier-specific quotes. However, it doesn't mention rate limits or authentication requirements.

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 efficiently structured with clear sections (purpose, usage examples, prerequisite, workflow, returns, errors) and zero redundant information. Every sentence serves a distinct purpose: the first states core functionality, subsequent sections provide practical guidance, and the Chinese translation adds localization without duplication.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only catalog tool with good annotations and no output schema, the description provides complete context: clear purpose, usage guidelines, prerequisite, workflow integration, detailed return structure, and error behavior. The combination of annotations (safety profile) and description (operational context) gives the agent everything needed to use this tool effectively.

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 a single well-documented parameter (supplier_id). The description reinforces the parameter's purpose by stating it's 'from search_suppliers' and providing example format 'sup_001', but doesn't add significant semantic value beyond what the schema already provides. Baseline 3 is appropriate given high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verb ('List all fabrics') and resource ('a specific supplier'), including the scope ('with quoted prices'). It distinguishes from siblings like get_fabric_detail (individual fabric) and search_fabrics (general search) by focusing on supplier-specific catalog retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance with 'USE WHEN' examples for three query patterns and a clear workflow sequence (search_suppliers → get_supplier_detail → get_supplier_fabrics). It also specifies a prerequisite ('MUST have a valid supplier_id') and mentions alternative tools (search_suppliers, get_supplier_detail) in the workflow context.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, but the description adds valuable behavioral context beyond this: it explains the ranking logic (prioritizes own-factory, then quality score, then capacity), describes error handling (returns empty data if no product match found), provides fallback guidance (try broader terms, limit to 3 calls), and specifies the return structure including ranking logic note. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (USE WHEN, WORKFLOW, DIFFERENCE, RETURNS, ERRORS, FALLBACK) and each sentence adds value. It could be slightly more concise by integrating some sections, but overall it's efficiently organized and front-loaded with key 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 and lack of output schema, the description provides comprehensive context: it explains the recommendation logic, distinguishes from siblings, outlines usage scenarios, describes the return format, error behavior, and fallback strategies. This compensates well for the missing output schema and aligns with the rich annotations provided.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add significant parameter-specific semantics beyond what's in the schema, though it implies the product parameter is central to the recommendation logic. This meets the baseline expectation when schema coverage is high.

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's purpose as 'Smart supplier recommendation based on sourcing requirements' and distinguishes it from siblings by explaining it's for ranking by fit rather than filtering by exact criteria like search_suppliers or finding alternatives from known suppliers like find_alternatives. This provides clear differentiation and a specific verb+resource combination.

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 includes explicit 'USE WHEN' scenarios with concrete examples, distinguishes when to use this tool versus search_suppliers and find_alternatives, and provides a 'WORKFLOW' section explaining it's the entry point for 'I need help finding a supplier' requests. It also mentions follow-up actions with get_supplier_detail or compare_suppliers.

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 valuable behavioral context beyond annotations: pagination behavior, return format details, error handling (empty array if no matches), fallback strategies, and language support (Chinese/English).

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?

Well-structured with clear sections (purpose, usage examples, coverage, returns, workflow, errors, fallback). Some redundancy exists (Chinese translation at end repeats purpose), but overall information density is high with minimal waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with comprehensive annotations and 100% schema coverage, the description provides excellent context: clear purpose, usage scenarios, example clusters, return format, pagination, error handling, fallback strategies, workflow integration with siblings, and language support. No output schema exists, but the description documents the return structure adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add significant parameter semantics beyond what's in the schema, though it provides context about specialization keywords through examples. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool searches for 'Chinese apparel industrial clusters and textile markets' with specific examples of what it covers. It clearly distinguishes from siblings like 'search_fabrics' or 'search_suppliers' by focusing on clusters rather than individual suppliers or materials.

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 'USE WHEN' examples with concrete user queries, lists famous clusters covered, and gives clear workflow guidance ('Use this to discover clusters. Then use compare_clusters...'). It also specifies fallback strategies and language support.

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, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it specifies pagination (max 50 per page, returns has_more), error handling (empty data array if no matches), constraints (returns summaries only), and usage limits (do not call more than 3 times for same question). This enriches the agent's understanding 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 well-structured with clear sections (USE WHEN, Filters, WORKFLOW, RETURNS, ERRORS, FALLBACK, CONSTRAINT, Chinese translation). It is appropriately sized for a search tool with many parameters and behavioral nuances. Some redundancy exists (e.g., 'Returns paginated fabric list' and RETURNS section), but overall, sentences earn their place by providing essential guidance and context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, search functionality) and rich annotations (readOnly, non-destructive, idempotent), the description is highly complete. It covers purpose, usage guidelines, behavioral traits (pagination, errors, constraints), and workflow integration with siblings. Although there is no output schema, the RETURNS section details the response structure, and the description compensates with comprehensive contextual information, making it fully adequate for agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all 8 parameters. The description lists filters (category, weight range, composition, etc.) but does not add syntax, format, or semantic details beyond what the schema provides. For example, it mentions 'category (woven/knit/nonwoven/leather/functional)' which mirrors the schema's description. Baseline 3 is appropriate as the schema handles parameter documentation effectively.

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: 'Search the Chinese fabric and textile database with lab-tested specifications.' It specifies the verb ('search'), resource ('Chinese fabric and textile database'), and scope ('lab-tested specifications'), distinguishing it from siblings like get_fabric_detail (full lab-test data) or get_fabric_suppliers (supplier information). The Chinese translation reinforces this 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 provides explicit usage guidance with 'USE WHEN' examples (e.g., user queries for specific fabrics or price ranges) and 'WORKFLOW' instructions (use as entry point, then call get_fabric_detail or get_fabric_suppliers). It also names alternatives (get_fabric_detail for full lab-test results) and includes fallback strategies (e.g., removing filters, limiting calls). This comprehensive guidance helps the agent select this tool appropriately.

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, covering safety profile. The description adds valuable behavioral context beyond annotations: pagination details (max 50 results per page, returns empty array if no matches), fallback strategies, usage limits (max 3 calls), and clarifies it's for filtering by exact criteria rather than recommendations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (USE WHEN, Filters, WORKFLOW, RETURNS, ERRORS, FALLBACK, NOTE) and every sentence adds value. It's appropriately sized for a complex tool with many parameters and workflow considerations, with 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?

For a complex search tool with 11 parameters and no output schema, the description provides comprehensive context: detailed return format specification, error behavior, pagination limits, workflow integration with get_supplier_detail, fallback strategies, and clear differentiation from sibling tools. It compensates well for the lack of 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?

With 100% schema description coverage, the schema already fully documents all 11 parameters. The description lists available filters (province, city, factory type, etc.) but doesn't add syntax or format details beyond what the schema provides. The baseline of 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for 'verified Chinese apparel manufacturers, apparel factories, and clothing suppliers' with specific resource scope. It distinguishes from siblings by explicitly naming 'recommend_suppliers' as an alternative for ranked recommendations, not filtering by exact criteria.

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 with example user queries, clear workflow guidance (primary entry point for discovery, then use get_supplier_detail), and explicit alternatives (use recommend_suppliers for ranked recommendations). It also includes fallback strategies and usage limits (max 3 calls for same question).

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