Bake a modifier's effect directly into the mesh to make it permanent, simplifying the scene and reducing computational load during rendering.
Bake a modifier's result into the mesh, making it permanent.
| Name | Required | Description | Default |
|---|---|---|---|
| object | Yes | ||
| modifier | No | Modifier name, or 'all' to apply repeatedly. | |
| response_format | No | 'markdown' for readable output, 'json' for raw structured data. | json |
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context by noting the result is 'permanent,' which goes beyond the annotations' bare mutation flags. However, it does not disclose that the modifier itself is removed, that undo may be needed for recovery, or what happens if the object has no matching modifier. No direct contradiction with annotations is present.
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?
A single sentence with no filler: 'Bake a modifier's result into the mesh, making it permanent.' It front-loads the action and immediately conveys the key consequence.
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 mutation tool with no output schema and a required object parameter, the description is too thin. It omits how to identify the object, how modifier selection interacts with the stack, and what errors or results the agent should expect. The agent must already understand Blender's apply-modifier semantics to call this 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 already documents the 'modifier' and 'response_format' parameters, but the required 'object' parameter is undocumented in both the schema and the description. The description does not clarify what object identifier should be provided or how the default modifier value behaves beyond what the schema states.
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 'Bake' and 'making it permanent' to clearly identify the operation as applying a modifier's result to the mesh. It states the verb, resource, and outcome, though it does not explicitly distinguish itself from sibling tools like blender_add_modifier or blender_apply_transform.
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?
No guidance is given about when to apply a modifier versus using alternatives such as blender_run_operator or blender_apply_transform. The description implies finalizing a modifier, but it does not state when this tool should be preferred or what prerequisites apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.