MRC Data — China's Apparel Supply Chain Infrastructure

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

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds valuable context: bird's-eye view, error handling (retries for 0 results, rate limit), and data source (MRC Data). 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 (USE WHEN, WORKFLOW, RETURNS, etc.), front-loaded with main purpose. Every sentence earns its place; no wasted words.

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

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

Despite no output schema, the description fully compensates by detailing the return structure (product, breakdowns, related_clusters). It covers prerequisites, errors, workflow, and links to other tools, making it complete for an analysis 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?

Both parameters are documented in the schema with 100% coverage. The description reinforces meaning with examples (e.g., 'sportswear') and demonstrates usage in examples. It adds value beyond the schema.

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

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

The description clearly states it provides 'Market overview and analysis for a product category in China' and distinguishes from siblings by warning against using for specific supplier lists or cluster details. It specifies the verb 'analyze' and resource 'market,' with explicit 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?

The description offers explicit 'USE WHEN' conditions, examples of user queries (including Chinese), and clear 'AVOID' instructions. It also suggests alternative tools like recommend_suppliers and search_clusters for different contexts.

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 the tool is read-only and idempotent. The description adds significant behavioral context: it explains the fusion of up to 5 weighted signals, confidence propagation, and clarifies that red flags are suspected inconsistencies, not definitive fraud findings, recommending human confirmation. This goes well 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 sections for USE WHEN, PREREQUISITE, RETURNS, and HOW IT WORKS. The inclusion of both English and Chinese adds length but serves multilingual users. While slightly long, every sentence provides necessary context, earning a 4.

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 single parameter and no output schema, the description adequately details the return object including fields like trust_score, confidence, signals, and red_flags. It explains the methodology and output interpretation. A score of 4 reflects that while not exhaustive, it covers the essential context for an AI agent.

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

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

With only one parameter and 100% schema description coverage, the schema already covers the basic meaning. The description adds value by specifying that the supplier_id must come from specific other tools (search_suppliers, etc.), providing context beyond the schema. A score of 4 is appropriate as it adds useful nuance.

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 that the tool assesses supplier credibility by fusing multiple signals into a 0-100 trust score, with checks for physical plausibility. It clearly distinguishes this from sibling tools like 'detect_discrepancy' or 'compare_suppliers' by specifying the fusion of multiple signals into a single score, making its unique purpose 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 a detailed 'USE WHEN' list with English and Chinese examples, and includes a prerequisite specifying where to obtain a valid supplier_id. However, it does not explicitly state when not to use this tool or compare it to sibling alternatives beyond the prerequisite, which prevents a score of 5.

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

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

Beyond annotations (readOnlyHint, idempotentHint), description adds critical behavioral context: return structure, data source (MRC Data), meaning of missing fields ('not confirmed' ≠ 'non-compliant'), rate limiting (429), and interpretation of incomplete data. All consistent 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 and front-loaded purpose. Slightly verbose due to many example queries and error scenarios, but every section adds value for an AI agent. Concise enough given the tool's complexity (multiple markets, error cases).

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

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

Despite no output schema, description explicitly lists return fields (supplier_id, company_name, overall_ready, etc.). Covers prerequisites, workflow, error handling, data limitations, and multi-language support. Complete for an evaluative compliance 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% (3 parameters all documented). Description reinforces each parameter with examples: supplier_id (pattern sup_001), target_market (enumerates us/eu/japan/korea with specific markets), verbose_hints (explains behavior). Go beyond schema by showing exact invocation examples.

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 checks whether a supplier meets compliance requirements for a target export market, with specific verbs and resources. It lists exact use cases (US/EU/Japan/Korea) and distinguishes from sibling tools like get_supplier_detail and find_alternatives.

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

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

Provides extensive when-to-use guidance, including specific user queries and Chinese examples. Clearly states prerequisite (supplier_id from search_suppliers/get_supplier_detail/recommend_suppliers), workflow, and explicit avoidance instructions. Also covers error self-correction patterns.

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

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

Discloses behavioral traits: returns full records, error handling for too many IDs, silent skips for invalid IDs, rate limit handling. Annotations (readOnlyHint, idempotentHint, destructiveHint) are consistent and description adds extra context beyond annotations.

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

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

Front-loaded with purpose, but lengthy with many examples and error handling. Every section is useful, but could be slightly more concise. However, the structure is logical and well-organized.

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

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

Given no output schema, description explains return format (full cluster objects with all fields), workflow, error handling, and constraints. Completely covers what an AI agent needs 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 coverage is 100%, but description adds example values for cluster_ids and explains verbose_hints parameter. Provides enough extra meaning beyond 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?

Clearly states it compares multiple Chinese apparel industrial clusters side-by-side on key metrics. Distinguishes from siblings like search_clusters (for getting IDs) and get_cluster_suppliers (for listing factories).

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

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

Explicitly says prerequisite to call search_clusters first, provides many example queries (English and Chinese), outlines a workflow, and states when not to use (e.g., don't guess IDs, don't use to list factories).

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

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

Annotations declare readOnlyHint, idempotentHint, destructiveHint. Description adds that invalid IDs are silently skipped, rate limit handling, max 10 IDs, and source of data, but does not contradict annotations.

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

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

Description is comprehensive but well-structured with clear sections (USE WHEN, PREREQUISITE, etc.). Some redundancy in examples, but front-loaded with 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?

Covers prerequisites, workflow, error scenarios, constraints, and even includes Chinese examples. No output schema needed as response is described as full profiles.

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

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

Schema coverage is 100% and both parameters are well-described in schema. Description adds examples and error handling but does not significantly augment the semantic 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 states 'Compare multiple suppliers side by side on all dimensions' with extensive examples and explicitly distinguishes from get_supplier_detail which returns a single supplier.

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 prerequisite (valid IDs from specific tools), workflow order, difference from get_supplier_detail, and explicit alternatives for finding new suppliers (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?

The description adds substantial behavioral context beyond the annotations, which already indicate read-only, idempotent, and non-destructive nature. It explains data constraints (requires both declared and tested values), limits (max 50 records), error handling (count=0, rate limit 429), and the underlying data source (MRC Data with AATCC/ISO/GB methods). 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 lengthy but well-structured with clear section headers, making it easy to navigate. While some repetition exists (e.g., constraint on both values exists in multiple places), every sentence adds value. It could be slightly more concise, but the structure compensates.

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

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

Given no output schema, the description thoroughly explains the return format with field names and deviation percentage. It covers edge cases (no records, partial data) and provides example calls. It also includes source attribution and methods, leaving no significant gaps for an AI agent 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?

The input schema has 100% description coverage, but the description enriches parameter understanding with examples (e.g., composition is exact-match), default behavior (min_discrepancy_pct defaults to 0), and field enumeration with Chinese translations. It goes beyond schema descriptions by providing context for each parameter's usage in queries.

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 core function: surfacing supplier specifications that deviate from independent lab measurements. It lists specific fields and provides numerous example user queries, differentiating it from sibling tools like search_fabrics and get_supplier_detail by emphasizing its role as a standalone audit tool.

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 extensive usage guidance, including a detailed 'USE WHEN' section with user query examples, a 'WORKFLOW' section explaining how to use the tool in sequence with others, an 'EXAMPLES' section with concrete calls, and an 'AVOID' section cautioning against common mistakes. It explicitly states that the tool does not require prior search and directs users to alternatives like 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?

Beyond annotations (readOnlyHint, idempotentHint), the description discloses important behavioral traits: estimates are non-binding, sourced from MRC Data, clarify fabric cost per meter, and handle rate limits with wait time. 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 lengthy but well-organized with clear sections (USE WHEN, WORKFLOW, RETURNS, EXAMPLES, ERRORS, AVOID, CONSTRAINT, NOTE). Every section adds value, but it could be slightly more concise.

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

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

Despite no output schema, the description includes a detailed 'RETURNS' structure. It covers workflow integration, error handling, multilingual support, constraints, and self-correction. It is complete for the intended use case.

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?

All 5 parameters are described in the schema (100% coverage). The description adds context like default quantity, fabric category options, and the note about fabric cost per meter (1-3m per piece). Examples show how parameters map to user queries.

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: 'Estimate sourcing cost for a product based on fabric price, supplier pricing, and order quantity.' It provides numerous use cases and distinguishes from siblings via the workflow hint ('estimate_cost → optionally search_fabrics first → then recommend_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?

Includes an explicit 'USE WHEN' section with specific query patterns, an 'AVOID' section, and guidance on when to use alternatives (e.g., 'search_fabrics first for accuracy'). Also provides error handling steps and self-correction strategies.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds significant behavioral detail: return structure {original_supplier, reason, alternatives, attribution}, sorting behavior by reason, max 10 alternatives, matches up to 3 product types, source attribution, and specific error handling. No contradictions with annotations.

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

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

The description is long but well-structured with clear sections (USE WHEN, PREREQUISITE, WORKFLOW, DIFFERENCE, RETURNS, EXAMPLES, ERRORS, AVOID, CONSTRAINT, NOTE, Chinese translation). Every section adds value. It is front-loaded with a concise summary. While verbose, the complexity of the tool justifies the 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?

Given no output schema, the description explicitly states the return structure. It covers all aspects: purpose, usage guidelines, parameter semantics, behavioral details, error handling, examples, and even Chinese localization. The tool has 5 parameters (1 required) and moderate complexity; the description is thorough enough to enable correct agent invocation without ambiguity.

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% (all parameters have descriptions in the schema). However, the description adds substantial value beyond schema: it explains the reason enum values in context (e.g., 'faster' sorts by lead_time_days.bulk_min ASC), provides examples mapping user complaints to parameter values, and clarifies constraints (limit max 10, province optional but narrows). This enriches understanding beyond raw schema.

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

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

The description clearly states the tool's purpose: 'Find alternative suppliers similar to a given supplier.' It specifies the verb 'find alternatives' and resource 'suppliers similar to a given supplier'. It explicitly distinguishes from sibling tools recommend_suppliers and search_suppliers by explaining differences.

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 extensive guidelines: it lists specific user utterances that trigger use, prerequisites (must have a valid supplier_id), workflow (search_suppliers → identify → find_alternatives → compare/check), differences from siblings, examples of correct invocation with parameter mappings, errors and self-correction steps, and explicit 'AVOID' instructions. This is exemplary 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?

Beyond annotations (readOnly, idempotent, not destructive), the description details sorting (quality_score DESC), pagination behavior, return structure (cluster_id, has_more, data), and source (MRC Data). It also covers error scenarios and rate limiting, providing comprehensive behavioral context.

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

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

The description is front-loaded with the primary purpose and well-organized into clear sections (use cases, workflow, examples, errors). While fairly long, each section serves a distinct purpose and enhances usability without unnecessary redundancy.

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

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

Given the lack of an output schema, the description adequately specifies the return shape (cluster_id, has_more, data sorted by quality_score). It also addresses error handling, prerequisites, workflow integration, and multilingual support (Chinese), leaving no critical gaps for an AI agent to correctly invoke the tool.

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

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

With 100% schema description coverage, the schema already fully describes all four parameters. The description adds marginal value through usage examples that illustrate typical values for limit, offset, and cluster_id, but does not significantly deepen understanding beyond the schema.

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

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

The description clearly states 'List all suppliers in a specific industrial cluster' and explicitly distinguishes from sibling tools like search_suppliers and compare_clusters, making its unique purpose unmistakable.

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' and 'AVOID' sections provide explicit usage contexts, common query patterns, and specific alternatives (e.g., search_suppliers for global search, compare_clusters for cluster comparison). The WORKFLOW guidance further clarifies its place in a multi-step process.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds extensive context: returns 30+ fields, error handling for 'Fabric not found', null fields, rate limiting (429 with 60s wait), and source details. This goes well beyond the annotations.

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

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

The description is well-structured with clear sections (PREREQUISITE, USE WHEN, WORKFLOW, RETURNS, EXAMPLES, ERRORS, AVOID, NOTE, 中文). While comprehensive, some redundancy exists (e.g., repeated mentions of field types). It is 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 complexity of the tool (returns 30+ fields, no output schema), the description compensates by listing the categories of returned fields, describing the response structure, covering error states, and providing a workflow context. It is fully adequate for an agent to understand and 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 coverage is 100% with clear parameter descriptions. The description adds value by explaining the prerequisite for fabric_id (must come from search_fabrics), providing example IDs, and elaborating on verbose_hints with usage context. This justifies a score above the baseline of 3.

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

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

The description clearly states it retrieves the complete lab-tested record of a single fabric by ID. It distinguishes itself from sibling tools like search_fabrics and get_fabric_suppliers by specifying its unique role in the workflow.

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

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

The description explicitly states the prerequisite to call search_fabrics first, provides a detailed list of user queries that trigger this tool, and outlines a workflow (search_fabrics → get_fabric_detail → optionally get_fabric_suppliers or detect_discrepancy). It also includes clear 'AVOID' guidance on when not to use it.

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

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

Discloses sorting behavior, return structure, error handling, rate limiting, and self-correction strategies, adding context beyond annotations that already declare readOnlyHint and idempotentHint.

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 sections like USE WHEN, PREREQUISITE, EXAMPLES; front-loaded with core action. Slightly lengthy but all content earns its place.

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

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

Despite no output schema, description explains return format, prerequisites, workflow, error handling, and provides examples, making it self-contained for correct 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?

Schema coverage is 100%, and description adds examples, meaning, and usage hints for both parameters (fabric_id with example, verbose_hints with explanation), enriching semantic understanding.

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 states 'List all suppliers offering a specific fabric, sorted by quality score, with price comparison' and distinguishes from sibling tools like search_suppliers and get_supplier_fabrics.

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

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

Explicitly lists use cases, prerequisites (fabric_id from search_fabrics), workflow, and what to avoid, providing strong guidance for agent decision-making.

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, destructiveHint, idempotentHint. Description adds that results are ranked by supplier count, data source is MRC Data, and includes error handling for empty data, invalid province, and rate limits.

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 (main description, USE THIS FIRST, WORKFLOW, etc.) and front-loaded key purpose. Slightly verbose but each section earns its place.

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

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

Completely describes return format (total_categories, province_filter, data array), ordering, error handling, data source, and provides sufficient examples. No output schema, so description carries full burden.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by explaining that province accepts English or Chinese (normalizeProvince handles both), and provides multiple examples showing parameter usage.

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 'List all product categories available in the database with supplier counts', uses a specific verb and resource, and distinguishes from siblings like get_province_distribution (geographic insight) and search_suppliers (follow-up).

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 specifies when to use ('USE THIS FIRST when: ...'), what to avoid ('Do not call this before every search'), and provides workflow alternatives (get_province_distribution, analyze_market).

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 and idempotent. Description adds return structure, ranking criteria, data source, error handling (rate limits, empty data, sparse results), and self-correction strategies. 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 headers like USE WHEN, WORKFLOW, RETURNS, EXAMPLES, ERRORS & SELF-CORRECTION, AVOID, NOTE. Front-loaded with purpose. Every section adds value, no wasted words.

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

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

Despite no output schema, description provides return structure. Covers usage, errors, examples, and notes. Complete for a read-only discovery tool with good annotations and comprehensive description.

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

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

Schema coverage is 100% with descriptions for both parameters. Description enriches meaning with examples, how to use product_type, and explains verbose_hints effect. Goes well beyond schema baseline.

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

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

Description clearly states it shows supplier distribution across Chinese provinces. It distinguishes from siblings like search_clusters and provides specific use cases with examples.

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 'USE WHEN' list with concrete user queries, 'AVOID' section for when not to use, and workflow suggestions for follow-up tools. This provides excellent guidance for tool selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds context: returns dynamic live counts with generated_at, only includes verified/partially_verified records, and specifies error behavior (retry on zero counts, wait on 429). No contradiction with annotations.

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

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

Description is well-structured with clear sections (USE WHEN, WORKFLOW, DIFFERENCE, RETURNS, EXAMPLES, ERRORS, AVOID, NOTE) but is quite verbose, including a long list of query examples and Chinese translation. Each sentence earns its place, but could be more concise.

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

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

Despite no output schema and only one optional param, the description covers returns format, examples, error handling, data scope (verified only), and relationship to other tools. It is fully complete for an agent 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 coverage is 100% (one optional param 'verbose_hints' fully described). Description does not add further parameter meaning beyond the schema. Baseline 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 gets overall database statistics (total counts of suppliers, fabrics, clusters, links). It lists many user query patterns and distinguishes from the database-overview resource and other tools like get_product_categories, making the purpose specific and unambiguous.

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

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

Description provides explicit USE WHEN scenarios, AVOID instructions, WORKFLOW guidance (call first for scale questions, then deeper tools), and ERROR handling with retry logic. This is comprehensive guidance for when and how to use the tool.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. Description adds significant behavioral context: workflow, error handling and self-correction (e.g., 'Supplier not found' → re-run search_suppliers), rate limiting (429 → wait 60s), data sourcing (MRC Data), and field meanings. No contradictions.

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

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

The description is long but well-structured with clear sections (USE WHEN, RETURNS, EXAMPLES, ERRORS & SELF-CORRECTION, AVOID, NOTE, 中文). Every sentence adds value. Could be slightly more concise, but the organization compensates. Front-loaded with purpose.

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

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

Given the tool's complexity (60+ fields, many sibling tools), the description is remarkably complete. Covers prerequisites, use cases, examples, error handling, workflow, language support, and data provenance. Output schema is missing but description explains return structure with example fields. No gaps identified.

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% (both parameters described in schema). Description adds value beyond schema: explains supplier_id must come from prior search results, and verbose_hints adds interpretation annotations. Also describes rich return structure (60+ fields). Baseline 3 exceeded by adding 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 it gets the complete profile of a single Chinese apparel supplier by ID. It distinguishes from sibling tools like search_suppliers (which returns a list) and compare_suppliers (which does side-by-side comparison). It lists specific user intents and example queries, reinforcing purpose.

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

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

Explicitly states prerequisite: must first call search_suppliers or recommend_suppliers. Provides detailed when-to-use scenarios (e.g., 'tell me more about supplier', 'what certifications'). Also includes when-not-to-use: avoid looping, browsing, or guessing IDs. Workflow and alternatives are clearly outlined.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds: returns data structure, possible errors (count=0, supplier not found, rate limit 429) with self-correction guidance, data source note, and that prices are not binding offers.

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 sections: overview, usage triggers, prerequisites, workflow, examples, errors, avoidance, note. Slightly long but each part earns its place. Front-loaded with 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?

No output schema, but description provides full return structure and error handling. With 2 params and complex error cases, the description is comprehensive and leaves little ambiguity.

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 both parameters described. Description provides examples and clarifies supplier_id origin, and explains verbose_hints effect. Baseline 3, but added value justifies 4.

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

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

The description clearly states it lists fabrics a supplier can provide with quoted prices. It specifies the resource (supplier's fabric catalog) and verb (list). Explicitly distinguishes from siblings like search_fabrics and 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?

Includes extensive guidance: when to use (with specific user queries), prerequisite (must have supplier_id), workflow (search_suppliers → get_supplier_detail → get_supplier_fabrics), and when NOT to use (avoid for general fabric search or cross-supplier comparison, with alternatives named).

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, idempotentHint=true, destructiveHint=false, so the tool is safe. Description adds significant behavioral context: ranking logic (own_factory > quality_score > declared_capacity_monthly), data source (MRC Data), return structure including 'note: ranking logic', error/self-correction strategies (e.g., drop province, broaden product), rate limit handling (429 wait 60 seconds), and empty result fallback. 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 long but well-structured with headings (USE WHEN, WORKFLOW, DIFFERENCE, RETURNS, EXAMPLES, ERRORS & SELF-CORRECTION, AVOID, NOTE). Each section serves a clear purpose. While not concise, the structure makes it scannable and the content earns its length. Minor redundancy (ranking mentioned in two places) could be trimmed.

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

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

Despite no output schema, the description explicitly states the return structure: '{ query, total_matches, showing_top, note: "ranking logic", data: [supplier objects] }'. It covers entry points, workflow with downstream tools, error handling, and ranking details. Given the tool's complexity (ranking, multiple inputs, fallback logic), this description is comprehensive.

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 good descriptions for each parameter. The description adds value through example mappings (e.g., user query to parameter values), explanation of the type enum (prefer factory vs. trading company), and context for verbose_hints. The examples provide practical guidance on how to set parameters based on user input, which goes beyond the schema's description.

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

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

The description clearly states the tool's purpose: 'smart supplier recommendation based on sourcing requirements.' It specifies the verb 'recommend,' the resource 'suppliers,' and the context 'sourcing requirements.' It explicitly distinguishes from siblings like search_suppliers and find_alternatives by contrasting ranking vs. filtering and starting point.

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?

Extensive usage guidelines with example user queries in English and Chinese, a workflow section linking to downstream tools, explicit differences from search_suppliers and find_alternatives, and an 'AVOID' section listing when not to use. This provides clear context for selecting this tool over 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral details such as pagination, rate limit handling (wait 60s), self-correction strategies for empty results, and data source attribution. No contradictions with annotations.

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

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

The description is long but well-structured: it starts with purpose, then use cases, examples, workflow, error handling, and avoidance. It is front-loaded with key information. While comprehensive, it could be slightly more concise, but the structure is clear.

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 tool with 7 parameters and no output schema, the description provides extensive context: return format, pagination details, error handling steps, and examples. It fully compensates for the lack of an output schema and addresses complexity 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?

The input schema has 100% description coverage for all 7 parameters. The description adds extra value by showing usage patterns, example values (e.g., specialization: 'denim', scale: 'mega'), and synonyms for Chinese/English terms. This goes beyond the schema, justifying a 4 instead of baseline 3.

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

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

The description clearly states it searches Chinese apparel industrial clusters and textile markets. It provides specific verbs and resources, and distinguishes from sibling tools like compare_clusters and search_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 explicitly lists when to use the tool with example user queries, and specifies when not to use it (e.g., for specific factory search). It also provides workflow guidance and example interactions.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds significant behavioral context: it returns summaries only, mentions rate limiting (429 with 60s wait), and provides error handling steps (empty data response). There is 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, Filters, WORKFLOW, RETURNS, EXAMPLES, ERRORS, AVOID, CONSTRAINT). It is slightly verbose but every section contributes to clarity. Some redundancy between English and Chinese text exists but does not detract significantly.

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 (9 parameters, no output schema), the description is exceptionally complete. It covers return structure, pagination, error handling, workflow chaining, and even provides Chinese language examples. The description leaves no ambiguity about tool behavior or usage.

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

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

Schema coverage is 100% with descriptions for all 9 parameters. The description adds value by providing usage examples, explaining the composition keyword normalization (TYPO_MAP), and showing how filters combine. While the schema already documents parameters well, the examples enhance understanding.

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 a Chinese fabric database with lab-tested specifications. It provides numerous example queries and explicitly distinguishes itself from sibling tools like get_fabric_detail and get_fabric_suppliers. The purpose is specific, actionable, and easily understood.

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: when to use (fabric discovery, specific example queries), when not to use (named SKU, full lab-test data, supplier pricing), and direct alternatives (get_fabric_detail, get_fabric_suppliers). It also outlines a workflow and self-correction strategies, offering comprehensive guidance.

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

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

Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) are already clear. The description adds valuable behavioral context: the tool is the primary entry point for supplier discovery, returns paginated list with specific fields (has_more, available_dimensions, data with supplier_id, type, etc.), and handles errors with defined self-correction logic (e.g., removing filters, broadening product_type, using recommend_suppliers). It also states that the source is MRC Data (meacheal.ai). 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 quite long but well-structured: it is front-loaded with the core purpose and common use cases, then organizes into sections for filters, workflow, returns structure, examples, errors/self-correction, and avoids. Every section adds value; there is no repetition. The length is justified given the tool's complexity (12 parameters, multiple sibling tools, error cases). A slight deduction for not being more compact, but still concise for the 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 complexity (12 parameters, many siblings, no output schema), the description is extremely complete. It covers purpose, all relevant use cases, filters, workflow with sibling tools, return structure (has_more, available_dimensions, data fields), error handling and self-correction for multiple scenarios, rate limiting, and bilingual examples. It also includes a note distinguishing from recommend_suppliers. The absence of an output schema is compensated by the described return structure.

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% (all 12 parameters described). The description goes beyond the schema by providing extensive examples that show how to use parameters together (e.g., province + product_type + compliance_status + limit, with MOQ example). It also explains behavior of product_type (typo normalization map for synonyms like 'tee'→'t-shirt', 'jeans'→'denim'). The 'AVOID' section clarifies when not to use certain parameters (e.g., do not loop across provinces).

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 starts with a clear action verb ('Search') and resource ('verified Chinese apparel manufacturers'), immediately stating the tool's purpose. It then lists numerous example user queries covering filters, locations, products, and compliance, making the scope explicit. It also distinguishes from sibling tools like recommend_suppliers (ranked vs filtered) and get_supplier_detail (detail vs list).

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 extensive usage guidance: an 'AVOID' section warns against looping across provinces (use get_province_distribution instead), using for ranked recommendations (use recommend_suppliers), or fetching details in a loop (use compare_suppliers). It also gives a workflow: search_suppliers → get_supplier_detail/compare_suppliers/find_alternatives/check_compliance/get_supplier_fabrics. Additionally, it includes error self-correction steps for empty results, invalid provinces, and rate limits.

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