Search reviewed Chinese CNC machining suppliers, with each fact linked to its source page.
Scored across 3 tools
The three tools have clearly distinct roles: search_suppliers finds suppliers, list_facets discovers filter values, and get_supplier retrieves one full record by slug. There is no meaningful overlap, and the descriptions make the transition from search to detail explicit.
All tools follow a consistent snake_case verb_noun pattern: search_suppliers, list_facets, get_supplier. The verbs accurately reflect each operation and maintain a predictable convention.
Three tools is well-scoped for a read-only supplier directory: discover facets, search suppliers, and retrieve a full supplier record. Each tool earns its place without redundancy.
The core read-only workflow is covered: facet discovery, search with paging, and detailed record retrieval. Minor gaps exist because list_facets does not expose certification values even though search_suppliers supports certification filtering, and there is no explicit browse-all/list operation beyond attribute-based search.
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,
certification, or location returns no records and a follow-up question instead of the whole
index. A stated certification (ISO 9001, IATF 16949, ISO 13485, AS9100, ISO 14001, ISO 45001,
RoHS) returns only suppliers whose listing shows it. `query` is 3 to 5000 characters, `limit`
1 to 20, `offset` 0 to 1000. When you already know the buyer's material, process, finish,
certification, or location, pass them as the optional fields: each overrides the parsed value
(for example material="aluminum 6061", process="CNC turning", finish="anodizing",
certification="IATF 16949", 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 | ||
| certification | 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 already declare read-only, closed-world, idempotent behavior, and the description adds substantial context beyond that: returned fields, no-match follow-up behavior, certification filtering, optional-field override semantics, and ignored_fields reporting.
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 definition is front-loaded and dense, with no obvious waste. Some return-field detail overlaps the output schema, but most of it adds behavioral meaning, so the length is largely justified.
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, the zero schema-description coverage, and the presence of annotations and an output schema, the description is complete enough for an agent to invoke the tool correctly. It covers input ranges, optional-field semantics, result behavior, and no-match handling.
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 parameter meaning, and it does: it documents query length, limit and offset ranges, optional material/process/finish/certification/location fields, override behavior, examples, and ignored_fields handling.
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: searching published CNC Compass supplier records using a natural-language sourcing brief. It is clear what the tool does, but it does not explicitly differentiate itself from siblings like get_supplier or list_facets.
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 gives clear usage context: use a natural-language brief, and pass known material/process/finish/certification/location fields when available. It also explains the no-match behavior. However, it does not explicitly say when to use get_supplier or list_facets instead.
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.
search_suppliers2 fields changedInput schema / properties / certificationAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Certification"
+}Output schema / $defs / SearchBrief / properties / certificationAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Certification"
+}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.
