Search reviewed Chinese CNC machining suppliers, with each fact linked to its source page.
Scored across 3 tools
The three tools occupy clearly separate roles: search_suppliers discovers records via a sourcing brief, get_supplier retrieves one full record by slug, and list_facets enumerates filterable values. No two tools overlap in purpose, and the slug handoff between search and get is explicit.
All three names follow a clean snake_case verb_noun pattern (get_supplier, list_facets, search_suppliers). The convention is uniform and predictable, with verbs that match each tool's actual action.
Three tools is at the low edge but each earns its place for a read-only supplier directory: discovery, detail, and facet enumeration. It is slightly thin (no compare or bulk-export helper), but nothing is redundant.
The read-only lifecycle is fully covered: find suppliers, filter by facets, and fetch a complete record with evidence. The main gap is that there is no way to browse the whole index (a fieldless brief returns a follow-up question), but this appears intentional and minor.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
List the values search_suppliers can filter on, with how many published suppliers declare each.
Fields are process, material, finish, and location; pass `field` for one of them. Each value has
a stable `key`, a display `label`, a `records` count, and `implies` (broader keys a narrower one
also matches, such as aluminum-6061 implying aluminum). Pass a label or key as the matching
optional argument of search_suppliers. Locations are the city and province words that at least
three supplier addresses share, most common first; `omitted_values` counts the rarer ones, which
search_suppliers still matches. `index_records` is the number of published suppliers.
| Name | Required | Description | Default |
|---|---|---|---|
| field | No |
| Name | Required | Description |
|---|---|---|
| fields | No | |
| index_records | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this readOnly/idempotent, so the description correctly focuses on behavior the annotations can't convey: locations are city/province words shared by at least three addresses, sorted most-common-first, with rarer values rolled into `omitted_values` (still matchable), and `index_records` as the published total. Only missing detail is whether `field` is required for a usable response.
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?
Front-loaded with the core purpose, then progressive detail on fields, keys, implies, and location semantics. Slightly dense with several distinct facts packed in, but every sentence carries information the agent needs.
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?
An output schema exists, so return shape needn't be restated, yet the description still explains the meaning of the returned fields (key, label, records, implies, omitted_values, index_records). Combined with the sibling cross-reference, an agent has everything needed to call and interpret this 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 0% and the single `field` param has no description or enum, but the description compensates by enumerating the four legal values (process, material, finish, location) and stating its role in selecting a facet. That is meaning well beyond the bare `anyOf[string, null]` 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?
States a specific verb and resource — listing the filter values that search_suppliers accepts — plus the scope (published suppliers). It clearly separates itself from search_suppliers (which filters) and get_supplier (which fetches one record) without needing the schemas.
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?
Explains that the fields are process, material, finish, and location and that `field` selects one, then closes the loop by telling the agent to pass a returned label or key as the matching optional argument of search_suppliers. No explicit when-not or exclusion, but the workflow context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search published CNC Compass supplier records with a natural-language sourcing brief.
Returns the normalized brief, the fields the brief did not state, matched suppliers with
match reasons and source evidence, the filters applied with record counts, and paging
fields (offset, limit, has_more). A brief with no recognisable process, material, finish,
or location returns no records and a follow-up question instead of the whole index.
`query` is 3 to 5000 characters, `limit` 1 to 20, `offset` 0 to 1000. When you already
know the buyer's material, process, finish, or location, pass them as the optional
fields: each overrides the parsed value (for example material="aluminum 6061",
process="CNC turning", finish="anodizing", location="Dongguan"); a value the index cannot
match is ignored and listed in `retrieval.ignored_fields`.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| finish | No | ||
| offset | No | ||
| process | No | ||
| location | No | ||
| material | No |
| Name | Required | Description |
|---|---|---|
| brief | Yes | |
| limit | No | |
| answer | Yes | |
| offset | No | |
| filters | No | |
| missing | No | |
| has_more | No | |
| retrieval | No | |
| suppliers | No | |
| index_records | No | |
| total_records | No | |
| follow_up_question | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), and the description adds substantial behavioral context beyond them: the exact fallback when no process/material/finish/location is recognized (no records + follow-up question instead of the whole index), the override precedence of optional fields over parsed values, and the ignored_fields reporting. This is rich, non-obvious disclosure that helps the agent anticipate outcomes.
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?
It is front-loaded with purpose and returns, then constraints, then override semantics, and every sentence carries information. It is somewhat dense with parenthetical examples and a stray leading indentation, but nothing is filler.
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?
An output schema exists, so explaining return fields is partly redundant, but the description's coverage of the no-match fallback, override precedence, and paging fields makes the tool fully callable and predictable. It is complete for a search tool; only explicit sibling routing is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the full burden, and it does: query length 3-5000, limit 1-20, offset 0-1000, and the semantics of the optional material/process/finish/location fields with concrete examples and the override/ignored-value rule. Every one of the 7 parameters gets meaning that the bare schema does not provide.
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 states a specific verb and resource ('Search published CNC Compass supplier records') and clarifies the input modality ('natural-language sourcing brief'), which clearly separates it from a single-record lookup like get_supplier. It does not explicitly name or contrast the siblings (get_supplier, list_facets), so it stops short of a 5.
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?
Usage is implied rather than prescribed: the agent can infer this is the discovery/query tool and that get_supplier is the detail lookup, but the description never says when to choose this versus the siblings. The edge-case guidance (empty brief returns no records plus a follow-up question) is useful but is behavioral, not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_supplierlist_facetssearch_suppliersSearch 4.8M verified Chinese factories: profiles, contacts, AI deep-dives, agentic sourcing.
Find manufacturers worldwide, match a part spec to suppliers, estimate cost, request quotes.
Search 160M+ Chinese court judgments; verify case numbers and quotes.
China sourcing, inspection and supplier verification: published rates, scope and fee estimates.
Add one secure layer between your agents and this server.
