Compute intersection volumes for every pair of parts in an assembly to identify and rank collisions by volume, returning an empty list when none exist.
Pairwise interference: compute volume of intersection between every pair of parts. Returns [{a, b, interference_mm3}, ...] descending by volume. Empty list = no interference.
| Name | Required | Description | Default |
|---|---|---|---|
| assembly | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden alone. It does disclose the return shape and the 'empty list = no interference' semantics, which is genuinely useful. However it never states that this is a read-only/non-mutating analysis, nor warns about cost (pairwise comparison scales quadratically with part count), which an agent needs to avoid calling it on huge assemblies.
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: operation, return format, and the empty-result interpretation. Front-loaded with the core action and free of 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?
With no output schema, the description usefully specifies the return structure and ordering, so the result contract is covered. Remaining gaps are the meaning/format of the 'assembly' argument and any indication of computational cost or scale limits, which matter for a pairwise comparison 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?
The single required parameter 'assembly' has 0% schema description coverage and is never mentioned in the description. It is ambiguous whether it expects an assembly name, id, or handle, and the description does not compensate for that gap.
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?
Specific verb+resource ('compute volume of intersection between every pair of parts') with explicit scope ('pairwise') that separates it from near-neighbors like min_clearance, envelope_check, and component_contract_check. An agent can tell immediately that this is a clash/interference detection routine rather than a general measurement or contract check.
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 use case (detecting overlapping parts) but never states when to prefer it over siblings such as min_clearance (gap checking) or envelope_check (bounding checks), nor does it mention prerequisites like requiring an assembly with multiple parts. Usage is inferable but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.