Loading ToolBench
The first and only MCP server providing structured Chinese fashion supply chain intelligence for AI platforms. Covers millions of Chinese apparel supply chain entities — 3,000+ manufacturers, 350+ fabrics, and 170+ industrial clusters with 63+ dimensions per record and lab test reports.
MRC Data is a thin STDIO proxy client to a remote API. Tool definitions are visible in index.js and show consistent naming (verb_noun pattern: search_*, get_*, detect_*, compare_*), non-empty descriptions for all 11 tools, and input schemas with typed parameters. However, there are significant gaps: (1) Parameter descriptions lack detail and actionable constraints. For example, 'province' is described simply as 'Filter by province (e.g. 'guangdong')' without noting valid values, enum constraints, or case sensitivity. (2) Output schemas are NOT documented, the rubric requires tools to declare what they return so LLMs can plan downstream calls. The test script reveals output structure (e.g. total_matches, data, has_more, limit) but this is not in the tool definitions themselves. (3) Error handling descriptions are absent. Tools do not explain how to recover from invalid IDs, missing fields, or API failures. (4) Several parameter descriptions include bare example values ('e.g. guangdong', 'e.g. knit'), which the rubric flags as anti-pattern, LLMs may reuse these literally. (5) No security or permission documentation (though all tools are read-only, the definitions don't declare this). Overall, the definitions are functional but lack the depth, constraints, and output documentation required for an A or B grade.
Compare multiple industrial clusters by IDs
Demo endpoint providing sample data without authentication
Detect data discrepancies in the database for a specific field with optional minimum discrepancy percentage
Retrieve detailed information for a specific fabric by ID
Retrieve suppliers associated with a specific fabric
Retrieve database overview statistics
Retrieve detailed information for a specific supplier by ID
Output schemas not documented. Tool definitions describe input parameters but nowhere specify what fields/structure LLMs should expect in responses. The test script reveals outputs include 'total_matches', 'data', 'has_more', 'limit', but LLMs cannot infer this from the tool definitions alone. LLMs need to know: Is the response a list? A single object? What fields are present? This prevents planning downstream calls and forces agents to guess. Required by pattern:tool and pattern:paginated-result.
Parameter descriptions lack actionable constraints and enums. Examples: 'province' has no enum of valid values (Guangdong, Zhejiang, etc.); 'product_type' ('e.g. sportswear') lacks a complete enum; 'category' ('e.g. knit') is under-specified; 'field' in detect_discrepancy has no list of valid fields. The rubric (pattern:constrained-input) requires enums for known value sets. Free-form strings invite LLM hallucination. Additionally, bare example values in descriptions are anti-pattern (review:param-validation-rules), LLMs reuse literal values.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | <=2025-11-25 | v2 |
Retrieve fabrics associated with a specific supplier
Search industrial clusters with filters for province and pagination
Search fabrics with filters for category, weight range, composition, and pagination
Search suppliers with filters for province, product_type, and pagination
No error recovery guidance. Tool descriptions do not specify what errors are possible or how LLMs should recover. E.g., get_supplier_detail with an invalid supplier_id, does it return 404? A structured error? Should the LLM retry, call search_suppliers first, or abort? The rubric (pattern:recovery-guide) mandates: 'Error responses must tell the LLM what to do next.' Actionable example: 'Supplier not found. Try search_suppliers() with partial name.'
Missing parameter type specificity. 'ids' in compare_clusters is described as 'Comma-separated cluster IDs' (string), but no constraint on count (how many IDs?), format (IDs are strings of what format?), or separator validation. Similarly, 'limit' and 'offset' lack min/max bounds. Rubric requires: 'Specify minimum and maximum for numeric parameters.' Actionable: limit should be 1 - 100, offset >= 0.
No security or permission declarations. All 11 tools are read-only (data retrieval only), but this is not explicitly documented in tool descriptions or via toolAnnotations. The rubric (pattern:scope-declaration, pattern:secret-injection) requires clarity: 'Each tool should declare what permissions it requires.' Additionally, no mention of readOnlyHint annotation (pattern:tool-annotation), which would signal to agents/clients that these operations are side-effect-free.
Vague descriptions for some tools. 'get_stats' is described as 'Retrieve database overview statistics', what statistics? What fields? What is the use case? 'demo' is 'Demo endpoint providing sample data without authentication', sample data about what? When should LLM use demo vs. authenticated tools? Descriptions should answer: What does it do? When to use it? What does it return? (pattern:tool-description requires 10 - 1024 chars with complete context.)