Supplier scoring, AQL sampling plans and factory audit checklists for cross-border sourcing.
Scored across 3 tools
Each tool addresses a clearly distinct function: sampling plan calculation, factory audit checklist generation, and supplier scorecard evaluation. There is no overlap or ambiguity between the three tools.
All tool names follow the same descriptive snake_case pattern using a domain-specific noun phrase (aql_sampling_plan, factory_audit_checklist, supplier_evaluation_scorecard). The naming is consistent and predictable.
Three tools is well-scoped for this niche supplier sourcing and QC domain. Each tool provides a distinct, valuable capability without unnecessary bloat.
The tool set covers the main QC and sourcing workflow: supplier evaluation, factory audit, and AQL sampling. Minor gaps exist such as corrective action tracking or inspection report generation, but these are not critical for the stated purpose.
按 ISO 2859-1（一般检验水平 II·正常检验·单次抽样）计算 AQL 抽样计划。
输入整批数量 lot_size 与 AQL 值（支持 1.0 / 2.5 / 4.0），返回样本量、接受/拒收 判定值（Ac/Re）与按缺陷等级（致命/主要/次要）的常用 AQL 组合建议。
| Name | Required | Description | Default |
|---|---|---|---|
| aql | No | AQL 值，可选 1.0 / 2.5 / 4.0（默认 2.5，即主要缺陷的常用值）。 | |
| lot_size | Yes | 整批数量（单位：件/pcs）。 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It discloses key behavioral constraints: the exact standard and variant (GIL II, normal, single sampling), the supported AQL values (1.0/2.5/4.0), and the kinds of results returned. It does not mention handling of unsupported AQL values or extreme lot sizes, but this is a minor gap for a calculation 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?
The description is two tight sentences with the standard and core function front-loaded. Every clause carries information: standard, inspection level, sampling type, inputs, supported AQL values, and outputs. No 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?
For a deterministic calculation tool with an output schema, the description fully covers the standard, inputs, supported values, and result contents. An agent can decide to invoke it and knows what to expect without needing additional context.
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 the schema already fully documents lot_size and aql, including the default and allowed values. The description mostly restates this same information and adds no deeper parameter semantics beyond what the schema provides.
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 clearly states a specific verb+resource: it computes an AQL sampling plan per ISO 2859-1, with concrete inputs (lot_size, AQL) and outputs (sample size, Ac/Re, defect-class suggestions). It is immediately distinguishable from the sibling audit/checklist and supplier-scorecard tools.
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?
The description gives clear context: use this when you need an ISO 2859-1 single-sampling plan at General Inspection Level II with normal inspection. It does not explicitly name alternatives or exclusions, but the sibling tools are unrelated domains, so the intended usage is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
返回验厂核查清单（社会/质量/供应链安全）与出货前质检类型说明。
支持 audit_type: BSCI / SMETA / SA8000 / ISO9001 / C-TPAT / ALL（返回全部）。
| Name | Required | Description | Default |
|---|---|---|---|
| audit_type | No | 验厂类型，可选 BSCI / SMETA / SA8000 / ISO9001 / C-TPAT / ALL（默认 ALL）。 | ALL |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the transparency burden. The verb '返回' (returns) implies a read-only operation with no side effects, which is some transparency, but it doesn't disclose permissions, data source, or any limitations. There is no contradiction since no annotations exist.
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 efficient sentences with no filler: the first states the purpose and the second lists supported values. All information is front-loaded and every sentence earns its place.
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 simplicity (one optional parameter) and the presence of an output schema, the description is mostly complete. It covers what the tool returns and the supported audit types, though it omits any context about when to choose different audit types, which is more of a usage-guidelines 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 coverage is 100% and the schema already documents the audit_type parameter with its allowed values. The description adds context that the output includes both audit checklists and pre-shipment inspection type explanations, but it largely repeats the schema's options rather than adding deep semantic meaning.
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 clear verb ('返回' – returns) and resource (factory audit checklist and pre-shipment inspection type descriptions), and adds specificity by listing social/quality/supply chain safety categories. It doesn't explicitly name sibling tools or contrast with them, but the resource scope is distinct enough from aql_sampling_plan and supplier_evaluation_scorecard.
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?
No guidance is provided on when to use this tool versus the sibling tools or when to select a specific audit type. There is no mention of context, exclusions, or alternatives, leaving the agent to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
供应商六维评估打分卡：输入各维度 1-5 分，输出加权总分、红黄绿评级与行动建议。
六维：quality(质量体系)、legitimacy(资质合法性)、capacity(产能与设备)、 price(价格竞争力)、delivery(交期信誉)、compliance(社会与环保合规)。
| Name | Required | Description | Default |
|---|---|---|---|
| price | Yes | 价格竞争力评分 1-5（报价/账期/起订量）。 | |
| quality | Yes | 质量体系评分 1-5（ISO 9001/QC 流程/三级检验）。 | |
| capacity | Yes | 产能与设备评分 1-5（产线/自动化/旺季弹性）。 | |
| delivery | Yes | 交期信誉评分 1-5（准时率/急单响应）。 | |
| compliance | Yes | 社会与环保合规评分 1-5（BSCI/SMETA/环保）。 | |
| legitimacy | Yes | 资质合法性评分 1-5（执照/进出口资质/真实工厂）。 | |
| supplier_name | No | 供应商名称（可选，用于报告抬头）。 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the input range (1-5 per dimension), the transformation (weighted calculation), and the output structure (total score, rating, action suggestions). It does not explicitly confirm side-effect-free behavior or computation details like weights, but the core behavior is transparent for a scoring 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?
The description is compact and front-loaded with the essential input-output contract, then follows with a clean enumeration of the six dimensions. Every sentence adds useful information without redundancy or 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?
For a tool with six required integer parameters and a rich input schema, the description covers the purpose, input dimensions, scoring range, and output categories. Since an output schema exists, return values do not need to be detailed here. The only notable gap is explicit usage guidance versus sibling tools, but the overall calling context is sufficiently complete.
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 each parameter in the input schema already has a detailed Chinese description. The tool description lists the six dimensions and their names but adds little beyond what the schema already provides, so the baseline score of 3 is appropriate.
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 clearly states the tool's function: input six dimension scores from 1-5 and output a weighted total, red-yellow-green rating, and action recommendations. This specific verb-resource framing distinguishes it from sibling tools like aql_sampling_plan and factory_audit_checklist, which serve different quality workflows.
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?
The description implies this tool is for supplier evaluation scoring, but it never explicitly states when to use it versus the sibling tools or when not to use it. The context is clear enough from the six named dimensions, but there is no direct routing guidance or exclusion criteria.
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.
aql_sampling_planfactory_audit_checklistsupplier_evaluation_scorecardSearch 4.8M verified Chinese factories: profiles, contacts, AI deep-dives, agentic sourcing.
Export compliance & HS code lookup for cross-border electronics sellers and factories.
Global B2B trade: verified manufacturers, product search, sanctions screening, HS codes.
Supplier sourcing, procurement, commercial intelligence, RFQ routing and B2B deal coordination.
Add one secure layer between your agents and this server.
