Registers the open saved .blend as a read-only master by recording its SHA256 without modifying the file. Requires confirm_master=true to verify and lock the asset version.
Register the open saved .blend as a read-only MASTER (records SHA256). Requires confirm_master=true. Never modifies the file.
| Name | Required | Description | Default |
|---|---|---|---|
| operation_id | No | ||
| confirm_master | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.9.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond the annotations: it records a SHA256, imposes a confirmation gate, and explicitly scopes the non-mutation claim to the file ("Never modifies the file"). That last point usefully reconciles with readOnlyHint=false, since the write is a registry record, not a file edit. It does not say whether repeat registrations create duplicate master records, which matters given idempotentHint=false.
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, front-loaded with the action and artifact type, followed by the precondition and the safety guarantee. No filler and no redundant restatement of the 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?
The presence of an output schema means return values needn't be described, and the core action is covered. Gaps remain around the undocumented operation_id, the required file state, and how this differs from the adjacent fixture/working-copy registration tools.
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%, so the description must carry the load. It explains the semantics of confirm_master (a required safety gate set to true) but says nothing about operation_id, leaving one of two parameters undocumented in both schema and description.
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 (Register) and resource (the open saved .blend) plus the resulting artifact type (MASTER) and side effect (records SHA256). This implicitly separates it from siblings like asset_register_fixture and asset_create_working_copy, but it never names those alternatives, so the differentiation is left to inference.
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?
"Requires confirm_master=true" gives one concrete precondition, which is genuinely useful. However, there is no guidance on when to choose this over asset_register_fixture or asset_create_working_copy, no statement about what state the file must already be in (saved, unsaved changes), and no when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.