MRC Data — China's Apparel Supply Chain Infrastructure

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

Annotations cover safety (readOnlyHint=true, destructiveHint=false) and idempotency (idempotentHint=true), but the description adds valuable context: it specifies the tool's scope ('bird's-eye view'), clarifies it's 'standalone,' and notes it's for 'market landscape' understanding. No contradictions with annotations exist.

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

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

The description is well-structured with sections (DESCRIPTION, USE WHEN, WORKFLOW, RETURNS, NOTE), front-loaded key information, and every sentence adds value (e.g., clarifying when to use, alternatives, and output format). No redundant or wasted text.

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

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

Given the tool's moderate complexity, rich annotations, and lack of output schema, the description is complete: it explains purpose, usage, workflow, and details the return structure explicitly. This compensates for the missing output schema and provides sufficient context 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?

Schema description coverage is 100% for the single parameter 'product,' with the schema providing a clear description and example. The description does not add further parameter details beyond implying 'product category' in the opening line, so it meets the baseline of 3 without compensating for gaps.

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 ('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 under 'USE WHEN:' with specific scenarios (e.g., user asks about market in China, wants intelligence before sourcing) and exclusions (e.g., 'not specific suppliers'). It also names alternatives ('use search_suppliers after') and clarifies workflow ('Use this BEFORE search_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, idempotentHint=true, and openWorldHint=false. The description adds valuable context beyond annotations: it explains the return structure, error conditions, and importantly clarifies that 'Missing data = "not confirmed", not "non-compliant"' which is crucial behavioral information not captured in annotations.

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

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

The description is well-structured with clear sections (purpose, usage scenarios, prerequisites, workflow, returns, errors, note). Every sentence earns its place by providing essential information without redundancy. The information is front-loaded with the core purpose first.

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

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

Given the tool's moderate complexity, rich annotations, and 100% schema coverage, the description provides excellent contextual completeness. It explains the tool's purpose, when to use it, prerequisites, workflow, return structure, error handling, and important behavioral nuances about incomplete data. No output schema exists, so describing the return format adds value.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add additional parameter semantics beyond what's in the schema (supplier_id from search_suppliers, target_market as export market). 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 by focusing on compliance verification rather than searching, analyzing, or comparing 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?

The description provides explicit usage scenarios ('USE WHEN' with three bullet points), clear prerequisites ('MUST have a valid supplier_id from search_suppliers'), and workflow guidance ('search_suppliers → check_compliance'). It also distinguishes when not to use by requiring supplier_id from a specific sibling 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 declare readOnlyHint=true; description adds valuable behavioral context beyond safety: it discloses that full records are returned (not summaries) and enumerates specific comparison dimensions (labor cost, rent, supplier count, scale, specializations, key advantages, risks). Adds max parallelism constraint (10 clusters).

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?

Efficient four-sentence structure: purpose (sentence 1), usage trigger (sentence 2), return value specification (sentence 3), and Chinese summary (sentence 4). Front-loaded with action, zero redundant text, well-organized with explicit section header 'USE WHEN'.

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, but description compensates by detailing return content ('full records') and comparison metrics. Workflow context (post-search usage) is present. Single parameter is simple; no additional complexity requires explanation. Complete for the tool's scope.

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 clear description 'Array of cluster IDs to compare, max 10'. Description mentions 'cluster ID provided' and reinforces the 10-item limit in Chinese text ('最多 10 个'), but schema carries the primary semantic burden. Baseline 3 appropriate for high-coverage schemas.

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 specific action ('Compare multiple Chinese apparel industrial clusters side-by-side') and explicitly distinguishes from sibling search_clusters by positioning this as an evaluation step 'typically after search_clusters'. Clear 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?

Contains explicit 'USE WHEN' section specifying trigger conditions ('evaluate or choose between specific clusters they've identified'). Explicitly names sibling workflow dependency ('typically after search_clusters'), providing clear temporal sequencing 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 adds valuable behavioral context beyond annotations: it specifies a constraint ('Max 10 supplier IDs per call'), error handling ('Missing IDs are silently skipped'), and return format details ('RETURNS: { count, data: [full supplier profiles with all fields] }'). Annotations cover read-only, non-destructive, and idempotent aspects, but the description complements them without contradiction.

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

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

The description is well-structured with clear sections (e.g., USE WHEN, PREREQUISITE, RETURNS) and front-loaded key information. Every sentence adds value without redundancy, making it efficient and easy 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, rich annotations, and lack of output schema, the description is highly complete. It covers purpose, usage, prerequisites, workflow, returns, errors, constraints, and differentiation from siblings, providing all necessary context for effective tool invocation.

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

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

With 100% schema description coverage, the input schema already fully documents the single parameter 'supplier_ids'. The description adds minimal extra semantics by reinforcing the prerequisite ('from search_suppliers') and constraint ('max 10'), but doesn't provide significant 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's purpose with specific verbs ('compare multiple suppliers side by side on all dimensions') and explicitly distinguishes it from its sibling get_supplier_detail by noting it returns multiple suppliers at once for comparison versus one 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 with 'USE WHEN' examples, a clear prerequisite ('MUST have valid supplier_ids from search_suppliers'), a workflow sequence ('search_suppliers → collect supplier_ids → compare_suppliers'), and an explicit alternative ('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?

With readOnlyHint=true in annotations, the description appropriately adds behavioral context: it discloses the return format (up to 50 records), ranking logic (by discrepancy percentage), and data included (both declared and verified values). It also explains this is MRC Data's unique verification 'moat'.

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: core feature, trigger conditions, differentiation rationale, and technical specs. The Chinese translation serves a functional purpose for bilingual routing. While the 'moat' language is slightly promotional, it efficiently communicates unique value without excessive 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 the description appropriately explains return values (up to 50 ranked records with both values). It covers all 4 detectable discrepancy types and the threshold parameter. Given the analytical nature and good annotations, the description provides complete context for 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?

Despite 100% schema coverage, the description adds valuable semantic context by mapping abstract field names to business units: fabric_weight (gsm), fabric_composition (fiber %), supplier_capacity (monthly pcs). This helps the LLM understand parameter intent beyond the schema's enum descriptions.

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

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

The description clearly states the specific action (detect discrepancies) and resources (supplier-declared vs lab-verified values). It effectively distinguishes from retrieval-focused siblings by emphasizing cross-checking and verification capabilities, contrasting with 'generic B2B directories' that only show self-reported numbers.

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 explicit 'USE WHEN' section provides concrete query patterns (e.g., 'which fabrics have under-weight issues', 'fabric composition fraud', Chinese queries like '实测和声称差距') that precisely signal when to invoke this tool versus simple search or retrieval 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 read-only, non-destructive, and idempotent behavior, which the description does not contradict. The description adds valuable context beyond annotations: it notes that estimates are based on database averages (not binding), accuracy improves with specific fabric IDs, and it's a standalone tool with optional workflow integration. This enhances behavioral understanding without redundancy.

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, CONSTRAINT, NOTE), each sentence adds value without redundancy, and it's front-loaded with the core purpose. It efficiently conveys necessary information 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 a complete context: it explains the purpose, usage guidelines, workflow integration, return structure, constraints, and accuracy notes. With annotations covering safety and no output schema, the description compensates by detailing behavioral aspects and output expectations, ensuring the agent has sufficient information.

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

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal parameter-specific semantics beyond the schema, such as implying 'product' examples and noting 'fabric_id' for accuracy, but it doesn't detail parameter interactions or constraints. 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: 'Estimate sourcing cost for a product based on fabric price, supplier pricing, and order quantity.' It specifies the verb ('estimate'), resource ('sourcing cost'), and key inputs, distinguishing it from siblings like 'search_fabrics' or 'compare_suppliers' which focus on different aspects of sourcing.

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, including user queries and budgeting needs. It also names an alternative ('search_fabrics') for more accurate estimates and includes a 'CONSTRAINT' clarifying when not to use it (e.g., for binding quotes). This offers comprehensive guidance on usage 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 declare the tool as read-only, non-destructive, and idempotent, covering basic safety. The description adds valuable behavioral context beyond annotations: it specifies that results exclude the original supplier, mentions a maximum of 10 alternatives per call, describes error conditions (supplier_id not found, empty alternatives), and explains the return structure. This provides practical operational details that annotations alone don't 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?

The description is well-structured with clear sections (purpose, usage guidelines, differences, returns, errors, constraints) and uses bullet points for readability. While slightly longer than minimal, every sentence adds value (e.g., workflow explanation, sibling tool differentiation). It could be more concise by combining some sections, but the structure enhances clarity without significant waste.

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

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

Given the tool's moderate complexity (4 parameters, no output schema), the description is highly complete. It covers purpose, usage, prerequisites, workflow, differences from siblings, return values, errors, and constraints. With annotations handling safety aspects and schema covering parameters, the description fills all remaining gaps, making it fully self-contained 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?

With 100% schema description coverage, the input schema already fully documents all four parameters. The description doesn't add significant parameter-specific semantics beyond what's in the schema—it mentions 'different attributes' and 'different province' which loosely relate to 'reason' and 'province' parameters, but doesn't provide additional syntax, format, or usage details. This meets the baseline expectation when schema coverage is complete.

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 a specific verb ('find') and resource ('alternative suppliers similar to a given supplier'). It explicitly distinguishes this tool from sibling tools like 'recommend_suppliers' (which starts from product requirements) and 'search_suppliers' (which filters by criteria), providing clear differentiation.

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 through a 'USE WHEN' section with concrete scenarios (e.g., 'supplier is too expensive'), user queries in multiple languages, and a prerequisite statement. It also clearly explains differences from sibling tools ('recommend_suppliers' and 'search_suppliers') and outlines a workflow, 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 context beyond annotations: it specifies the return structure (including sorting by quality_score), pagination behavior (has_more field), and error handling (empty data if no suppliers). No contradictions with annotations exist.

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

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

The description is efficiently structured with clear sections (purpose, usage examples, prerequisite, workflow, returns, errors). Every sentence adds value—no redundancy or fluff—and key information is front-loaded, making it easy for an agent to parse quickly.

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, and 100% schema coverage, the description is highly complete. It covers purpose, usage, prerequisites, workflow, return format, sorting, pagination hints, and error cases, compensating for the lack of an output schema. No gaps remain for effective 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 each parameter well-documented in the schema (cluster_id, limit, offset). The description doesn't add significant semantic details beyond the schema, but it reinforces the cluster_id prerequisite and implies pagination through the returns section. Baseline 3 is appropriate given the comprehensive 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's purpose with a specific verb ('List') and resource ('suppliers in a specific industrial cluster'), distinguishing it from siblings like get_supplier_detail (detailed view) or search_suppliers (general search). It provides concrete examples that reinforce the 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?

Explicit guidance is provided with 'USE WHEN' examples, a 'PREREQUISITE' (valid cluster_id from search_clusters), and a 'WORKFLOW' sequence (search_clusters → pick cluster_id → get_cluster_suppliers). This clearly defines when to use this tool 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 indicate readOnlyHint=true, and description adds substantial behavioral context: enumerates 30+ specific return fields (weight, composition, color fastness, shrinkage, etc.), confirms lab-tested data source, and describes the payload comprehensively. Minor gap: doesn't specify error behavior for invalid IDs.

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?

Excellent structure: purpose statement → usage trigger → detailed return value specification → localization. Each section earns its place; the enumerated field list substitutes for missing output schema. Bilingual text is appropriate for the domain without being redundant.

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?

Thoroughly compensates for missing output schema by explicitly listing 30+ returned fields and their categories. Establishes clear relationship to search_fabrics sibling. For a single-parameter lookup tool, the description provides exhaustive context for successful invocation and result interpretation.

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% (fabric_id well documented with examples). Description mentions 'by ID' which aligns with schema but doesn't add additional semantic meaning, format constraints, or validation rules beyond the schema definition. Baseline 3 appropriate for high-coverage schemas.

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?

Clear specific verb 'Get' + resource 'lab-tested record of a single fabric' + scope 'by ID'. Explicitly distinguishes from search_fabrics sibling by specifying this retrieves a single record by ID versus searching.

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?

Contains explicit 'USE WHEN' directive stating exactly when to invoke (user wants full specs on specific fabric) and workflow context (typically after search_fabrics), clearly positioning it in the tool chain and indicating the prerequisite search step.

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?

With readOnlyHint already declaring this a safe read operation, the description adds valuable behavioral context including the sorting logic ('Sorted by supplier quality score') and the complete return payload structure ('company name, location, quality score, and that supplier's quoted price + MOQ'). It discloses the ranking algorithm so agents understand why results appear in a specific order. The score is 4 rather than 5 due to omitted details regarding pagination, rate limits, or behavior when no suppliers exist.

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

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

The description employs efficient section headers ('USE WHEN', 'Returns') to organize information hierarchically, with the core value proposition stated in the opening sentence. While it includes a Chinese translation that technically duplicates content, this serves legitimate localization purposes for bilingual contexts. The text avoids redundancy with structured schema data, though the explicit field listing in the Returns section slightly exceeds minimal necessary detail.

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?

Absent an output schema, the description effectively compensates by detailing the return structure (supplier records with company name, location, quality score, price, and MOQ) and explaining the sorting mechanism. For a single-parameter read-only tool, this coverage is sufficient for an agent to understand both the request and response contracts. It could achieve a 5 by specifying edge case behavior (empty results) or pagination capabilities.

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 provides complete coverage for the single fabric_id parameter with the description 'Fabric ID', establishing a baseline of 3 per the scoring guidelines. While the description references 'fabric fab_XXX' in usage examples, it does not elaborate on parameter semantics beyond what the schema already provides. Given the 100% schema coverage, the description appropriately focuses on behavioral aspects rather than compensating for parameter documentation.

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

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

The description uses the specific verb 'List' targeting 'suppliers offering a specific fabric', clearly defining the resource and action. It distinguishes from siblings like get_supplier_fabrics (inverse relationship) and get_fabric_detail by focusing on supplier discovery for a specific fabric. The explicit mention of 'sorted by quality score' and 'price comparison' further differentiates it from general supplier search tools.

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

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

The description includes an explicit 'USE WHEN' section with concrete user query patterns like 'who supplies fabric fab_XXX' and 'compare prices for [fabric]'. These examples provide clear guidance on when to select this tool versus alternatives such as get_supplier_detail (single supplier lookup) or search_suppliers (general search). The conditional triggers map directly to the tool's specific capability of listing suppliers for a given fabric 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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it explains the ranking logic ('Returns all categories ranked by supplier count'), the workflow role ('Standalone discovery tool'), and the return structure details. No contradictions with annotations exist.

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

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

The description is well-structured with clear sections (USE THIS FIRST, WORKFLOW, RETURNS, NOTE) and efficiently conveys essential information without redundancy. While slightly longer due to the structured format, every sentence adds value, and it's front-loaded with the core purpose.

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

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

Given the tool's low complexity (1 optional parameter), rich annotations covering safety and behavior, and no output schema, the description provides excellent contextual completeness. It explains the tool's role in workflows, return format, ranking logic, and usage scenarios, compensating 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?

Schema description coverage is 100% for the single parameter 'province', which is documented as 'Filter by province (e.g. guangdong, 广东)'. The description does not add any additional parameter semantics beyond what the schema provides, such as explaining when to use the province filter or its impact on results. With high schema coverage, 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 specific action ('List all product categories'), resource ('available in the database'), and scope ('with supplier counts'), distinguishing it from siblings like search_suppliers or get_supplier_detail. It explicitly differentiates by being a discovery tool for exploring what's available rather than searching for specific items.

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 THIS FIRST when: User doesn't know what to search for, User asks "what do you have", User needs to explore the database') and includes specific alternative workflows ('then use search_suppliers with a specific product_type'). It clearly distinguishes this as a standalone discovery tool versus other search-oriented 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 cover read-only, non-destructive, and idempotent behavior, so the description adds valuable context beyond that: it explains the ranking of provinces by supplier count (e.g., Guangdong typically leads) and describes the return structure in detail, including nested objects like top_cities. This enhances the agent's understanding of output behavior, though it doesn't mention rate limits or authentication needs.

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, RETURNS, NOTE), front-loaded with the core purpose, and every sentence adds value—no redundancy or fluff. It efficiently conveys usage scenarios, workflow integration, output details, and typical results 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 moderate complexity (one optional parameter), rich annotations, and no output schema, the description is complete: it explains the purpose, usage guidelines, workflow role, detailed return structure, and typical rankings. This compensates for the lack of output schema and provides sufficient context for an agent 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%, so the schema fully documents the optional product_type parameter. The description does not add any parameter-specific information beyond what the schema provides (e.g., no examples of product_type values or filtering effects), but it implies the tool can be used without parameters for general distribution. 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 a specific verb ('show') and resource ('supplier distribution across Chinese provinces'), distinguishing it from siblings like search_suppliers (which finds individual suppliers) or get_stats (which might provide broader statistics). It explicitly identifies the geographic scope and data focus.

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 (e.g., user asks about factory locations or needs to decide sourcing regions, including Chinese-language examples) and when not to use it (it's a 'standalone discovery tool' for identifying provinces, after which search_suppliers should be used for detailed supplier information). It clearly differentiates from alternatives like search_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 declare readOnlyHint=true indicating safe read operation. Description adds specific disclosure of what data is returned (the four count categories), providing necessary behavioral context beyond the safety annotation.

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?

Efficiently structured with purpose statement, usage guidance section, and bilingual support. Every sentence serves distinct function; no redundant or tautological content despite inclusion of Chinese translation.

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 zero-parameter aggregation tool without output schema, description adequately specifies return semantics by listing all four counted entities. Complexity level matches description depth appropriately.

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?

Zero parameters present with 100% schema coverage (trivially satisfied). Description appropriately focuses on return value semantics rather than input parameters, meeting baseline for zero-param tools.

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 uses specific verb 'Get' with clear resource 'database statistics' and enumerates exact scope (suppliers, fabrics, clusters, links). Distinct from siblings which focus on specific item retrieval/search rather than aggregate counts.

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?

Contains explicit 'USE WHEN' section with three specific query patterns ('how big is your database', 'what's the coverage', 'data overview') that clearly distinguish this from sibling search/detail 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 substantial behavioral context beyond the readOnlyHint annotation. It comprehensively lists the 50+ returned fields including specific certification standards (BSCI/OEKO-TEX/GRS/SA8000), ownership types, market access regions, and compliance frameworks (ZDHC/MRSL). This specific disclosure of data richness and structure significantly aids the agent in understanding what data payload to expect from this read operation.

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 front-loaded with the core purpose ('Get complete profile...'), followed by explicit usage guidance ('USE WHEN...'), detailed return value documentation, and a concise Chinese translation. The structure logically progresses from what, when, to outcome. No wasted sentences—every line adds unique value either for selection or invocation.

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 lacking an output schema, the description thoroughly compensates by enumerating the extensive field categories and specific data points returned (capacity types, equipment lists, certifications). It also maps the tool into the broader workflow context (post-search_suppliers usage), which is critical given the sibling relationships. Complete for a detail-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% (supplier_id fully documented with examples). Baseline is therefore 3. The description adds workflow context that the ID refers to a supplier 'already identified' from search results, which augments the raw schema definition. It doesn't elaborate on ID format/syntax beyond the schema's examples, but the contextual usage guidance provides meaningful semantic enhancement.

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?

Uses specific verb 'Get' with precise resource 'complete profile' and scope restriction 'single Chinese apparel supplier by ID'. Explicitly distinguishes from sibling search_suppliers (list/search vs. detail retrieval) through the 'USE WHEN' guidance referencing the typical post-search workflow. No ambiguity about what distinguishes this from get_supplier_fabrics or get_fabric_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?

Contains exemplary explicit guidance: 'USE WHEN user wants full details on a specific supplier already identified (typically after search_suppliers returns matches)'. Names the sibling alternative directly, clarifies the prerequisite state (post-search), and defines the trigger condition (full details needed). This is a model of clear when-to-use documentation.

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=true; description adds substantial return-value context: specific fields returned (fabric name, category, weight, composition, quoted price + MOQ) and the linkage model ('linked to the supplier'). 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 statement, USE WHEN triggers, return value specification, and Chinese translation. Front-loaded with the core action. Each sentence earns its place; bilingual support justifies the additional length.

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 operation, description comprehensively covers: query intent, expected return structure (fabric records with 6 specific fields), business context (quoted prices, MOQ), and trigger conditions. No output schema exists, but description adequately compensates.

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% (single parameter 'supplier_id' with description 'Supplier ID'). Description implies the ID format through example 'sup_XXX' in usage guidelines, but does not substantially augment the schema's semantic documentation. Baseline 3 appropriate given complete 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?

Excellent specificity: verb 'List' + resource 'fabrics' + scope 'a specific supplier can provide' + value-add 'with quoted prices'. Clearly distinguishes from sibling get_fabric_suppliers (inverse relationship) and get_fabric_detail (single item vs catalog).

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?

Exceptional 'USE WHEN' section provides four concrete trigger phrases including 'what fabrics does [supplier name] have' and 'show me the catalog of supplier sup_XXX'. Explicitly maps user intent to tool selection, eliminating ambiguity with inverse operation get_fabric_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?

The description adds valuable behavioral context beyond annotations: it explains the ranking logic (prioritizes own-factory, then quality score, then capacity), describes error behavior ('Returns empty data if no product match found'), provides fallback guidance ('try a broader product term'), and includes a usage limit ('Do not call more than 3 times for the same question'). This complements the annotations well without contradicting them.

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

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

The description is well-structured with clear sections (USE WHEN, WORKFLOW, DIFFERENCE, RETURNS, ERRORS, FALLBACK) that make it easy to scan. While somewhat lengthy, every section adds value. The front-loaded purpose statement is clear, and the structure helps organize the comprehensive information efficiently.

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 the absence of an output schema, the description provides excellent contextual completeness. It details the return format, ranking logic, error conditions, fallback strategies, usage limits, and differentiation from siblings. This compensates well for the lack of structured output documentation and provides a complete picture for the 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?

With 100% schema description coverage, the baseline is 3. The description doesn't add significant parameter semantics beyond what's in the schema, though it does provide context about the 'product' parameter through usage examples ('I need a factory for cotton t-shirts in Guangdong') and fallback guidance about broadening product terms.

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: 'Smart supplier recommendation based on sourcing requirements.' It distinguishes itself from siblings by explicitly contrasting with search_suppliers (which filters by exact criteria) and find_alternatives (which starts from a known supplier). The description specifies it ranks by fit rather than just 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?

The description provides explicit usage guidelines with a 'USE WHEN' section listing three specific scenarios, plus a 'WORKFLOW' section positioning it as the 'standalone entry point' for finding suppliers. It explicitly names when to use this tool versus search_suppliers and find_alternatives, and suggests 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 declare readOnlyHint=true, confirming safe read access. The description adds valuable behavioral context absent from annotations: it specifies pagination ('Returns paginated cluster list') and details the exact data fields returned (rent, labor costs, advantages/risks), compensating for the missing output_schema.

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?

Excellent information density with clear visual hierarchy: one-sentence purpose, bulleted use cases, named cluster examples, return value disclosure, and Chinese translation. Every sentence serves selection or invocation. 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 zero required parameters and no output schema, the description fully compensates by explaining what filtering dimensions exist (via USE WHEN examples) and detailing the return payload structure. The enumeration of famous clusters (Humen, Zhili, etc.) provides critical domain grounding for an AI to match user queries 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 coverage is 67% (4/6 params described). While the description doesn't explicitly map parameters, it provides rich semantic examples in the USE WHEN block (e.g., 'denim', 'womenswear', 'childrenswear') that implicitly clarify the 'specialization' and 'type' parameters. Standard pagination params (limit/offset) lack description but are conventionally understood.

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 opens with a specific verb-noun phrase ('Search Chinese apparel industrial clusters and textile markets') and immediately distinguishes scope from siblings like search_fabrics or search_suppliers by listing famous clusters it covers (Humen, Shaoxing Keqiao, etc.). The domain specificity (apparel/textile) is precisely bounded.

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, concrete trigger phrases ('where is China's [denim] manufacturing concentrated', 'recommend an industrial cluster for sourcing') that condition the model to invoke this tool versus alternatives like compare_clusters or search_suppliers. Including Chinese keywords ('服装产业带') further sharpens invocation criteria.

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=true; description adds valuable behavioral context including pagination ('Returns paginated fabric list'), data quality features ('declared+tested' comparison), and confidence levels that help the agent understand the unique lab-verified dataset.

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 distinct sections (purpose, USE WHEN, filters, returns, Chinese translation). Every section earns its place; bilingual support is appropriate for a Chinese database tool. Slightly dense but information-rich 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?

Despite lacking output schema, comprehensively describes return structure (name, tested weight, price range, confidence level). Implicitly signals all parameters are optional via 'Filters' language, though explicit 'all filters optional' statement would strengthen it.

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 75% with clear descriptions. The description adds semantic grouping ('Filters: category...weight range...') that maps parameters to user intents (e.g., 'target apparel type' for suitable_for parameter), though it omits explicit mention of pagination controls (limit/offset).

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?

Opens with specific verb+resource ('Search the Chinese fabric and textile database') and distinguishes from siblings like search_suppliers and search_clusters by emphasizing 'lab-tested specifications' and filterable fabric attributes (category, weight, composition).

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?

Excellent 'USE WHEN' section with 5 concrete example queries including Chinese commands (找面料), clearly signaling appropriate triggers. However, lacks explicit redirection to siblings (e.g., 'use search_suppliers for vendor queries') when this tool is inappropriate.

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=true. Description adds valuable context beyond annotations: discloses pagination ('Returns paginated supplier list'), specifies return fields (company name, location, declared+verified capacity), and notes data verification levels. Could be improved with rate limit or auth context, but solid for a search tool.

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 front-loaded purpose, clear 'USE WHEN' bullet section, filter summary, and return value description. Chinese translation adds value without clutter. Slightly verbose but earns its length through specific example coverage.

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 lacking output schema, description comprehensively compensates by detailing return structure (pagination, specific fields). Covers all 10 parameters via filter listing, explains verification/data confidence concepts, and addresses both English and Chinese use cases.

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 80%, establishing baseline 3. Description lists available filters ('province, city, factory type...') but largely repeats schema descriptions without adding syntax details, business logic, or parameter relationships. Schema already carries descriptive load 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?

Opens with specific verb 'Search' targeting clear resource ('verified Chinese apparel manufacturers, apparel factories, and clothing suppliers'). Effectively distinguishes from siblings like 'search_fabrics' and 'get_fabric_suppliers' by emphasizing apparel/clothing 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?

Excellent 'USE WHEN' section with six specific query patterns covering location, product types, certifications, and Chinese language queries. Provides concrete trigger phrases for the LLM. Lacks explicit 'when not to use' or named sibling alternatives (e.g., when to use get_supplier_detail instead), preventing a 5.

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