RoboParts 机器人零部件兼容性

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does a good job: it explicitly states conclusions are rule-based on manufacturer public declarations, not lab-tested, and that undeclared dimensions are marked as 'cannot determine' and not counted as compatible/incompatible. This is valuable behavioral context for an agent interpreting results, though it does not cover authentication or side effects, which are likely less relevant here.

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 concise sentences: the first states the main purpose and return types, the second delivers an important caveat about inference basis and undeclared dimensions. It is front-loaded, every sentence adds value, and there is no redundant or vague wording.

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 a 2-parameter tool with no output schema, the description sufficiently explains the core behavior: what it returns (per-dimension, overall, confidence) and the inference logic. It lacks a concrete output format example, but the stated return categories and the detailed parameter schema make the tool actionable. A fully exhaustive spec would be excessive for this simplicity.

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 baseline is 3. The description itself does not add parameter-specific semantics beyond the schema, which already thoroughly explains ID format, retrieval via search_components, and the ID-prefix mismatch warning. The description's mention of the four dimensions is context for the tool's logic, not parameter syntax, so it does not elevate the score.

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 uses the specific verb '判定' (determine) and clearly identifies the resource: compatibility of two components across four stated dimensions (protocol/electrical/mechanical/software). It also lists what the tool returns (per-dimension conclusions, overall judgment, confidence), distinguishing it from sibling tools like get_component_detail or recommend_for_application.

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 the tool is for cross-component compatibility checking and even notes in the parameter schema that cross-category comparison is this tool's purpose. However, it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria, though the context is clear enough for an agent to infer appropriate use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It mentions the returned content (metadata fields) and context, but does not explicitly disclose whether this is a safe read-only operation, error behavior, or the exact-match requirement (the latter is in the schema, not the description). The 'verify evidence strength' purpose hints at non-destructive use, but lacks explicit behavioral guarantees.

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 main action and resource, followed by a concise use-case statement. Every word earns its place; no filler or repetition.

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?

The tool has a single parameter and no output schema, yet the description covers purpose, return fields, and use context. The schema supplements with matching rules. It lacks an explicit 'not found' behavior or output format, but given the simplicity, it is adequately complete for an agent to select and invoke correctly.

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 describes the id parameter in detail (exact match, case sensitivity, no fuzzy lookup, suggestion to get from search_components, ID prefix caution). Schema description coverage is 100%, so the baseline is 3. The description itself adds no additional parameter semantics beyond mentioning the ID.

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 verb '获取' (get) and the resource '单个零部件的完整字段' (complete fields of a single component), distinguishing it from sibling tools like search_components (search) or check_compatibility (compatibility). It also lists specific metadata fields, leaving no ambiguity about its function.

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 provides a clear use context: '用于在做出采购/设计决策前核对证据强度' (used to verify evidence strength before procurement/design decisions). The schema additionally advises obtaining the ID from search_components, implying a sequential workflow. However, it does not explicitly exclude alternative tools or state when not to use it, so it's not a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full transparency burden. It discloses important behavioral context: the database contains many torque/speed variants (19 torque calibers, 37 speed calibers, even Gbps and rad/s mixed in), and the tool returns normalization aids rather than modifying data. It does not state edge cases like failure modes, but it goes well beyond a bare 'return parameter semantics' statement.

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 sentences, front-loaded with the core purpose, and every clause earns its place: the first sentence establishes the problem (semantic ambiguity), and the second lists the outputs and use case. There is 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 zero-parameter metadata lookup tool, the description is complete: it explains why the tool exists, the data-quality issues it addresses, what it returns, and how to apply the result. Since there is no output schema, the detailed enumeration of return components (physical red lines, unit conversions, comparability grades, vendor inquiry list) is sufficient.

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 tool has zero parameters and the input schema is empty, so the baseline is 4. The description adds context about the domain (torque/speed calibers and unit ambiguity) that helps an agent understand what the tool operates on, even though there are no explicit parameters to document.

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 action ('获取参数口径规范') and clearly identifies the resource (parameter definition norms). It then lists concrete outputs (physical red lines, unit conversion, comparability grading, vendor inquiry checklist) and states the intended use ('判断两份参数表到底能不能直接比较'), which distinguishes it from sibling tools like search_components or recommend_for_application.

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 explicitly states when to use the tool: when determining whether two parameter tables can be directly compared, especially in cross-vendor contexts with ambiguous units. It does not explicitly name sibling tools or state when not to use it, but the context is clear enough for an agent to select it appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 fully explains the tool's operation: it is an automated cross-validation, read-only in nature (returns results), not a compatibility ruling, and it identifies unverifiable entries and gaps. It also states the intended follow-up (manual evidence completion), providing rich context beyond a simple 'returns audit results'.

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 consists of three sentences, each adding valuable information: what it returns, what it is not, and what it is for. While not as terse as a two-sentence ideal, every sentence earns its place and there is no redundancy.

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 a single optional parameter and no output schema, the description covers the main output categories (verifiable, unverifiable, gaps, coverage) and clarifies the non-goal (compatibility ruling). It lacks explicit detail about the exact report structure or response format, but this is not critical given the simple parameter and the thorough narrative description.

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 input schema already provides a 100% documented parameter with an enum and default ('scope: all/conflicts'), so the baseline is 3. The description adds no specific parameter-level semantics beyond the overall purpose, but that is acceptable given the schema coverage is complete.

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 returns cross-validation results between standard registration forms and entity declarations, specifying what it verifies (mechanical/bus declarations) and what it indicates (gaps, coverage). It explicitly distinguishes itself from compatibility checks by stating 'not a compatibility ruling', which separates it from siblings like bom_compatibility_check and check_compatibility.

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 provides clear context for use: it is a data quality self-check, not a compatibility ruling, and its purpose is to flag entries with questionable provenance for manual evidence completion. However, it does not explicitly name alternative tools to use instead (e.g., check_compatibility), leaving the when-not-to-use partially implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden. It discloses the heuristic nature and the need to verify against datasheets, which is useful. However, it does not mention fallback behavior (e.g., category listing when no match), price coverage limitations, or read-only characteristics; these are partly covered in the schema but not in the description itself.

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 three sentences long, front-loaded with the main purpose, followed by the return behavior and a necessary caveat. Every sentence adds useful information with no redundancy or fluff.

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?

No output schema exists, so the description should clarify return details. It mentions per-category candidates and reasons but omits count semantics, scene_matched flag, and price_fit behavior. However, the schema's parameter descriptions compensate for budget and application behavior, making the tool invocable despite the gaps.

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 fully documents all three parameters. The description only repeats the budget parameter's existence without adding new meaning, and it does not explain count or application semantics beyond what the schema already provides, so the baseline 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 recommends component combinations by application scenario and returns per-category candidates with reasons. It also characterizes the recommendation as heuristic and non-authoritative, which helps differentiate it from the sibling search_components tool, though it does not explicitly name that alternative.

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 clearly implies use for application-based recommendations and adds a caveat that it is not engineering advice. The application parameter's schema description explicitly directs users to search_components when no matches occur, providing an alternative path, but the main description lacks explicit when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even without annotations, the description reveals important behavioral traits: keyword does substring, case-insensitive, non-fuzzy matching; Chinese and English result sets may not overlap; multi-word queries are not AND-split; category values are exact with no aliases; market intelligence entries are hidden by default; and inventory metrics are intentionally not hardcoded to avoid drift. This goes far beyond a basic tool statement.

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 only three sentences, front-loads the purpose, and contains no redundant fluff. Every sentence contributes either to core functionality, scope, or a note about data freshness.

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?

The description covers return summary fields, category scope, behavior of each parameter, and points to external sources for inventory metrics. However, it states '10 个品类' (10 categories) while the schema enum includes 11 values (including connectors, flexible_actuators, etc.), creating a factual mismatch that could mislead an agent. No output schema exists, but the summary field list partially compensates.

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 baseline is 3. The description text adds no additional parameter-specific meaning beyond what is already in the schema's parameter descriptions. The only extra context is the note about inventory metrics, which is not parameter-related.

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 'searches robot components' with specific filters (category/keyword) and explicitly notes it returns summary entries (id/name/category/manufacturer/specs/evidence level). This distinguishes it from the sibling tool get_component_detail, which presumably returns full details.

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 context is implied through the description of search behavior and parameter guidance (e.g., keyword matching, category exact match), but there is no explicit mention of when to use this tool versus alternatives like get_component_detail or check_compatibility. No exclusions or 'when not to use' guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the semantic index is built offline with precomputed TF-IDF vectors, zero external calls, and zero external models, and that it falls back to keyword search with explicit notification. This is good transparency, though it doesn't detail return format or error handling.

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 concise and front-loaded, starting with the core purpose and example, then explaining the underlying mechanism and usage guidance. Every sentence adds value without redundancy.

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 moderate complexity, the description covers purpose, mechanism, usage guidance, and fallback behavior. It lacks explicit return format details, but since there is no output schema, the description could have mentioned what the response contains (e.g., component IDs, scores). Still, it's fairly complete for a search 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 description coverage is 100%, so the schema already documents both parameters well. The description adds context about the k parameter's trade-off (larger k means broader recall but more deviation from intent) and provides example queries for the query parameter, adding value beyond the 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?

The description clearly states the tool performs semantic recall using natural language queries to return the most similar components. It distinguishes itself from sibling tools like search_components (keyword substring matching) and check_compatibility (compatibility judgment), positioning itself as a 'discovery' channel.

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 explicitly states when to use this tool: when uncertain about exact part numbers or parameter names, semantic search is more robust than keyword substring matching. It also mentions fallback behavior to keyword search when the index is unavailable, providing clear usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.