Removes an equation from a SolidWorks model by name or index, then rebuilds and reports deleted items, failing features, and mass properties.
Delete an equation by the name it sets ("L_thigh", "D1@Boss") or its list_equations index.
Rebuilds and returns what was deleted, failing_features and mass properties.
| Name | Required | Description | Default |
|---|---|---|---|
| equation | Yes |
Changes observed during successful MCP inspections.
v0.13.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present the description carries the full burden, and it does disclose the key side effect: the model is rebuilt as part of the deletion. It also names the return payload (deleted item, failing_features, mass properties). It stops short of saying whether deletion is irreversible or what happens when the equation name/index is not found.
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 short sentences, front-loaded with the identifier formats an agent needs before anything else. Minor awkwardness in the phrase 'the name it sets' and a slightly clipped second sentence, but nothing wasted.
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 no-annotation, no-output-schema mutation tool, the description covers the essentials: input formats, the rebuild side effect, and the return contents. Remaining gaps are failure/error behavior and reversibility, which are secondary for correct invocation.
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 0% and the single 'equation' property has no description, so the description must compensate — and it largely does, explaining the accepted name syntax with two concrete examples and the alternative list_equations index. It lacks detail on index base (0- or 1-based) or quoting rules.
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 (delete an equation) and immediately defines the two accepted identifier forms — the name the equation sets, e.g. "L_thigh" or "D1@Boss", or its list_equations index. This separates it cleanly from set_equation/set_equations/list_equations without the agent needing to open any 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?
The description implicitly tells the agent how to supply the argument (name or list_equations index), which is genuine usage help. It does not, however, state when to prefer this over alternatives such as set_equation (modify) or delete_feature, nor any preconditions. Adequate but with clear gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.