对一组零部件（BOM，物料清单）做两两兼容性矩阵。输入已有条目 ID（可含开源贡献层 OSS-xxx），返回每个组合在 protocol/electrical/mechanical/software 四维的判定与理由。判定基于厂商公开声明字段的规则推断而非实测；未声明维度记为无法判定，不会为了填满矩阵而编造结论。返回的 verdict_reason 才是结论依据，overall_compatible=null 表示"证据不足"，不等于不兼容。
| Name | Required | Description | Default |
|---|---|---|---|
| component_ids | Yes | 待校验的零件 ID 列表，如 ["ACT-001","SENS-001","PROTO-012"]。ID 必须真实存在：先用 search_components 取得，不要自行拼造（ID 前缀与 category 非一一对应）。支持主库零件与开源贡献层 OSS-xxx 混合。至少传 2 个才有意义。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral transparency burden. It discloses that verdicts are rule-based inferences from vendor-declared fields, not physical tests; that undeclared dimensions are marked undetermined; and that it will not fabricate conclusions. It also clarifies the critical meaning of overall_compatible=null as 'insufficient evidence', not 'incompatible', and states that verdict_reason is the authoritative basis.
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 front-loaded with the core purpose, then adds only high-value behavioral caveats: inference vs. testing, no fabricated conclusions, null semantics, and reliance on verdict_reason. Each sentence earns its place; there is no fluff or redundant restatement of the tool name.
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 (pairwise matrix, four dimensions, no output schema, no annotations), the description is unusually complete. It covers what the tool does, how verdicts are derived, how missing data is handled, and how to interpret null results. It even points to the authoritative field (verdict_reason), leaving no major decision ambiguity for the agent.
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?
The schema already provides 100% parameter coverage, including ID examples, requirement to use search_components, OSS support, and a minimum of 2 IDs. The tool description adds minimal semantics beyond this—mostly repeating 'existing IDs', 'OSS-xxx', and the two-ID minimum. Therefore, the baseline of 3 applies; 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?
The description opens with a specific verb and resource: '对一组零部件做两两兼容性矩阵' (perform pairwise compatibility matrix on a BOM), clearly distinguishing this from the generic sibling check_compatibility. It also names the four evaluation dimensions (protocol/electrical/mechanical/software) and the return type, making the tool's scope unmistakable.
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 and schema give clear usage context: IDs must already exist, should be obtained via search_components, OSS-xxx entries are allowed, and at least 2 IDs are needed for meaningful results. It does not explicitly state when not to use this tool versus the sibling check_compatibility, so a small exclusionary gap remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
多个工具处理重叠的任务：check_compatibility、review_compatibility 和 bom_compatibility_check 都涉及兼容性验证，其中前两个尤其相似，第二个使用了与第一个相同的引擎，可能是多余的。此外，search_components 和 semantic_search 重叠但具有不同机制。虽然这些描述有所澄清，但代理仍可能选择错误工具（例如，当简单检查就足够时使用了 review_compatibility）。
大多数名称遵循 verb_noun 模式（get_component_detail、search_components、review_compatibility），但有几个偏差：semantic_search 是 adjective_verb 而非 search_semantic，而 bom_compatibility_check 将操作放在最后，与 check_bom_compatibility 相反。模式的不一致性削弱了可预测性。
使用 9 个工具，组件覆盖了搜索、详情、参数语义、标准审计、推荐以及兼容性检查的多个变体——表面上足够广，但没有膨胀。每个工具针对不同的检索或分析需求，使其合理且可管理。
该表面涵盖了该领域的大部分关键功能：搜索、详情、语义标准化、标准审计、推荐以及通过三种模式进行的兼容性检查。缺失 CRUD 操作可能表明它是一个只读库，但没有任何接口来创建或更新部件，这限制了对数据库的管理。总体而言，对于查询和验证，覆盖范围相当完整，仅有边缘缺口。