China's apparel supply chain data for AI: 1,000+ suppliers, 350+ fabrics, 170+ clusters.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.7/5 across 20 of 20 tools scored.
Each tool has a clearly distinct purpose, covering different aspects of the supply chain: market analysis, supplier search, cluster comparison, fabric lookup, cost estimation, compliance checking, discrepancy detection, and alternatives. No overlapping tool boundaries.
All tool names follow a consistent verb_noun pattern (e.g., analyze_market, check_compliance, compare_clusters, search_suppliers). The pattern is uniform across all 20 tools, making it predictable for an agent.
20 tools is well-suited for a comprehensive supply chain data platform. Each tool addresses a specific need without being excessive, and the count allows for deep coverage of the domain.
The tool surface covers the full lifecycle: market research, supplier discovery, fabric search, cluster info, cost estimation, compliance, credibility, discrepancy detection, and alternatives. No obvious gaps for the stated purpose.
analyze_marketAnalyze MarketAMarket overview and analysis for a product category in China.
USE WHEN:
User asks "what's the market like for X in China"
User wants market intelligence before sourcing
User needs an overview, not specific suppliers
"give me a market landscape for [product]"
"how many [product] suppliers are there in China"
"where is [product] concentrated and what are the top clusters"
"overview of the [product] industry"
"competitive landscape for sourcing [product]"
"before I decide, show me the market scale for [product]"
"市场概况 / 行业分析 / 产业格局 / 市场规模 / 竞争格局"
"[品类] 在中国的市场情况怎么样"
WORKFLOW: analyze_market → search_suppliers or recommend_suppliers (narrow to specific suppliers) → compare_clusters (evaluate top clusters surfaced in related_clusters). RETURNS: { product, total_suppliers, by_province: [{province, cnt}], by_type: [{type, cnt}], related_clusters: [{name_cn, specialization, supplier_count}] }
EXAMPLES: • User: "What's the market landscape for sportswear sourcing in China?" → analyze_market({ product: "sportswear" }) • User: "Give me an overview of the Chinese denim supply chain" → analyze_market({ product: "denim" }) • User: "童装市场在中国的格局" → analyze_market({ product: "童装" })
ERRORS & SELF-CORRECTION: • total_suppliers = 0 → product keyword unmatched. Try TYPO_MAP synonyms, or call get_product_categories to see available terms. • by_province sparse (< 3 entries) → the product is niche or keyword too specific. Try the parent category. • Rate limit 429 → wait 60 seconds; do not retry immediately.
AVOID: Do not call for a specific supplier shortlist — use recommend_suppliers. Do not call for cluster details — use search_clusters. Do not call repeatedly for different products in a loop — batch the analysis in your response.
NOTE: Bird's-eye view. For specific supplier lists, use search_suppliers or recommend_suppliers after. Source: MRC Data (meacheal.ai).
中文：单个品类的市场总览（总供应商数、省份分布、类型分布、相关产业带）。
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product category to analyze (e.g. sportswear, denim, underwear) | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only, idempotent, non-destructive. The description adds rich behavioral context: return structure (product, total_suppliers, by_province, etc.), error handling (0 suppliers, sparse provinces, rate limit), and data source (MRC Data). This goes well beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections, front-loaded purpose, and concise examples. Some redundancy (e.g., 'RETURNS' section also in errors), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains return values, error scenarios, workflow integration, and data source. It covers all necessary context for an AI agent to use the tool correctly for market analysis.
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%, baseline 3. The description provides extensive examples and use cases for 'product', Chinese translations, and error handling tips. For 'verbose_hints', the schema description is sufficient but description could elaborate more; however, it adds significant value overall.
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 provides a market overview for a product category in China, using specific verbs like 'analyze' and 'overview'. It distinguishes from siblings by citing use cases and workflow, e.g., 'For specific supplier lists, use search_suppliers or recommend_suppliers after.'
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 explicit 'USE WHEN' section with specific user queries, an 'AVOID' section, and a suggested workflow sequence. It differentiates from alternatives with clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
assess_supplier_credibilityAssess Supplier CredibilityAAssess a supplier's overall data credibility by fusing multiple declared-vs-verified signals into one 0-100 trust score, with cross-signal physical-plausibility checks.
USE WHEN:
User asks "is this factory's data trustworthy / are they overstating?"
"credibility / trust score / red flags for sup_XXX"
"does sup_XXX's declared capacity match its actual workforce?"
"这家工厂数据可信吗 / 有没有虚报 / 可信度评分 / 产能和用工对得上吗"
PREREQUISITE: a valid supplier_id from search_suppliers / get_supplier_detail / recommend_suppliers. RETURNS: { supplier_id, company_name, trust_score (0-100 or null), confidence (high/medium/low/none), composite_risk, signals[], red_flags[], coverage_pct, parameters, method_note }
HOW IT WORKS: fuses up to 5 weighted signals over ONLY the signals that have data — social-insurance-vs-declared-workers, capacity-vs-workforce physical plausibility, declared-vs-verified capacity, certification validity, quality track record — then propagates a confidence level from how many signals and verified dimensions backed the score. Red flags are SUSPECTED inconsistencies, NOT definitive fraud findings; recommend human/document-level confirmation.
中文：把"申报 vs 核验"的多路信号(社保↔申报用工、产能↔核验用工的物理一致性、申报↔核验产能、认证时效、质量记录)按来源可靠度加权融合成一个 0-100 可信度分,并按数据覆盖度给出该分数的置信度。红旗为疑似不一致,非定性结论。
| Name | Required | Description | Default |
|---|---|---|---|
| supplier_id | Yes | Supplier ID from search_suppliers, e.g. sup_001 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds significant behavioral context: it fuses up to 5 weighted signals, returns a trust score with confidence levels, and clarifies that red flags are suspected inconsistencies requiring human confirmation. 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 well-structured with clear sections (purpose, usage, prerequisite, returns, how it works, Chinese translation). It is comprehensive but could be slightly more concise; every sentence serves a 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 a single parameter, no output schema, and rich return description, the description is fairly complete. It explains the fusion logic, signals, confidence propagation, and what red flags mean. Minor gaps could include error scenarios or edge 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?
The schema has 100% coverage for the single required parameter (supplier_id). The description adds value by stating that supplier_id should come from search_suppliers, get_supplier_detail, or recommend_suppliers, which provides context beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: assessing supplier credibility by fusing multiple signals into a 0-100 trust score. It distinguishes itself from sibling tools by focusing on data credibility and cross-signal plausibility checks, with specific examples in English and Chinese.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'USE WHEN' examples and a prerequisite (valid supplier_id from specific tools). While it doesn't explicitly state when not to use it, the examples effectively guide appropriate usage. Adding exclusion criteria would elevate to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_complianceCheck Export ComplianceACheck if a supplier meets compliance requirements for a target export market.
USE WHEN:
User asks "can this factory export to the US/EU/Japan"
User needs to verify certifications for a specific market
"UFLPA / Xinjiang cotton / REACH / JIS / KC check on sup_XXX"
"is [supplier] ready for EU CSDDD / Forced Labor Regulation"
"what's missing for sup_XXX to export to US"
"gap analysis / compliance dossier for [supplier] → [market]"
"does [supplier] meet Japan formaldehyde / azo dye rules"
"follow-up after get_supplier_detail: 'is this one US-ready?'"
"能不能出口美国 / 欧盟 / 日本 / 韩国"
"合规检查 / 认证要求 / 出口资质 / 强制性法规 / UFLPA 合规"
"[供应商] 能否满足 [市场] 的准入要求"
PREREQUISITE: You MUST have a valid supplier_id from search_suppliers, get_supplier_detail, or recommend_suppliers. WORKFLOW: search_suppliers → check_compliance → if issues exist, use find_alternatives to source compliant alternatives OR get_supplier_detail to see the full compliance fields and coverage. RETURNS: { supplier_id, company_name, target_market, overall_ready: boolean, passed: [string], issues: [string], certifications: [string], market_requirements: {field: value}, note }
EXAMPLES: • User: "Can sup_001 export to the US? Check UFLPA compliance" → check_compliance({ supplier_id: "sup_001", target_market: "us" }) • User: "Is Texhong EU REACH compliant?" → check_compliance({ supplier_id: "sup_texhong_042", target_market: "eu" }) • User: "sup_234 能出口日本吗" → check_compliance({ supplier_id: "sup_234", target_market: "japan" })
ERRORS & SELF-CORRECTION: • "Supplier not found" → supplier_id invalid. Re-run search_suppliers. • passed=[] AND issues=["No specific issues found, but data may be incomplete"] → the supplier's compliance fields are mostly null. Interpret as UNKNOWN not COMPLIANT. Tell user: "Compliance data incomplete — recommend verifying directly with the supplier." • overall_ready=false with many issues → use find_alternatives to find backup suppliers, OR search_suppliers with compliance_status="compliant" to filter upfront. • Rate limit 429 → wait 60 seconds; do not retry immediately.
AVOID: Do not call this in a loop across all suppliers — instead pre-filter via search_suppliers({ compliance_status: "compliant" }). Do not treat missing fields as non-compliant — report them as "not confirmed". Do not use for general supplier info — use get_supplier_detail.
NOTE: Many suppliers have incomplete compliance data. Missing data = "not confirmed", not "non-compliant". Source: MRC Data (meacheal.ai). Market requirements cover UFLPA/Xinjiang (US), REACH/CSDDD/Forced Labor Reg (EU), formaldehyde/azo/JIS (Japan), KC (Korea).
中文：检查某供应商是否满足目标出口市场（美/欧/日/韩）的合规要求。
| Name | Required | Description | Default |
|---|---|---|---|
| supplier_id | Yes | Supplier ID from search_suppliers, e.g. sup_001 | |
| target_market | Yes | Target export market | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false. Description adds behavioral details: returns specific fields, handles incomplete data, interprets missing fields as 'not confirmed', rate limit handling, and 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 headings (USE WHEN, PREREQUISITE, WORKFLOW, etc.). Front-loaded with purpose and key conditions. Every section adds value despite 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?
Covers prerequisites, workflow, return format, error handling, and interpretation. Without output schema, description explains return fields fully. Addresses complexity of incomplete data and market-specific requirements.
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 property descriptions. Description adds context on provenance of supplier_id and clarification of verbose_hints, but does not significantly deepen semantics beyond 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?
Clearly states the tool checks compliance for export markets, with explicit verb+resource ('Check if a supplier meets compliance requirements for a target export market'). Distinguishes from siblings like get_supplier_detail (general info) and find_alternatives (alternatives) via AVOID section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use list, prerequisites, workflow, error handling, and self-correction. Includes AVOID section to prevent misuse. Covers all usage context comprehensively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_clustersCompare Industrial ClustersACompare multiple Chinese apparel industrial clusters side-by-side on key metrics.
PREREQUISITE: You MUST first call search_clusters to obtain valid cluster_ids. Do not guess IDs.
USE WHEN user asks:
"compare Humen vs Shishi vs Jinjiang"
"which cluster has lower labor cost — Humen or Dongguan"
"side-by-side: Haining vs Xintang for denim"
"evaluate 3 clusters for my sportswear line"
"对比 [产业带1] 和 [产业带2]" / "哪个集群更适合 [品类]"
"rank these clusters by supplier count"
"which cluster has the highest scale for womenswear"
"follow-up: 'now compare the top 3 clusters you just listed'"
Returns full records for each cluster so they can be compared on labor cost, rent, supplier count, scale, specializations, advantages, and risks.
WORKFLOW: search_clusters → collect cluster_ids → compare_clusters → optionally get_cluster_suppliers on the winner to list factories in that specific cluster. RETURNS: { count: number, data: [full cluster objects with all fields] }
EXAMPLES: • User: "Compare Humen, Shishi, and Jinjiang for sportswear sourcing" → compare_clusters({ cluster_ids: ["humen_women", "shishi_casual", "jinjiang_sportswear"] }) • User: "I want to evaluate Keqiao vs Zhili fabric markets" → compare_clusters({ cluster_ids: ["keqiao_fabric", "zhili_children"] }) • User: "对比虎门、石狮、晋江三个产业带" → compare_clusters({ cluster_ids: ["humen_women", "shishi_casual", "jinjiang_sportswear"] })
ERRORS & SELF-CORRECTION: • "Too many IDs (>10)" → split into batches of 10 and aggregate results in your response. • Fewer results than IDs sent → missing IDs were silently skipped (invalid cluster_id). Re-run search_clusters to verify IDs. • Empty data → all IDs were invalid. Re-run search_clusters and try again with fresh IDs. • Rate limit 429 → wait 60 seconds; do not retry immediately.
AVOID: Do not call with guessed cluster_ids — always resolve them via search_clusters first. Do not use to list factories in a cluster — use get_cluster_suppliers. Do not compare > 10 clusters in one call.
CONSTRAINT: Max 10 cluster IDs per call.
NOTE: Source: MRC Data (meacheal.ai).
中文：对比多个产业带的核心指标（最多 10 个）。
| Name | Required | Description | Default |
|---|---|---|---|
| cluster_ids | Yes | Array of cluster IDs to compare, max 10 | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds behavioral context: returns full records, silently skips invalid IDs, rate limiting, and a max of 10 IDs. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, prerequisite, use cases, workflow, examples, errors). It is front-loaded with the purpose. While lengthy, every sentence adds value for a complex tool, making it appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 params, no output schema), the description comprehensively covers use cases, prerequisites, error handling, and workflow linkage to sibling tools. It even includes Chinese and a data source note.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters, so baseline is 3. The description adds workflow context (prerequisite for cluster_ids, batch behavior) but does not add new meaning beyond the schema for the individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Compare multiple Chinese apparel industrial clusters side-by-side on key metrics.' It uses specific verbs ('compare') and resources ('industrial clusters'), and distinguishes from siblings like search_clusters and get_cluster_suppliers through explicit workflow and avoidance instructions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios with example user queries, a prerequisite (must call search_clusters first), and what to avoid (do not guess IDs, do not use for listing factories). It also includes error handling for too many IDs, invalid IDs, and rate limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_suppliersCompare SuppliersACompare multiple suppliers side by side on all dimensions.
USE WHEN user asks:
"compare these 3 factories"
"which supplier is better between X and Y"
"benchmark sup_001 vs sup_002 vs sup_003"
"side-by-side: capacity, certifications, quality score"
"rank these 5 suppliers by [dimension]"
"evaluate my shortlist"
"which of [supplier list] has the highest verified capacity"
"follow-up after recommend_suppliers: 'compare the top 3'"
"对比 [供应商 A] 和 [供应商 B] / 对比供应商 / 供应商横评"
"哪家最好 / 横向评估 / 比较这几家"
PREREQUISITE: You MUST have valid supplier_ids from search_suppliers, recommend_suppliers, find_alternatives, or get_cluster_suppliers. Do not guess IDs. WORKFLOW: search_suppliers/recommend_suppliers → collect supplier_ids → compare_suppliers → optionally check_compliance (verify top picks for target market) OR find_alternatives (expand the shortlist).
DIFFERENCE from get_supplier_detail: This returns multiple suppliers at once for comparison. get_supplier_detail returns one with verified_dimensions breakdown.
RETURNS: { count, data: [full supplier profiles with all fields] }
EXAMPLES: • User: "Compare sup_001, sup_002, sup_003 for me" → compare_suppliers({ supplier_ids: ["sup_001", "sup_002", "sup_003"] }) • User: "Benchmark the top 5 you just recommended" → compare_suppliers({ supplier_ids: ["sup_A", "sup_B", "sup_C", "sup_D", "sup_E"] }) • User: "横向对比 sup_100、sup_200、sup_300" → compare_suppliers({ supplier_ids: ["sup_100", "sup_200", "sup_300"] })
ERRORS & SELF-CORRECTION: • Fewer results than IDs sent → missing IDs were silently skipped (invalid supplier_id). Re-run search_suppliers to verify. • count=0 → all IDs invalid. Re-run search_suppliers. • "Too many IDs" → split into batches of 10. • Rate limit 429 → wait 60 seconds; do not retry immediately.
AVOID: Do not loop get_supplier_detail — always use compare_suppliers when you have 2+ IDs. Do not pass more than 10 IDs. Do not use to find new suppliers — use search_suppliers or recommend_suppliers first.
CONSTRAINT: Max 10 supplier IDs per call.
NOTE: Source: MRC Data (meacheal.ai). Returns full 60+ field profile per supplier.
中文：横向对比多个供应商的全部字段（最多 10 个 ID）。
| Name | Required | Description | Default |
|---|---|---|---|
| supplier_ids | Yes | Array of supplier IDs from search_suppliers, e.g. ['sup_001', 'sup_002'], max 10 | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it |
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 details: returns full profiles (60+ fields), max 10 IDs, silent error handling for invalid IDs, rate limit behavior (429 wait 60s), and data source (MRC Data). 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 well-structured with headings, bullet points, and examples, making it easy to scan. However, it is somewhat verbose, with repetition of the max 10 constraint in multiple sections. It could be trimmed slightly without losing clarity, but overall the structure is effective for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return format ({ count, data: [full supplier profiles] }). It covers all important aspects: prerequisites, workflow, error handling (invalid IDs, rate limits), constraints (max 10), and explicit do-not-do instructions (no looping get_supplier_detail, no passing more than 10). This is highly complete for a compare 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% (both parameters have descriptions). The description adds value by explaining the origin of supplier_ids (must come from prior search), reinforcing the max 10 constraint, and clarifying the verbose_hints parameter's effect. While the schema already covers the basics, the description provides essential context and usage constraints that go beyond bare 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 compares multiple suppliers side by side on all dimensions. It distinguishes itself from sibling tools like get_supplier_detail (returns one supplier) and search_suppliers (finds suppliers). The specific verb 'compare' and resource 'suppliers' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive usage guidelines, including a detailed list of user intents (with example queries in both English and Chinese), a clear prerequisite (must have valid supplier_ids from prior search tools), a workflow, differences from related tools, and explicit 'AVOID' instructions. This leaves no ambiguity about 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.
detect_discrepancyDetect Spec DiscrepanciesA[Core feature] Surface supplier specifications that deviate from independent lab measurements.
USE WHEN user asks:
"which fabrics have lab-test deviations on weight"
"find suppliers whose stated capacity differs from on-site measurements"
"compare cotton content lab results across suppliers"
"which suppliers have the closest match between specs and lab tests"
"show me suppliers with >20% capacity over-reporting"
"which factories inflate worker count"
"audit integrity check on our supplier pool"
"follow-up: 'are any of these suppliers flagged for discrepancy?'"
"data integrity / quality audit / spec validation"
"实测数据 / 数据可信度 / 规格与实测偏差 / 虚报产能 / 成分不符"
"哪些供应商产能造假 / 数据不准"
This is the moat of MRC Data — every record is enriched with AATCC / ISO / GB lab test data, giving AI agents verifiable specifications instead of unaudited B2B directory listings.
Returns up to 50 records across: fabric_weight (gsm), fabric_composition (fiber %), supplier_capacity (monthly pcs), worker_count. Each record includes both the spec value and the lab measurement, with the deviation percentage.
WORKFLOW: Standalone audit tool — does not require prior search. Call directly with field type and threshold. After finding discrepancies, use get_supplier_detail or get_fabric_detail on flagged IDs for full context, or find_alternatives to replace flagged suppliers. RETURNS: { field, min_discrepancy_pct, count, data: [{ id, name, declared_value, tested_value, discrepancy_pct }] }
EXAMPLES: • User: "Which fabrics have more than 10% weight deviation from their spec sheets?" → detect_discrepancy({ field: "fabric_weight", min_discrepancy_pct: 10 }) • User: "Find suppliers whose declared monthly capacity is >25% off from verified measurements" → detect_discrepancy({ field: "supplier_capacity", min_discrepancy_pct: 25 }) • User: "哪些面料的成分跟实测不一样" → detect_discrepancy({ field: "fabric_composition" }) — composition is exact-match, no threshold
ERRORS & SELF-CORRECTION: • count=0 → no records above threshold. Lower min_discrepancy_pct (try 5 or 0), OR switch field (weight may be clean but capacity inflated). • Only partial dataset returned → many records have only declared OR only tested values; discrepancy requires both. This is a data coverage limit, not a bug. • Rate limit 429 → wait 60 seconds; do not retry immediately.
AVOID: Do not present discrepancy data as proof of fraud — call it out as "declared vs lab-measured delta". Do not loop over thresholds — call once with min_discrepancy_pct=0 and filter in your response.
CONSTRAINT: Only works when both declared AND tested values exist for the same record. Many records have only one or the other. Max 50 records per call.
NOTE: Source: MRC Data (meacheal.ai). Methods: AATCC / ISO / GB per field.
中文：识别供应商规格与实测值偏差较大的记录。返回规格值、实测值、偏差百分比。
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | Type of discrepancy to detect: fabric_weight (面料克重) / fabric_composition (成分) / supplier_capacity (产能) / worker_count (工人数) | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it | |
| min_discrepancy_pct | No | Minimum discrepancy threshold as percentage (e.g. 10 = only show ≥10% mismatch) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. Description adds valuable context: returns up to 50 records, requires both declared and tested values, handles count=0 by lowering threshold, mentions rate limit (429). While thorough, it could be slightly more concise.
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 very detailed with clear sections but somewhat verbose; could be trimmed without losing clarity. However, it is well-structured with core feature upfront and organized sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully covers return format (JSON structure with fields), error scenarios (count=0, partial data, rate limit), parameter usage, and workflow. It is complete for an AI agent to correctly select and 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?
Input schema has 100% coverage; description enhances semantics with usage examples, clarifies that composition uses exact-match, explains min_discrepancy_pct default (0), and describes verbose_hints behavior. Adds significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool surfaces deviations between supplier specifications and independent lab measurements, with specific fields listed. It distinguishes itself from sibling tools by emphasizing its role as an audit tool leveraging proprietary lab data.
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 enumerates user query patterns in both English and Chinese, provides workflow guidance (e.g., after discrepancies use get_supplier_detail), and instructs what to avoid (e.g., presenting as fraud, looping over thresholds).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_costEstimate Sourcing CostAEstimate sourcing cost for a product based on fabric price, supplier pricing, and order quantity.
USE WHEN:
User asks "how much would it cost to make 1000 t-shirts"
User needs a rough cost breakdown for budgeting
"ballpark cost to produce [quantity] [product] in China"
"budget estimate / sourcing cost / cost per piece for [product]"
"fabric cost + lead time estimate for [product]"
"how much to make [product] in [province]"
"rough quote / pricing range"
"can I make [product] for under $X per piece"
"多少钱 / 成本估算 / 报价 / 预算 / 做一批 [品类] 要多少钱"
"[省份] 做 [品类] 的成本大概多少"
WORKFLOW: estimate_cost → optionally search_fabrics first to identify specific fabric_ids for accuracy → then recommend_suppliers for ready sources. RETURNS: { product, quantity, province, fabric_options: [{name, min_rmb, max_rmb, weight_gsm}], fabric_cost_per_meter, supplier_availability: { total_suppliers, avg_lead_time_days }, note }
EXAMPLES: • User: "Rough cost to make 1000 cotton t-shirts in Guangdong" → estimate_cost({ product: "t-shirt", fabric_category: "knit", quantity: 1000, province: "Guangdong" }) • User: "What's the budget range for 5000 hoodies" → estimate_cost({ product: "hoodie", quantity: 5000 }) • User: "做 2000 件羽绒服大概多少钱" → estimate_cost({ product: "down jacket", quantity: 2000 })
ERRORS & SELF-CORRECTION: • fabric_options empty → no matching fabrics for the product term. Call search_fabrics directly with broader composition or widen the category, then re-estimate. • supplier_availability.total_suppliers = 0 → drop province filter or broaden product term. • Rate limit 429 → wait 60 seconds; do not retry immediately.
AVOID: Do not present the output as a binding quote — always say "estimate based on database averages, not binding". Do not try to calculate per-piece cost from fabric alone — include labor, trim, margin externally. Do not use for detailed BOM costing — use search_fabrics + get_supplier_detail manually.
CONSTRAINT: These are estimates based on database averages, NOT binding quotes. Always clarify this to the user. Fabric cost is per meter (typical usage: 1-3m per piece).
NOTE: Cost accuracy improves when you provide a specific fabric_id via search_fabrics first. Source: MRC Data (meacheal.ai).
中文：按面料均价 + 供应商供货能力估算 [品类] 的生产成本区间。仅供参考，非正式报价。
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product type (e.g. t-shirt, hoodie, down jacket) | |
| province | No | Preferred sourcing province | |
| quantity | No | Order quantity in pieces | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it | |
| fabric_category | No | Fabric category: knit, woven, functional |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it clarifies that estimates are based on database averages, not binding quotes, and advises on rate limit handling. It also explains the data source (MRC Data) and the meaning of fabric cost (per meter). No contradictions with annotations (readOnlyHint=true, idempotentHint=true).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (USE WHEN, WORKFLOW, RETURNS, etc.) and is front-loaded with the main statement. However, it is somewhat verbose, including a Chinese language block and a NOTE section that could be condensed. Still, every section serves a purpose, so it earns 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 5 parameters and no output schema, the description is highly complete. It explains the return structure, provides error handling, and covers constraints. The examples and workflow make the tool's role in a broader process clear. No gaps remain for an agent to guess.
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 5 parameters. The description adds significant value beyond the schema: it explains that fabric cost is per meter with typical usage of 1-3m per piece, and that providing fabric_id improves accuracy. Examples show how parameters are used in context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Estimate sourcing cost for a product based on fabric price, supplier pricing, and order quantity.' The USE WHEN section provides specific queries, distinguishing it from sibling tools like search_fabrics or recommend_suppliers. The workflow clarifies it as the first step in a sequence, so the agent knows when to use this 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 includes an extensive USE WHEN section with concrete examples in English and Chinese, covering various cost-related queries. The AVOID section explicitly states when not to use it (e.g., for binding quotes, detailed BOM costing). The workflow and ERROR sections guide the agent on prerequisites and fallback actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_alternativesFind Alternative SuppliersAFind alternative suppliers similar to a given supplier.
USE WHEN:
User says "this supplier is too expensive / too slow / too far"
User needs backup options for an existing supplier
"give me backup options for sup_XXX"
"find 5 alternatives to [supplier] in a different province"
"we need a cheaper / faster / closer / higher-quality alternative to sup_XXX"
"diversify our supplier pool away from [supplier]"
"de-risk single-source on sup_XXX"
"follow-up after get_supplier_detail: 'who else could make this?'"
"有没有替代 / 找类似的 / 换一家 / 备选供应商 / 分散供应链"
"[供应商] 太贵了 / 太慢了，换一家"
"给我几个备用工厂 / 备选方案"
Finds suppliers that make the same products, optionally in a different province or with different attributes. Results exclude the original supplier.
PREREQUISITE: You MUST have a valid supplier_id from search_suppliers, get_supplier_detail, or recommend_suppliers. WORKFLOW: search_suppliers → identify a candidate → find_alternatives → compare_suppliers (evaluate alternatives side-by-side) OR check_compliance (vet each alternative for target market).
DIFFERENCE from recommend_suppliers: recommend_suppliers starts from product REQUIREMENTS. This tool starts from a KNOWN supplier_id and finds similar alternatives. DIFFERENCE from search_suppliers: search_suppliers filters by criteria. This tool uses an existing supplier as the baseline reference.
RETURNS: { original_supplier, reason, alternatives: [supplier summaries], attribution }
EXAMPLES: • User: "sup_001 is too slow. Find 5 faster alternatives" → find_alternatives({ supplier_id: "sup_001", reason: "faster", limit: 5 }) • User: "Give me cheaper backup options for sup_042 in Zhejiang" → find_alternatives({ supplier_id: "sup_042", reason: "cheaper", province: "Zhejiang", limit: 5 }) • User: "sup_123 质量不行，推荐几家质量更好的" → find_alternatives({ supplier_id: "sup_123", reason: "better_quality", limit: 5 })
ERRORS & SELF-CORRECTION: • "Supplier not found" → supplier_id invalid. Re-run search_suppliers. • "Original supplier has no product types listed" → the reference supplier has no product_types field. Use recommend_suppliers with the product category the user actually wants instead. • Empty alternatives → the product type is rare OR province filter is too narrow. Drop province filter first, then try broader product search via recommend_suppliers. • Rate limit 429 → wait 60 seconds; do not retry immediately.
AVOID: Do not call this without first knowing the user's complaint (cheaper/faster/closer/quality) — without reason, results are generic. Do not call to find a supplier from scratch — use recommend_suppliers or search_suppliers. Do not compare via this tool — use compare_suppliers after.
CONSTRAINT: Max 10 alternatives per call. Query matches up to 3 product types from the reference supplier.
NOTE: Source: MRC Data (meacheal.ai). Sorting: "faster" uses lead_time_days.bulk_min ASC; others use quality_score DESC.
中文：基于已知 supplier_id 查找同品类的备选供应商（支持按 便宜/快/近/质量 排序，可限定省份）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of top results to return (1-10, default 5) | |
| reason | No | Why looking for alternatives | any |
| province | No | Preferred province for alternatives | |
| supplier_id | Yes | Current supplier ID to find alternatives for | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description details sorting behavior, error handling and self-correction steps, rate limit handling, constraints (max 10 alternatives), and return structure. This fully informs the agent of the tool's behavior and side effects.
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, DIFFERENCES, etc.). It is front-loaded with the core purpose and use cases. Every section adds necessary information, and the structure aids quick scanning. Slight redundancy in examples could be trimmed, but it remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 1 required, with enums and constraints), the description fully explains functionality, usage scenarios, error conditions, and output structure. It compensates for the lack of an output schema by describing the return format. The inclusion of a Chinese version also broadens accessibility.
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 already covers all parameters with descriptions. The description adds value by providing usage examples for each parameter (e.g., reason, province, limit) and explaining the verbose_hints parameter. While schema coverage is 100%, the examples and context elevate the understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find alternative suppliers similar to a given supplier.' It provides extensive use cases and explicitly distinguishes this tool from siblings like recommend_suppliers and search_suppliers, making its unique role 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 description includes a 'USE WHEN' list with concrete examples, prerequisites (must have a valid supplier_id), workflow guidance, and explicit differences from similar tools. It also warns against incorrect usage in the 'AVOID' section, providing comprehensive decision support for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_cluster_suppliersGet Cluster's SuppliersAList all suppliers in a specific industrial cluster.
USE WHEN user asks:
"what factories are in Humen cluster"
"show me suppliers in Keqiao fabric market"
"list all womenswear factories in [cluster]"
"top-quality suppliers in [cluster]"
"factory directory for [cluster]"
"page through suppliers in Shengze silk cluster" (pagination)
"follow-up after search_clusters: 'show me the factories there'"
"虎门产业带有哪些供应商 / [产业带] 的工厂列表"
"[集群] 里最好的几家工厂"
PREREQUISITE: You MUST have a valid cluster_id from search_clusters. WORKFLOW: search_clusters → pick cluster_id → get_cluster_suppliers → optionally get_supplier_detail (vet top-ranked factory) OR compare_suppliers (evaluate top 3-10 factories in the cluster). RETURNS: { cluster_id, has_more, data: [supplier summary objects sorted by quality_score DESC] }
EXAMPLES: • User: "What factories are in the Humen womenswear cluster?" → get_cluster_suppliers({ cluster_id: "humen_women", limit: 20 }) • User: "Show me the top 10 factories in Jinjiang sportswear cluster" → get_cluster_suppliers({ cluster_id: "jinjiang_sportswear", limit: 10 }) • User: "虎门有哪些服装厂，分页看第二页" → get_cluster_suppliers({ cluster_id: "humen_women", limit: 20, offset: 20 })
ERRORS & SELF-CORRECTION: • Empty data → either (a) cluster has no mapped suppliers (try compare_clusters to see supplier_count), or (b) cluster_id invalid. Re-run search_clusters. • cluster_id unknown → search_clusters({ specialization: "..." }) returns cluster_id values. • Rate limit 429 → wait 60 seconds; do not retry immediately.
AVOID: Do not guess cluster_ids — always resolve via search_clusters. Do not use this to find suppliers globally — use search_suppliers. Do not iterate clusters in a loop — use compare_clusters.
NOTE: Sorted by quality_score DESC. Source: MRC Data (meacheal.ai).
中文：列出某产业带内所有供应商，按质量评分排序。分页最多 50 条/页。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size: number of records to return (1-50, default 20) | |
| offset | No | Pagination offset: skip this many records before returning results (default 0) | |
| cluster_id | Yes | Cluster ID from search_clusters, e.g. humen_women, keqiao_fabric, shishi_casual | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations: sorted by quality_score DESC, source is MRC Data, pagination details (max 50/page), return structure { cluster_id, has_more, data }, rate limit handling, and empty data explanations. Annotations already indicate safe/idempotent, but description enriches understanding of behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with logical sections (USE WHEN, PREREQUISITE, etc.) and front-loaded with key action. Some sections like Chinese translation add completeness but extend length. Every sentence earns its place, though slightly verbose for a simple listing tool.
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 4 parameters, no output schema, and annotations only covering safety, the description provides complete context: return structure, sort order, error handling, pagination limits, bilingual examples, and workflow integration with sibling tools. No gaps remain.
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 value with examples showing parameter usage (e.g., limit and offset pagination), explains cluster_id must come from search_clusters, and details verbose_hints behavior. The examples illustrate real parameter values.
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' with specific verb and resource. It distinguishes from siblings like search_suppliers (global search) and compare_clusters (iterate clusters) by providing explicit contrasting usage patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use with concrete user queries ('what factories are in Humen cluster'), provides prerequisite (must have cluster_id from search_clusters), outlines workflow, and lists what to avoid (do not guess cluster_ids, do not use for global search, do not iterate clusters). Also includes errors and self-correction guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fabric_detailGet Fabric DetailAGet the complete lab-tested record of a single fabric by ID.
PREREQUISITE: You MUST first call search_fabrics to obtain a valid fabric_id. Do not guess IDs.
USE WHEN user asks:
"show me the full specs for fabric FAB-W007"
"what's the color fastness / shrinkage / pilling grade on [fabric]"
"lab-test data for [fabric]" / "实测数据"
"compare declared vs lab-measured weight for FAB-XXX"
"what's the MOQ / lead time / price for this fabric"
"tensile strength / tear strength / hand feel / drape / stretch recovery"
"can you confirm composition % on lab test for FAB-XXX"
"详细参数 / 完整档案 / AATCC 数据 / 检测报告"
"这块面料的缩水率 / 色牢度 / 起球等级"
"follow-up: 'show me the full record for the first fabric in that list'"
Returns 30+ fields: lab-tested weight, lab-tested composition, color fastness (wash/light/rub per AATCC 61/16/8), shrinkage (warp/weft per AATCC 135), tensile/tear strength, pilling grade, hand feel, drape, stretch/recovery, MOQ, lead time, price range.
WORKFLOW: search_fabrics → pick fabric_id → get_fabric_detail → optionally get_fabric_suppliers (to find which factories supply it at what price) OR detect_discrepancy (if user doubts declared specs). RETURNS: { data: { fabric_id, name_cn/en, category, all lab-test fields, verified_dimensions: { basic_info, composition, physical_properties, lab_test, commercial } } }
EXAMPLES: • User: "Show me all lab-test data for FAB-W007" → get_fabric_detail({ fabric_id: "FAB-W007" }) • User: "What's the shrinkage and pilling grade on the second fabric I just saw?" → get_fabric_detail({ fabric_id: "" }) • User: "我要 FAB-K023 的完整实测档案" → get_fabric_detail({ fabric_id: "FAB-K023" })
ERRORS & SELF-CORRECTION: • "Fabric not found" → the fabric_id is invalid. Re-run search_fabrics and use an ID from the fresh results. • Field returns null → that test wasn't performed on this fabric. Check verified_dimensions.lab_test to see what IS tested before asserting anything. • "not available" → unverified fabric in reserve pool. Filter search_fabrics for higher data_confidence. • Rate limit 429 → wait 60 seconds; do not retry immediately.
AVOID: Do not call in a loop for multiple fabrics — if user wants to compare fabrics, present the search_fabrics summary list instead. Do not call to browse — use search_fabrics with filters.
NOTE: Source: MRC Data (meacheal.ai). AATCC/ISO/GB methods cited per field.
中文：按 ID 获取单个面料的完整实测档案（含 AATCC/ISO/GB 检测指标）。
| Name | Required | Description | Default |
|---|---|---|---|
| fabric_id | Yes | Fabric ID from search_fabrics results, e.g. FAB-W007 | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, idempotent=true, destructive=false, so description's behavioral burden is lower. It adds value by detailing error cases (fabric not found, null fields, 429 rate limit) and self-correction actions, which is useful 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?
Well-structured with clear sections (purpose, prerequisite, use cases, workflow, returns, examples, errors, avoidance). While lengthy, every sentence adds value. Could be slightly trimmed but remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates thoroughly—lists 30+ fields, explains return structure, covers edge cases, and provides multilingual examples. Completely covers all context needed for an agent to use 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%, so baseline is 3. Description adds significant context: explains fabric_id comes from search results, and verbose_hints toggles interpretation annotations. This enriches the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the complete lab-tested record of a single fabric by ID, distinguishing it from sibling tools like search_fabrics (list results) and get_fabric_suppliers (supplier details). It uses specific verbs and resources.
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 the prerequisite to call search_fabrics first, provides dozens of user queries as cues, outlines workflow (search → pick ID → get detail → optionally further tools), and warns against looping or browsing. Includes error self-correction guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fabric_suppliersGet Fabric's SuppliersAList all suppliers offering a specific fabric, sorted by quality score, with price comparison.
USE WHEN user asks:
"who supplies fabric fab_XXX" / "where can I buy this fabric"
"compare prices for [fabric] across suppliers"
"best supplier for [fabric specification]"
"which factory has the lowest price on FAB-XXX"
"rank suppliers by quality for this fabric"
"follow-up: 'who else sells this?'"
"source comparison for [fabric]"
"price spread on FAB-XXX"
"谁家有这块面料 / 哪个厂报价最低 / 面料供应商对比"
"[面料] 有哪些供应商 / 货源"
Returns supplier records linked to the fabric with: company name, location, quality score, and that supplier's quoted price + MOQ for the fabric. Sorted by supplier quality score so the most reliable options appear first.
PREREQUISITE: You MUST have a valid fabric_id from search_fabrics. WORKFLOW: search_fabrics → pick fabric_id → get_fabric_suppliers → optionally get_supplier_detail (vet the top-ranked supplier) OR compare_suppliers (up to 10 IDs from this list). RETURNS: { fabric_id, count, data: [{ supplier_id, company_name_cn, province, city, quality_score, price_rmb, moq }] }
EXAMPLES: • User: "Who supplies FAB-W007 and at what price?" → get_fabric_suppliers({ fabric_id: "FAB-W007" }) • User: "Compare all suppliers for fabric FAB-K023" → get_fabric_suppliers({ fabric_id: "FAB-K023" }) • User: "FAB-123 有哪些供应商" → get_fabric_suppliers({ fabric_id: "FAB-123" })
ERRORS & SELF-CORRECTION: • count=0 → no suppliers linked to this fabric. Either (a) fabric is a spec-sheet reference with no mapped source, or (b) suppliers carry this fabric but the link isn't captured. Try search_suppliers filtered by the fabric's typical specialization (e.g. denim cluster) instead. • "Fabric not found" (implicit) → fabric_id invalid. Re-run search_fabrics. • Rate limit 429 → wait 60 seconds; do not retry immediately.
AVOID: Do not call this to browse suppliers generally — use search_suppliers. Do not call to see a supplier's full fabric range — use get_supplier_fabrics.
NOTE: Source: MRC Data (meacheal.ai). Sorted by supplier quality_score DESC.
中文：查询某面料的所有供应商，按质量评分排序，含报价对比。
| Name | Required | Description | Default |
|---|---|---|---|
| fabric_id | Yes | Fabric ID from search_fabrics, e.g. FAB-W007 | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint; description adds details: sorted by quality_score, return structure, error handling (count=0, rate limit), and data source. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with sections (USE WHEN, PREREQUISITES, etc.). Front-loaded with core purpose. Slightly long but every section adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a 2-param tool with 100% schema coverage. Covers return structure, error scenarios, and rate limiting. No output schema needed.
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%. Description adds examples and explains verbose_hints adds interpretation annotations. Baseline 3, extra context 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 'List all suppliers offering a specific fabric' and provides multiple user question examples. It 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?
Explicit when-to-use scenarios are given (e.g., 'who supplies fabric fab_XXX', 'compare prices'), prerequisites (fabric_id from search_fabrics), workflow, and error self-correction. Also states when NOT to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_categoriesList Product CategoriesAList all product categories available in the database with supplier counts.
USE THIS FIRST when:
User doesn't know what to search for
User asks "what do you have" / "what can I source"
User needs to explore the database
"what's the most common product category in Guangdong"
"show me all product types you cover"
"which categories have the most suppliers"
"what apparel categories exist in [province]"
"database catalog / inventory overview / category list"
"有哪些品类 / 能找什么 / 覆盖哪些产品 / 品类分布"
"[省份] 主要做什么品类"
WORKFLOW: Standalone discovery entry point. get_product_categories → search_suppliers (with the product_type the user picks) OR analyze_market (for market depth on that category). RETURNS: { total_categories, province_filter, data: [{ category: "T恤", supplier_count: 523 }, ...] }
EXAMPLES: • User: "What product types does your database cover?" → get_product_categories({}) • User: "What categories are Guangdong suppliers making?" → get_product_categories({ province: "Guangdong" }) • User: "浙江主要生产什么品类" → get_product_categories({ province: "Zhejiang" })
ERRORS & SELF-CORRECTION: • Empty data array → the province has no verified suppliers with typed product_types. Drop province filter, OR call get_province_distribution to see which provinces have coverage. • Invalid province → use English (Guangdong) or Chinese (广东). normalizeProvince handles both. • Rate limit 429 → wait 60 seconds; do not retry immediately.
AVOID: Do not call this before every search — it's an exploratory tool. Do not use for geographic insight — use get_province_distribution.
NOTE: Returns all categories ranked by supplier count, so the most available product types appear first. Source: MRC Data (meacheal.ai).
中文：列出数据库中所有品类及其供应商数量，按数量排序。可按省份筛选。
| Name | Required | Description | Default |
|---|---|---|---|
| province | No | Filter by province (e.g. guangdong, 广东) | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false. Description adds value by disclosing return format, error handling (empty data, invalid province, rate limit), and ordering by supplier count. 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?
Well-structured with sections (USE THIS FIRST, WORKFLOW, RETURNS, EXAMPLES, ERRORS). Slightly lengthy due to comprehensive examples and error handling, but front-loaded with purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and 20 siblings, the description fully covers when to use, workflow, return format, error handling, and examples. Addresses all critical context for an exploration 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 100% provides baseline 3. Description adds richness with examples mapping user queries to province parameter, bilingual support, and error handling context. Does not describe verbose_hints in text but examples suffice.
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?
Specific verb 'list' and resource 'product categories' with added scope 'with supplier counts'. Clearly distinguishes from siblings like get_province_distribution 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?
Provides explicit when-to-use scenarios, workflow (standalone discovery entry point), and what to avoid (do not call before every search). Mentions alternatives like get_province_distribution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_province_distributionProvince DistributionAShow supplier distribution across Chinese provinces.
USE WHEN:
User asks "where are factories located" / "which provinces"
User needs to decide which region to source from
"where's [product] manufacturing concentrated in China"
"top provinces for [category]"
"geographic heatmap of suppliers for [product]"
"is sportswear mostly in Fujian or Zhejiang"
"which cities lead denim production"
"follow-up: 'break it down by province'"
"哪里有工厂 / 供应商分布 / 产业分布 / 地域分布"
"[品类] 主要在哪几个省 / 哪个省最集中"
WORKFLOW: Standalone discovery tool. get_province_distribution → search_suppliers (with top province) OR search_clusters (for clusters within that province) OR analyze_market (deeper view). RETURNS: { total_provinces, data: [{ province, supplier_count, top_cities: [{ city, count }] }] }
EXAMPLES: • User: "Where are most Chinese apparel factories located?" → get_province_distribution({}) • User: "Which provinces lead in sportswear manufacturing?" → get_province_distribution({ product_type: "sportswear" }) • User: "牛仔工厂主要分布在哪" → get_province_distribution({ product_type: "denim" })
ERRORS & SELF-CORRECTION: • Empty data for product_type → product_type keyword may not match. Try TYPO_MAP synonyms (tee→t-shirt, jeans→denim, 运动服→activewear) or drop the filter entirely. • Sparse results (< 3 provinces) → the product is niche. Try the parent category or broaden the term. • Rate limit 429 → wait 60 seconds; do not retry immediately.
AVOID: Do not call for cluster-level granularity — use search_clusters. Do not call without product_type if user is asking about a specific category — the unfiltered output is generic.
NOTE: Provinces are ranked by supplier count (Guangdong, Zhejiang, Jiangsu, Fujian typically lead). Source: MRC Data (meacheal.ai).
中文：按省份展示供应商分布，含每省 Top 城市。可按品类筛选。
| Name | Required | Description | Default |
|---|---|---|---|
| product_type | No | Filter by product type (e.g. sportswear, t-shirt, 运动服) | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description reinforces no destructive actions, adds error handling (429, empty data, sparse results), data ranking details, and data source, exceeding 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?
Well-structured with clear sections (USE WHEN, WORKFLOW, RETURNS, EXAMPLES, ERRORS, AVOID, NOTE). Slightly long but every section adds unique value. Could be more concise but remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully outlines return structure. Covers query patterns, error handling, workflow, multilingual examples, and data source. No gaps apparent for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and schema already documents both parameters. The description adds value through usage examples, synonyms for product_type, and error self-correction strategies, going beyond schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Show supplier distribution across Chinese provinces' and provides numerous specific use cases and query examples, clearly distinguishing it from siblings like search_clusters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Extensive 'USE WHEN' list with concrete query patterns, explicit 'AVOID' cases (cluster granularity, missing product_type), workflow integration, and alternative tool references. This provides comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_statsGet Database StatsAGet overall database statistics: total counts of suppliers, fabrics, clusters, and links.
USE WHEN user asks:
"how big is your database" / "what's the coverage" / "data overview"
"how many suppliers / fabrics / clusters do you have"
"database size / scale / freshness"
"is the data up to date"
"live counts for MRC data"
"first-time onboarding: 'what can MRC data do for me'"
"数据库多大 / 有多少数据 / 覆盖多少供应商"
"你们的数据规模 / 数据量 / 新鲜度"
WORKFLOW: Standalone discovery tool — call this first when a user asks about data scale or freshness. Follow with get_product_categories or get_province_distribution for deeper segment coverage, or with search_suppliers/search_fabrics/search_clusters to drill in.
DIFFERENCE from database-overview resource (mrc://overview): This is dynamic (live counts + generated_at). The resource is static (geographic scope, top provinces, data standards).
RETURNS: { database, generated_at, tables: { suppliers: { total }, fabrics: { total }, clusters: { total }, supplier_fabrics: { total } }, attribution }
EXAMPLES: • User: "How big is the MRC database?" → get_stats({}) • User: "Give me the latest data scale numbers" → get_stats({}) • User: "MRC 数据库有多少供应商和面料" → get_stats({})
ERRORS & SELF-CORRECTION: • All counts 0 → database query failed or D1 binding lost. Retry once after 5 seconds. If still 0, surface a transport error to user. • Rate limit 429 → wait 60 seconds; do not retry immediately.
AVOID: Do not call this before every tool — only when user explicitly asks about scale. Do not call to get per-category counts — use get_product_categories. Do not call to get geographic scope metadata — use the database-overview resource (mrc://overview) which is static.
NOTE: Only reports verified + partially_verified records. Unverified reserve data is excluded from counts. Source: MRC Data (meacheal.ai).
中文：获取数据库整体统计（供应商总数、面料总数、产业带总数、关联记录数）。动态快照，含生成时间戳。
| Name | Required | Description | Default |
|---|---|---|---|
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint true, idempotentHint true, destructiveHint false. The description adds significant behavioral context: it returns a dynamic snapshot with generated_at timestamp, excludes unverified records, explains error handling (all zeros indicates failure, rate limiting), and notes data source. 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 comprehensive but well-structured with clear sections (USE WHEN, WORKFLOW, DIFFERENCE, RETURNS, etc.). It is lengthy but every section adds value. Could be slightly more concise, but overall efficient for the information conveyed.
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 the return shape, examples, and error handling. The tool has low complexity (1 optional param) and the description covers all necessary context for an agent to invoke it 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 a single optional boolean parameter 'verbose_hints'. The description does not add meaning beyond the schema's description of the parameter. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns overall database statistics (suppliers, fabrics, clusters, links). The verb 'Get' and resource 'Database Stats' are specific. It explicitly distinguishes from siblings like get_product_categories and get_province_distribution, and from the static resource mrc://overview.
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 use case scenarios with example user queries in English and Chinese. Includes workflow guidance (call this first when asking about scale), explicit differences from similar tools, and a clear 'AVOID' section detailing when not to use this tool and which alternatives to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_supplier_detailGet Supplier DetailAGet the complete profile of a single Chinese apparel supplier by ID.
PREREQUISITE: You MUST first call search_suppliers or recommend_suppliers to obtain a valid supplier_id. Do not guess IDs.
USE WHEN user asks:
"tell me more about [supplier]" / "show full details for sup_XXX"
"what certifications does this factory hold"
"what's their monthly capacity / worker count / equipment list"
"can [supplier] export to US / EU / Japan / Korea"
"give me the full profile / dossier / fact sheet for [supplier]"
"how verified is this supplier's data" (returns coverage_pct + 8 dimensions)
"what's their ownership type — own factory or broker"
"show payment terms / lead time / sample turnaround for sup_XXX"
"这家供应商具体情况 / 详细资料 / 工厂档案"
"[供应商] 的合规 / 认证 / 出口资质"
Returns 60+ fields including: monthly capacity (lab-verified), equipment list, certifications (BSCI/OEKO-TEX/GRS/SA8000), ownership type (own factory vs subcontractor vs broker), market access (US/EU/JP/KR), chemical compliance (ZDHC/MRSL), traceability depth, and verified_dimensions breakdown showing exactly which of the 8 dimensions (basic_info, geo_location, production, compliance, market_access, export, financial, contact) have data.
WORKFLOW: search_suppliers → pick supplier_id → get_supplier_detail → optionally get_supplier_fabrics (fabric catalog) OR check_compliance (market export readiness) OR find_alternatives (backup pool) OR compare_suppliers (side-by-side evaluation). RETURNS: { data: { supplier_id, company_name_cn/en, type, province, city, product_types, worker_count, certifications, compliance_status, quality_score, verified_dimensions: { verified_dims: "5/8", coverage_pct, dimensions: {...} } } }
EXAMPLES: • User: "Show me the full profile for sup_001" → get_supplier_detail({ supplier_id: "sup_001" }) • User: "What certifications does Texhong hold and can they export to EU?" → get_supplier_detail({ supplier_id: "sup_texhong_042" }) — then inspect certifications + eu_market_ready; follow with check_compliance for formal verification • User: "我要看 sup_123 的完整档案" → get_supplier_detail({ supplier_id: "sup_123" })
ERRORS & SELF-CORRECTION: • "Supplier not found" → the supplier_id is invalid or outside free-tier access. Re-run search_suppliers to obtain a fresh valid ID. Do not guess sequential IDs. • Field returns null → that dimension is unverified for this supplier. Check verified_dimensions.coverage_pct before asserting data. If coverage_pct < 50, warn the user: "This supplier's record has limited verified data (X/8 dimensions). Consider find_alternatives for better-documented options." • "not available for public access" → this supplier is in the reserve pool (paid tier only). Use search_suppliers filters data_confidence=verified to stay in public tier. • Rate limit 429 → wait 60 seconds; do not retry immediately.
AVOID: Do not call this for multiple suppliers in a loop — use compare_suppliers with up to 10 IDs at once. Do not call to browse the database — use search_suppliers or get_province_distribution for discovery.
NOTE: Source: MRC Data (meacheal.ai). Every numeric field shows both declared and lab-verified values where available.
中文：按 ID 获取单个供应商的完整档案（含维度覆盖率详情）。
| Name | Required | Description | Default |
|---|---|---|---|
| supplier_id | Yes | Supplier ID from search_suppliers results, e.g. sup_001 | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds error handling (not found, null fields, rate limit), data verification details (lab-verified values, coverage_pct), and source attribution. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (PREREQUISITE, USE WHEN, WORKFLOW, RETURNS, EXAMPLES, ERRORS). Front-loaded with main purpose. Every sentence adds value; 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?
Despite no output schema, description provides sample return structure, explains key fields (verified_dimensions, coverage_pct), and covers error handling. Sufficient for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both params documented). Description adds context: supplier_id must come from search, verbose_hints adds interpretation. Examples show exact invocation.
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 'Get the complete profile of a single Chinese apparel supplier by ID' using specific verb+resource. Clearly distinguishes from siblings like compare_suppliers (multiple IDs) and search_suppliers (discovery).
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 prerequisite (must call search_suppliers or recommend_suppliers first), provides specific user query patterns, and includes what to avoid (loops, browsing). Workflow section maps tool sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_supplier_fabricsGet Supplier's Fabric CatalogAList all fabrics a specific supplier can provide, with quoted prices.
USE WHEN user asks:
"what fabrics does [supplier name] have" / "what can this factory source for me"
"show me the catalog of supplier sup_XXX"
"what does this manufacturer offer"
"what fabric options does sup_XXX quote for denim"
"does [supplier] supply [fabric type]"
"price list / fabric catalog / offering sheet for sup_XXX"
"MOQ per fabric at this supplier"
"follow-up: 'what fabrics can they supply?' after identifying a supplier"
"[供应商] 能供应哪些面料 / 报价表 / 起订量"
Returns fabric records linked to the supplier with: fabric name, category, weight, composition, and the supplier's quoted price + MOQ for that specific fabric.
PREREQUISITE: You MUST have a valid supplier_id from search_suppliers or get_supplier_detail. WORKFLOW: search_suppliers → get_supplier_detail → get_supplier_fabrics → optionally get_fabric_detail (for lab-test data on a specific fabric) OR get_fabric_suppliers (cross-check price vs other suppliers for same fabric). RETURNS: { supplier_id, count, data: [{ fabric_id, name_cn, category, weight, composition, price_rmb, moq }] }
EXAMPLES: • User: "What fabrics does sup_texhong_042 offer?" → get_supplier_fabrics({ supplier_id: "sup_texhong_042" }) • User: "Show me the fabric catalog and MOQs for sup_001" → get_supplier_fabrics({ supplier_id: "sup_001" }) • User: "sup_234 能做哪些面料，报价多少" → get_supplier_fabrics({ supplier_id: "sup_234" })
ERRORS & SELF-CORRECTION: • count=0 → this supplier has no linked fabric catalog in the database. Either (a) they don't self-source fabrics (CMT-only) — confirm via get_supplier_detail.ownership_type, or (b) their catalog is unmapped — use search_fabrics with their expected specialization instead. • "Supplier not found" (implicit) → the supplier_id is invalid. Re-run search_suppliers. • Rate limit 429 → wait 60 seconds; do not retry immediately.
AVOID: Do not call this for a general fabric search — use search_fabrics. Do not call to compare prices across suppliers for the SAME fabric — use get_fabric_suppliers instead.
NOTE: Source: MRC Data (meacheal.ai). Prices are supplier-quoted, not binding offers.
中文：查询某供应商能供应的所有面料及其报价、起订量。
| Name | Required | Description | Default |
|---|---|---|---|
| supplier_id | Yes | Supplier ID from search_suppliers, e.g. sup_001 | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and idempotent. Description adds: return fields, error handling for count=0 and invalid IDs, rate limit rules, source note, and that prices are not binding. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is long but well-structured with clear sections. Front-loaded with purpose and USE WHEN. Slightly verbose but every section adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description details return structure. Covers prerequisites, errors, workflow integration with siblings. Highly complete for a complex 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% with 2 parameters. Description adds context: supplier_id format, examples, and explanation of verbose_hints. Baseline 3 with extra 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 the tool lists all fabrics a supplier can provide with quoted prices. It distinguishes from siblings like search_fabrics and get_fabric_suppliers, providing specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use (e.g., user asks for supplier's fabrics, catalog, price list) and when not to use (general fabric search, cross-supplier price comparison). Includes prerequisites and workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_suppliersRecommend SuppliersASmart supplier recommendation based on sourcing requirements.
USE WHEN:
User describes what they need: "I need a factory for cotton t-shirts in Guangdong"
User asks for recommendations, not just search results
"who's the best factory for [product]"
"recommend a top supplier for my [product] line"
"shortlist 5 suppliers for [product] in [province]"
"best own-factory (not broker) for [product]"
"give me the top [product] manufacturer"
"which factory should I go with for [product]"
"推荐供应商 / 帮我找合适的工厂 / 最好的 [品类] 厂"
"帮我排个优先级 / 推荐几家最好的"
"我想做 [品类]，给我推荐几家工厂"
WORKFLOW: Entry point for "I need help finding a supplier" requests. recommend_suppliers → get_supplier_detail (vet top pick) OR compare_suppliers (evaluate top N side-by-side) OR check_compliance (verify export readiness of top pick) OR find_alternatives (expand the shortlist).
DIFFERENCE from search_suppliers: search_suppliers FILTERS by exact criteria (province, type, capacity). This tool RANKS by fit — prioritizes own-factory, then quality score, then capacity. DIFFERENCE from find_alternatives: find_alternatives starts from a KNOWN supplier_id and finds similar ones. This tool starts from product REQUIREMENTS.
RETURNS: { query, total_matches, showing_top, note: "ranking logic", data: [supplier objects] }
EXAMPLES: • User: "Recommend me the top 5 factories for sportswear in Fujian" → recommend_suppliers({ product: "sportswear", province: "Fujian", type: "factory", limit: 5 }) • User: "I need the best own-factory (not trading company) for down jackets" → recommend_suppliers({ product: "down jacket", type: "factory", limit: 5 }) • User: "帮我推荐 3 家广东做 T 恤的工厂" → recommend_suppliers({ product: "t-shirt", province: "Guangdong", limit: 3 })
ERRORS & SELF-CORRECTION: • Empty data → try in order: (1) drop province, (2) drop type filter, (3) broaden product (e.g. "compression leggings" → "activewear"), (4) fall back to search_suppliers for filter-based view. • product_type not found in normalizeProductType → use the Chinese term or the parent category. • Rate limit 429 → wait 60 seconds; do not retry immediately. • Empty after 3 retries → tell user: "I don't see verified suppliers matching [product] in [province]. Want me to broaden to nationwide, or try a sibling category?"
AVOID: Do not call this when the user wants exact filtering — use search_suppliers. Do not call repeatedly for different limit values — request max once then slice in your response. Do not use for cluster recommendations — use search_clusters.
NOTE: Ranking: own_factory > quality_score > declared_capacity_monthly. Source: MRC Data (meacheal.ai).
中文：基于采购需求智能推荐供应商，按 自有工厂 > 质量分 > 产能 排序。
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Prefer own factory or trading company | |
| limit | No | Number of top results to return (1-10, default 5) | |
| product | Yes | What product to source (e.g. sportswear, t-shirt, down jacket) | |
| province | No | Preferred province | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, confirming it's a safe read operation. The description adds detail on ranking logic (own_factory > quality_score > capacity), error self-correction steps (drop province, broaden product), rate limit handling (wait 60 seconds), and data source (MRC Data). 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, WORKFLOW, DIFFERENCE, RETURNS, EXAMPLES, ERRORS, AVOID). Every section adds value, and the content is front-loaded with the purpose. Could be slightly more concise, but the structure 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 5 parameters, no output schema, and many sibling tools, the description is extremely complete. It covers ranking logic, error recovery strategies, example queries, and workflow integration. It provides all necessary context for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds substantial value with example calls mapping natural language to parameters, error handling for empty results (e.g., try dropping province), and explains how parameters affect ranking. This goes far beyond the schema definitions.
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 is a smart supplier recommendation tool that ranks by fit based on product requirements. It distinguishes itself from search_suppliers (which filters by exact criteria) and find_alternatives (which starts from a known supplier_id). The verb 'recommend' and resource 'suppliers' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use with many examples (e.g., 'I need a factory for cotton t-shirts in Guangdong') and when not to use ('Do not call when the user wants exact filtering'). It also outlines the workflow with follow-up tools like get_supplier_detail and compare_suppliers, and lists differences from siblings. An AVOID section prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_clustersSearch Industrial ClustersASearch Chinese apparel industrial clusters and textile markets.
USE WHEN user asks:
"where is China's [denim / suit / women's wear / underwear] manufacturing concentrated"
"what is the largest [silk / cashmere / down jacket] industrial cluster in China"
"industrial cluster comparison Humen vs Shaoxing vs Haining vs Zhili"
"recommend an industrial cluster for sourcing [product]"
"where should I set up a sourcing office for [category]"
"list mega clusters for [category]"
"fabric markets in Zhejiang / Jiangsu"
"accessories / trim / zipper / button markets in China"
"which province dominates [category] exports"
"follow-up: 'tell me more about Humen's cluster scale'"
"服装产业带 / 面料市场 / 产业集群 / 纺织集群 / 辅料市场"
"做 [品类] 应该去哪个产业带 / 集群推荐"
Famous clusters this database covers include: Humen (Guangdong, womenswear), Shaoxing Keqiao (Zhejiang, fabric mega-market), Haining (Zhejiang, leather), Zhili (Zhejiang, children's wear), Shengze (Jiangsu, silk), Shantou (Guangdong, underwear), Puning (Guangdong, jeans), Jinjiang (Fujian, sportswear), and more.
Returns paginated cluster list with name, location, specialization, scale, supplier count, average rent and labor cost, and key advantages/risks.
WORKFLOW: Cluster discovery entry point. search_clusters → compare_clusters (side-by-side up to 10 cluster_ids) OR get_cluster_suppliers (list factories in that cluster) OR analyze_market (broader market view). RETURNS: { has_more: boolean, data: [{ cluster_id, name_cn, name_en, type, province, city, specialization, scale, supplier_count, labor_cost_avg_rmb }] }
EXAMPLES: • User: "Where are the biggest denim clusters in China?" → search_clusters({ specialization: "denim", scale: "mega" }) • User: "Show me fabric markets in Zhejiang" → search_clusters({ province: "Zhejiang", type: "fabric_market" }) • User: "童装产业带有哪些" → search_clusters({ specialization: "童装" })
ERRORS & SELF-CORRECTION: • Empty data array → try in order: (1) drop scale filter, (2) broaden specialization (e.g. "服装" instead of "牛仔"), (3) remove type, (4) remove province. • Specialization mismatch → both Chinese and English work. Synonyms: sportswear/运动服, womenswear/女装, underwear/内衣, denim/牛仔. • Rate limit 429 → wait 60 seconds; do not retry immediately. • Empty after 3 retries → tell user: "No clusters match [criteria]. Try broader specialization or removing filters."
AVOID: Do not use this for specific factory search — use search_suppliers. Do not compare clusters by calling search_clusters twice — use compare_clusters with cluster_ids.
NOTE: Source: MRC Data (meacheal.ai). 170+ clusters mapped across 31 provinces.
中文：搜索中国服装产业带和面料市场。
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Cluster type: fabric_market (面料市场) / garment_manufacturing (服装制造) / accessories (辅料) / integrated (综合) | |
| limit | No | Page size: number of records to return (1-50, default 10) | |
| scale | No | Cluster scale: mega / large / medium / small | |
| offset | No | Pagination offset: skip this many records before returning results (default 0) | |
| province | No | Province in China (e.g. Guangdong, Zhejiang, Jiangsu, Fujian, Shandong) | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it | |
| specialization | No | Primary specialization keyword (e.g. 牛仔 denim, 女装 womenswear, 童装 childrenswear, 内衣 underwear, 运动服 sportswear) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, destructiveHint. Description adds behavioral context: pagination details, workflow as entry point, error handling (rate limit 429 wait 60s), empty data retry strategies, source attribution. 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?
Well-structured with clear sections (USE WHEN, examples, returns, workflow, errors, avoid, note, Chinese). Some repetition of example queries could be trimmed, but overall front-loaded and 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?
Fully covers all aspects: 7 parameters (all described), no output schema but return fields explained, error scenarios, self-correction, relationship to siblings, source and scale (170+ clusters). Highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage. Description adds value beyond schema with examples of parameter values (denim, womenswear, Zhejiang, mega), synonyms, and error correction logic for empty results.
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 it searches Chinese apparel industrial clusters and textile markets. It includes extensive example queries and clearly 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?
Provides explicit when-to-use guidance with example queries, and avoidance instructions: 'Do not use for specific factory search', 'Do not compare clusters by calling search_clusters twice'. Also includes error handling and fallback strategies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_fabricsSearch FabricsASearch the Chinese fabric and textile database with lab-tested specifications.
USE WHEN user asks:
"find me a [cotton / polyester / nylon / wool / linen] fabric for [t-shirts / jeans / suits]"
"I need 180gsm jersey knit with verified composition"
"fabrics under N RMB/meter for womenswear"
"compare lab-tested fabric weight across suppliers"
"show me functional fabrics for activewear / sportswear"
"what woven fabrics work for shirting"
"list organic / GOTS / recycled fabrics"
"I want heavyweight denim above 12 oz"
"fabrics with stretch / spandex content 2-5%"
"give me another page" (pagination via offset)
"lab-verified composition for [product]" (quality check)
"找面料 / 搜面料 / 查面料 / 找布料 / 打样面料"
"我要做 T 恤，帮我找克重 180-220 的针织面料"
Filters: category (woven/knit/nonwoven/leather/functional), weight range (gsm), composition keyword, target apparel type, max price. Returns paginated fabric list with name, lab-tested weight, lab-tested composition, price range, suitable apparel, and data confidence level.
WORKFLOW: Primary entry point for fabric discovery. search_fabrics → get_fabric_detail (full 30+ lab-test fields) OR get_fabric_suppliers (compare supplier prices for same fabric) OR estimate_cost (budget the product). RETURNS: { has_more: boolean, available_dimensions: ["basic_info","composition","physical_properties","lab_test","commercial"], data: [{ fabric_id, name_cn, category, subcategory, declared_weight_gsm, declared_composition, price_range_rmb, suitable_for, verified_dims: "4/5", coverage_pct }] }
EXAMPLES: • User: "Find 180-220gsm cotton jersey for t-shirts under 35 RMB/m" → search_fabrics({ category: "knit", min_weight_gsm: 180, max_weight_gsm: 220, composition: "cotton", suitable_for: "t-shirt", max_price_rmb: 35 }) • User: "I need stretch denim for women's jeans" → search_fabrics({ category: "woven", composition: "spandex", suitable_for: "denim" }) • User: "帮我找适合做衬衫的梭织面料，棉 60% 以上" → search_fabrics({ category: "woven", composition: "cotton", suitable_for: "shirt" })
ERRORS & SELF-CORRECTION: • Empty data array → try in order: (1) drop suitable_for, (2) widen weight range by 50gsm each side, (3) broaden composition (e.g. "cotton" instead of "organic cotton"), (4) drop max_price_rmb, (5) try the parent category (knit → all). • Composition mismatch → TYPO_MAP normalizes common misspellings (e.g. "poly" → "polyester", "lycra" → "spandex"). If still no match, try the Chinese term (棉/涤纶/氨纶/锦纶). • Rate limit 429 → wait 60 seconds. Do not retry immediately. • Empty after 3 retries → tell user: "No fabric matches [criteria]. Would you like to broaden weight/price/composition?"
AVOID: Do not call this looking for a specific named fabric SKU — search by specs instead (weight + composition + category). Do not fetch full lab-test data this way — use get_fabric_detail. Do not call repeatedly for supplier pricing on the same fabric — use get_fabric_suppliers.
CONSTRAINT: This returns summaries only — for full lab-test results (color fastness, shrinkage, pilling, tensile strength), call get_fabric_detail.
NOTE: Source: MRC Data (meacheal.ai). Every record includes AATCC / ISO / GB lab test measurements where verified.
中文：搜索面料数据库，按品类、克重、成分、适用品类、价格筛选。每条均含 AATCC / ISO / GB 方法的实测数据。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size: number of records to return (1-50, default 10) | |
| offset | No | Pagination offset: skip this many records before returning results (default 0) | |
| category | No | Fabric category: woven (梭织) / knit (针织) / nonwoven (无纺) / leather (皮革) / fur (毛皮) / functional (功能性) | |
| composition | No | Fiber composition keyword (e.g. cotton, polyester, spandex, nylon, wool, linen, 棉, 涤纶) | |
| suitable_for | No | Target apparel keyword (e.g. T恤 t-shirt, 衬衫 shirt, 牛仔 denim, 连衣裙 dress) | |
| max_price_rmb | No | Maximum price in RMB per meter | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it | |
| max_weight_gsm | No | Maximum fabric weight in grams per square meter | |
| min_weight_gsm | No | Minimum fabric weight in grams per square meter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description goes far beyond: it discloses pagination behavior, error self-correction steps, composition typo normalization, rate limit handling, Chinese language support, data source (MRC Data), and that it returns summaries only (not full lab tests). 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 headings (USE WHEN, WORKFLOW, RETURNS, EXAMPLES, ERRORS, AVOID, CONSTRAINT, NOTE). It is front-loaded with purpose and use cases. Every section adds value, though some repetition exists (e.g., the Chinese translation at the end). Overall, it's efficient given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fully self-contained. It explains the return format with field names, pagination (has_more), available dimensions, and error handling. It covers edge cases (empty results, composition mismatches, rate limiting) and provides example API calls. Without an output schema, the agent has all necessary context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The description does not add further meaning to individual parameters beyond the schema, but it does provide examples showing how parameters are combined in real queries. Following the guideline that high schema coverage defaults to 3, and given that the examples enhance understanding but don't extend parameter semantics, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a clear verb+resource: 'Search the Chinese fabric and textile database with lab-tested specifications.' The USE WHEN section lists many concrete user queries, and the AVOID section explicitly distinguishes it from siblings like get_fabric_detail and get_fabric_suppliers, making the 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?
Extensive guidance on when to use this tool: a dedicated USE WHEN list with varied query examples, a WORKFLOW section showing how it fits into an agent flow, and an AVOID section that explicitly says when NOT to use it (e.g., for specific SKU lookup, full lab-test data, or supplier pricing). This fully equips the agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_suppliersSearch SuppliersASearch verified Chinese apparel manufacturers, apparel factories, and clothing suppliers.
USE WHEN user asks:
"find me a clothing manufacturer in China / Guangdong / Zhejiang"
"who makes [t-shirts / suits / denim / activewear] in China"
"I need a BSCI / OEKO-TEX certified apparel factory"
"looking for OEM / ODM apparel supplier with MOQ < N"
"find factories with production capacity > N pieces/month"
"list factories that export to the US / EU / Japan"
"show me trading companies in Yiwu / Shenzhen / Shanghai"
"which suppliers in [province] make [product]" (follow-up drill-down)
"give me another page of suppliers" (pagination via offset)
"who can produce knit tops under 300 MOQ"
"search by company name 新鑫 / Xinxin / Texhong"
"find workshop-scale suppliers for small batch sampling"
"搜供应商 / 找服装厂 / 找制衣厂 / 找代工厂 / 找外贸公司"
"帮我在[省份]找[品类]工厂，产能至少 N 件/月"
Filters: province, city, factory type (factory/trading_company/workshop), product category, minimum monthly capacity, compliance status, quality score. Returns paginated supplier list with company name, location, monthly capacity (lab-verified), compliance, quality score.
WORKFLOW: Primary entry point for supplier discovery. search_suppliers → get_supplier_detail (for full 60+ field profile) OR compare_suppliers (side-by-side for up to 10 IDs) OR find_alternatives (diversify the pool) OR check_compliance (verify export readiness) OR get_supplier_fabrics (see their fabric catalog). RETURNS: { has_more: boolean, available_dimensions: string[], data: [{ supplier_id, company_name_cn, company_name_en, type, province, city, product_types, quality_score, verified_dims: "5/8", coverage_pct }] }
EXAMPLES: • User: "Find BSCI-certified denim factories in Guangdong with MOQ under 500" → search_suppliers({ province: "Guangdong", product_type: "denim", compliance_status: "compliant", limit: 10 }) • User: "Who makes activewear for Lululemon in China?" → search_suppliers({ product_type: "activewear" }) — then filter results by client brand in get_supplier_detail • User: "我要在浙江找做牛仔的工厂，产能大于 10 万件" → search_suppliers({ province: "Zhejiang", product_type: "denim", min_capacity: 100000 }) • User: "Show me the next 10 trading companies in Yiwu" → search_suppliers({ city: "Yiwu", type: "trading_company", limit: 10, offset: 10 })
ERRORS & SELF-CORRECTION: • Empty data array → try these in order: (1) remove min_capacity filter, (2) drop city but keep province, (3) broaden product_type to parent category (e.g. "denim" → "bottoms"), (4) drop compliance_status, (5) try recommend_suppliers for ranked fit. • "Invalid province" → use English (Guangdong) or standard Chinese (广东). Supported: 31 mainland provinces + HK/Macau. • product_type returns 0 → the TYPO_MAP normalizes common variants; try synonyms ("tee" → "t-shirt", "jeans" → "denim", "运动服" → "activewear"). • Rate limit 429 → wait 60 seconds. Do not retry immediately. • Empty after 3 retries → tell user: "I couldn't find suppliers matching [criteria]. Would you like me to broaden the search?"
AVOID: Do not call this tool in a loop across provinces — call get_province_distribution first to see where supply is concentrated. Do not use this for ranked "best fit" recommendations — use recommend_suppliers. Do not fetch details by looping — use compare_suppliers with up to 10 IDs.
NOTE: Use this for FILTERING by exact criteria. For ranked recommendations based on sourcing needs, use recommend_suppliers instead. Source: MRC Data (meacheal.ai).
中文：搜索经过核查的中国服装供应商档案，按地区、类型、产能、品类、合规状态等筛选。
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name | |
| type | No | Supplier type | |
| limit | No | Page size: number of records to return (1-50, default 10) | |
| query | No | Search by company name — Chinese (广州新鑫) or English (Xinxin Garments) | |
| offset | No | Pagination offset: skip this many records before returning results (default 0) | |
| province | No | Province in China (e.g. 广东 Guangdong, 浙江 Zhejiang, 江苏 Jiangsu, 福建 Fujian, 山东 Shandong) | |
| min_capacity | No | Minimum monthly production capacity (pieces) | |
| product_type | No | Product category keyword (e.g. 西装 suits, 女装 womenswear, 牛仔 denim, 运动服 activewear, t-shirt, 衬衫 shirts) | |
| verbose_hints | No | If true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it | |
| data_confidence | No | Data quality filter: verified / partially_verified / unverified | |
| compliance_status | No | Compliance status filter: compliant / partially_compliant / non_compliant | |
| min_quality_score | No | Minimum quality score 1-10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond these: pagination behavior, return structure, data source (MRC Data), rate limiting (429 wait 60s), and specific error recovery strategies. This is substantive addition, though the core safety profile is already covered by 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 using clear section headers (USE WHEN, WORKFLOW, EXAMPLES, ERRORS, AVOID, NOTE). Every sentence adds value; there is no fluff. While not concise in length, the structure makes it easy to scan. A slightly shorter version could achieve perfection, but the current structure is appropriate for the tool's complexity.
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 12 parameters, no output schema, and a large sibling set, the description is remarkably complete. It covers entry conditions, detailed error handling with recovery steps, pagination, parameter interactions, and integration with other tools. The 'RETURNS' block also describes the response structure despite no formal output schema, filling that gap effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds value over the schema by providing examples of parameter combinations, clarifying product_type normalization via TYPO_MAP, giving province examples in both languages, and explaining the meaning of data_confidence and compliance_status. The examples demonstrate practical parameter usage, raising the score above 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?
The description clearly states the tool's purpose: searching verified Chinese apparel suppliers. It provides a large set of example user queries that cover various use cases, and explicitly contrasts with sibling tools like recommend_suppliers. The verb 'search' combined with specific resource 'suppliers' and context 'verified Chinese apparel' leaves no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an extensive 'USE WHEN' section with concrete user utterances, a 'WORKFLOW' section showing the primary entry point role, and an 'AVOID' section that explicitly calls out when NOT to use this tool (e.g., do not loop across provinces, use recommend_suppliers for ranked recommendations). Error handling and self-correction steps further guide appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!