Manufacturing capability graph for AI agents: materials, processes, tolerances, and instant quotes.
Scored across 5 tools
Each tool targets a clearly distinct resource/action: get_supplier vs search_suppliers, get_work vs search_works, and a separate capability dictionary lookup. Descriptions explicitly clarify boundaries, including that list_supplier_capability_rows is not a supplier list.
All tool names follow a consistent snake_case verb_noun pattern: get_, search_, and list_. The convention is predictable and readable throughout.
Five tools are well-scoped for a read-only supplier/work discovery server. Each tool has a distinct role and none appear redundant or missing from the core flow.
The surface covers supplier search/get, work search/get, and capability/process dictionary lookup, forming a coherent discovery lifecycle. Minor gaps may exist around pagination or richer filtering, but core agent workflows are supported.
Use when the user has a supplier_id or slug and needs the full public profile: location, capabilities, tolerances, materials, batch range, certifications, logo, equipment types (aggregated), and up to 20 recent works with image URLs. Contact email and phone are never returned. Use search_suppliers first if the supplier is unknown.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Canonical supplier slug. | |
| supplier_id | No | Public supplier id, e.g. sup_... |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the return surface, the aggregation of equipment types, the 20-works cap, and an important privacy exclusion (contact email and phone are never returned). It does not say what happens when a slug/id is not found, nor whether both identifiers can be supplied or which wins, leaving a small gap for a zero-required-param tool.
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?
Two sentences, front-loaded with the usage condition and the fallback alternative, then a dense but scannable field list. The enumeration is long ("logo" is marginal), but every element maps to real returned data, so there is little waste.
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?
There is no output schema, so the description must describe returns — and it does so in detail, including the recent-works subset and image URLs. The remaining omissions are error/not-found behavior and whether the works list is paginated, which are minor for a single-record fetch.
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 100%, so the baseline is 3; the description earns above that by framing the two parameters as alternatives ("has a supplier_id or slug"), which tells the agent one identifier suffices even though neither is marked required. It stops short of stating precedence when both are provided.
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+resource (fetch a supplier's full public profile) and enumerates exactly what that profile contains: location, capabilities, tolerances, materials, batch range, certifications, logo, aggregated equipment types, and up to 20 recent works. This is clearly distinguishable from search_suppliers and from the row-level sibling list_supplier_capability_rows.
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?
Gives an explicit trigger condition ("when the user has a supplier_id or slug and needs the full public profile") and an explicit alternative plus the condition that selects it ("Use search_suppliers first if the supplier is unknown"). No inference required to choose between the two tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use after search_works or when the user supplies a work_id. Returns the canonical work page URL and public supplier summary. No buyer, contact, price or inquiry data is included.
| Name | Required | Description | Default |
|---|---|---|---|
| work_id | Yes | Public work id, e.g. wk_... |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden, and it does disclose the data boundary: only public supplier summary and the canonical URL are returned, with buyer, contact, price and inquiry data explicitly excluded. It does not cover error behavior for an invalid or unknown work_id, which is the remaining gap for an unannotated read tool.
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?
Three short sentences, front-loaded with the usage trigger, then return contents, then the data exclusion. Nothing is redundant and nothing could be cut without losing information.
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 no output schema, the description supplies both the trigger and the shape of the return value plus its data boundaries. An agent has everything needed to call it correctly and to set expectations about the response.
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 100% and the single work_id parameter is documented with an example format ('wk_...') in the schema. The description only adds the trivial framing 'when the user supplies a work_id', so baseline 3 applies.
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 ('get_work') and immediately specifies the payload: the canonical work page URL and public supplier summary. It also names the sibling search_works, so an agent can distinguish lookup-by-id from discovery without opening either schema.
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?
Gives two clear trigger conditions: after search_works, or when the user supplies a work_id. The exclusion clause ('No buyer, contact, price or inquiry data') also signals that this tool is not the route for contact or pricing lookups. No explicit when-not statement, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user needs valid capability/process ids, category names, tiers or required equipment specs before searching suppliers or works. This is a curated L0 dictionary from grid_capabilities.csv and equipment_types.csv; it is not a supplier list.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows, default 90. | |
| category_id | No | Filter by category id, e.g. cnc-machining. | |
| capability_id | No | Filter by exact capability row id. | |
| equipment_type | No | Equipment type substring in English or Chinese. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral load, and it does the important part: it discloses the data provenance (two named CSVs), that the set is curated/L0 reference data, and that no supplier entities are returned. It does not discuss result volume or whether the dictionary is static versus refreshed, which keeps it from a 5.
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?
Two sentences, zero filler. The usage trigger leads, the identity/provenance and the negative disambiguation follow — exactly the order an 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?
There is no output schema, so the description should convey what comes back, and it does at the field-category level (ids, category names, tiers, equipment specs). A hint about row shape or default-90 behavior (only in the schema) would close the remaining gap.
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 100%, so all four filters (limit, category_id, capability_id, equipment_type) are already documented with examples and ranges. The description mentions the kinds of values returned but adds no filtering semantics or precedence rules beyond the schema, so the baseline 3 applies.
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 identifies the resource precisely: a curated L0 dictionary built from grid_capabilities.csv and equipment_types.csv that yields capability/process ids, category names, tiers and equipment specs. It also explicitly rules out the most likely misreading ("it is not a supplier list"), which separates it from search_suppliers and search_works.
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?
"Use when the user needs valid capability/process ids... before searching suppliers or works" gives an explicit trigger and even an ordering relative to the search siblings. It stops short of naming the alternatives by name or stating when not to call it, so it falls just under a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks which Chinese factories can make a part, which suppliers offer a process (CNC machining, injection molding, 3D printing, sheet metal, die casting, etc.), or wants suppliers filtered by region, certification or material. Returns only public L0 profile fields and canonical source URLs. Results are ranked by a public profile-completeness quality_score; no grid, price or payment fields are read.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, default 10. | |
| region | No | Province or city substring, e.g. Guangdong or Shenzhen. | |
| process | No | Process/capability id to match primary profile or recent work. | |
| material | No | Material substring, e.g. 6061 or titanium. | |
| category_id | No | Category id, e.g. cnc-machining. | |
| capability_id | No | Exact capability row id, e.g. cnc-machining/03. | |
| certification | No | Certification name, issuer or number substring. | |
| tolerance_max_mm | No | Only return suppliers whose declared tolerance is at or below this value in mm. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it discloses the return scope (public L0 profile fields plus canonical source URLs), the ranking basis (profile-completeness quality_score), and an explicit exclusion set (no grid, price or payment fields read), which signals a read-only, safe operation. It omits auth/permission requirements and whether results are paginated beyond the limit parameter.
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?
Three sentences, front-loaded with the usage triggers, followed by return scope and then ranking/exclusions. No restatement of the name or title and no filler; every clause adds either routing or behavioral information.
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 an eight-parameter, zero-required search tool with no output schema and no annotations, the description covers the important unknowns: what comes back, how it is ordered, and what data is deliberately not exposed. The main remaining gap is behavior with no filters supplied (return-all vs error) and any result-cap semantics, though the limit parameter partially covers the latter.
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 100%, so every parameter is already documented with examples (Guangdong, 6061, cnc-machining). The description only echoes the filterable dimensions at a high level and adds no syntax, matching behavior, or interaction semantics (e.g. process vs capability_id vs category_id) beyond what the schema states. Baseline 3 applies.
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 (supplier search) plus the domain scope (Chinese factories) and the concrete question shapes it answers. An agent can tell this is a discovery/listing tool rather than a detail fetch, but the description never names the sibling it is not (get_supplier, search_works), so differentiation is inferred from the triggers rather than stated.
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?
Gives three explicit trigger scenarios — part manufacturability, process capability lookup, and filtering by region/certification/material — which is well above typical guidance. It stops short of when-not-to-use or naming an alternative tool for single-supplier lookup, so the routing decision against get_supplier is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Core discovery tool. Use when the buyer asks for examples such as 'who has made a 6061-T6 medical endoscope housing to ±0.01 mm' or wants factories with experience in an industry. Returns work title, material, process, industry, tolerance, images and canonical source URL, plus supplier context. Results are newest-first. Works without English/published projection are excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, default 20. | |
| region | No | Supplier province or city substring. | |
| process | No | Capability/process id, e.g. cnc-machining/03. | |
| industry | No | Industry cluster or detail substring, e.g. aerospace or medical. | |
| material | No | Single material substring; alias for materials. | |
| materials | No | Material substrings; any match is accepted. | |
| supplier_id | No | Restrict to one supplier. | |
| tolerance_max_mm | No | Only return works with declared tolerance at or below this value in mm. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well: it discloses result ordering ('newest-first'), a non-obvious filtering rule ('Works without English/published projection are excluded'), and the returned fields. It omits pagination/limit behavior and any auth or performance characteristics, which keeps it short of a 5.
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 usage examples, then return shape and exclusions — every sentence carries information. The phrase 'English/published projection' is jargon that an agent may not resolve from the description alone, slightly reducing clarity.
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 no output schema and no annotations, the description supplies return fields, ordering, supplier context, and an exclusion rule — enough for correct invocation. It lacks explicit default/pagination guidance and cross-references to siblings for multi-tool workflows.
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 100%, so all eight parameters are already documented in the schema; the description only echoes the filter concepts (material, process, industry, tolerance) without adding syntax or precedence rules. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Core discovery tool' for works) and gives concrete example queries, so an agent knows it retrieves work/portfolio examples rather than suppliers. It does not fully separate itself from search_suppliers, since 'wants factories with experience in an industry' could plausibly be served by either tool.
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?
Provides concrete trigger examples ('who has made a 6061-T6 medical endoscope housing') that make the intended use case easy to recognize. However, it names no alternatives and gives no when-not-to-use guidance against the sibling search_suppliers or get_work.
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.
calculate_part_masscheck_equipment_capabilitycheck_material_environment_compatibilitycheck_service_temperaturecompare_equipmentcompare_materialscompare_processesfilter_materials_by_constraintfind_alternative_processesfind_equipment_by_processfind_equivalent_materialsget_equipment_qc_specsget_industry_requirementsget_iso2768_tolerancesget_material_complianceget_material_process_compatibilityget_process_specsget_supplierget_worklist_supplier_capability_rowsmatch_industry_materialsquote_calcsearch_materialssearch_supplierssearch_workscalculate_part_masscheck_equipment_capabilitycheck_material_environment_compatibilitycheck_service_temperaturecompare_equipmentcompare_materialscompare_processesfilter_materials_by_constraintfind_alternative_processesfind_equipment_by_processfind_equivalent_materialsget_equipment_qc_specsget_industry_requirementsget_iso2768_tolerancesget_material_complianceget_material_process_compatibilityget_process_specsmatch_industry_materialsquote_calcsearch_materials
Add one secure layer between your agents and this server.