MRC Data — China's Apparel Supply Chain Infrastructure

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?

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 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 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?

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.