Edit 3D model dimensions or replace source code, using revision check to reject stale changes and preserve previous version on failure.
Edit primitive dimensions or replace source using scad_code. Pass expected_revision from get_model/get_model_source to reject stale edits. Failed edits leave the previous revision intact.
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | Yes | ||
| scad_code | No | ||
| parameters | No | ||
| modifications | No | ||
| expected_revision | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses two non-obvious behaviors: stale edits are rejected via expected_revision, and failed edits leave the previous revision intact ('Failed edits leave the previous revision intact'). It does not mention permissions or success response shape, but the failure semantics are substantive.
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 with the primary action first, then the prerequisite, then the failure guarantee. Every sentence contributes a distinct operational fact, and 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?
The tool has five parameters, no annotations, and no output schema, so the description must carry significant weight. It covers the revision/concurrency contract well but omits how parameters and modifications should be used, when scad_code is needed versus optional, and what the success response looks like. Correct invocation remains partially underdetermined.
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 0%, so the description must compensate. It adds meaning to scad_code (source replacement) and expected_revision (concurrency guard), but leaves model_id, parameters, and modifications semantically unexplained. An agent cannot determine how to express 'primitive dimensions' or when to use parameters versus modifications.
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 an action verb and resource ('Edit primitive dimensions or replace source') and names two concrete use cases: changing dimensions or replacing source via scad_code. It clearly conveys that this tool modifies an existing model, which differentiates it from create/export/get siblings, though it does not explicitly name alternative 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?
It gives concrete usage guidance: fetch expected_revision from get_model/get_model_source and pass it to reject stale edits. This tells the agent where to get a required input and why. However, it does not explicitly state when to prefer this tool over create_model_from_scad or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.