CNC Compass

Get a CNC Compass supplier record

get_supplier

Read-onlyIdempotent

Return one published supplier record in full, by the slug from search_suppliers results.

    Includes identity (legal name, Chinese registered name when a registry lookup confirmed it, location, business type, founded year, employee range), the
    official website or source listing, the Made-in-China.com inquiry form when there is one,
    capabilities (processes, materials, certifications, equipment, industries, tolerance, maximum
    part size) and the facet keys search_suppliers matches, certificates, product families,
    facilities and news items with their own source pages, the listings the record was read from
    with permission basis and check date, and field-level evidence (the quote, page, extraction
    method, and review status behind each claim). `buyer_facts.checked` lists what CNC Compass confirmed (registry review,
    source factory, certificates on China's national register, a named third-party audit);
    `buyer_facts.profile` is what the supplier publishes about itself (tolerance, inspection, lead time,
    MOQ, Incoterms, payment terms, ...), each item with its quote and source page: present it as the
    supplier's statement, to be confirmed at quotation. `verification_status`, `factory_verification`
    ("Verified source factory" or empty) and `last_verified_at` report editorial review.
    An unknown slug is a tool error.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`slug`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes
`news`	No
`slug`	Yes
`facets`	No
`sources`	No
`summary`	No
`evidence`	No
`location`	No
`page_url`	No
`products`	No
`equipment`	No
`materials`	No
`processes`	No
`tolerance`	No
`facilities`	No
`industries`	No
`legal_name`	No
`buyer_facts`	No
`inquiry_url`	No
`website_url`	No
`certificates`	No
`country_code`	No
`founded_year`	No
`website_kind`	No
`business_type`	No
`certifications`	No
`employee_range`	No
`last_verified_at`	No
`maximum_part_size`	No
`chinese_legal_name`	No
`verification_status`	No
`factory_verification`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 7, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations declare readOnly/idempotent/no-open-world, and the description goes well beyond them: it defines the error behavior for unknown slugs, disambiguates `buyer_facts.checked` (CNC Compass-confirmed) vs `buyer_facts.profile` (supplier self-published) and instructs how to present the latter ('as the supplier's statement, to be confirmed at quotation'), and explains what `verification_status`/`factory_verification` mean.

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

Conciseness3/5

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

Purpose is front-loaded, but the single dense paragraph then enumerates a large portion of the return payload (identity, capabilities, facet keys, facilities, news, evidence) which the tool already has an output schema for. That field-by-field inventory is redundant against structured output and inflates the description.

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

Completeness4/5

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

For a one-parameter read tool with an output schema and full annotations, the description is more than sufficient: it covers provenance of the input, the error case, and the interpretation rules for the trickiest fields. The only shortfall is that the return-field recap duplicates the output schema rather than adding new guidance.

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 0% (the only param is a bare `string` named `slug`), so the description must carry the meaning — and it does, telling the agent the slug originates from search_suppliers results. It does not add format or normalization details, but the provenance hint is the key semantic an agent needs.

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?

Opens with a specific verb and resource: 'Return one published supplier record in full, by the `slug` from search_suppliers results.' It immediately distinguishes itself from the sibling search_suppliers by scope (single record vs. search results) and names the keying parameter.

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

Usage Guidelines4/5

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

It clearly states where the required input comes from ('the `slug` from search_suppliers results') and defines the failure case ('An unknown slug is a tool error'), which routes the agent to search first. It stops short of an explicit when-not-to-use statement or naming alternatives beyond the slug source.

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

All CNC Compass tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?