Skip to main content
Glama

MRC Data — China's Apparel Supply Chain Infrastructure

by ai.meacheal

Get Fabric Detail

get_fabric_detail
Read-onlyIdempotent

Get 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 检测指标）。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fabric_idYesFabric ID from search_fabrics results, e.g. FAB-W007
verbose_hintsNoIf true, response includes _interpretation annotations explaining what the data means and _guidance on how to use it

TDQS

A4.6/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All MRC Data — China's Apparel Supply Chain Infrastructure toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Resources