blender_execute_python

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description says 'Execute arbitrary Python inside Blender' and demonstrates code that creates an object via bmesh and bpy. Arbitrary Python can mutate state, so the description contradicts the annotations and presents a false safety model to the agent.

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?

The description front-loads the core purpose, then gives usage context, available names, and one instructive example. No sentence is filler; the example earns its place by showing a complete object-creation and result-return pattern.

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 complex arbitrary-code tool with no output schema, it covers return variants, imports, and the view3d context, which is good. However, it fails to counter the misleading read-only/non-destructive annotations by warning that executed Python may modify Blender scene state, leaving the operational picture incomplete and unsafe.

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?

With schema coverage at 67%, the description adds meaningful semantics mainly for the `code` parameter: available namespaces, the `Result(...)` pattern, and a full bmesh example. `capture_output` and `response_format` are already documented in the schema, so the added parameter guidance is solid but not exhaustive.

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 opens with a specific verb and resource: 'Execute arbitrary Python inside Blender' and a clear return contract ('stdout, the expression value, or the traceback'). It also labels itself 'the general escape hatch' for areas dedicated tools do not cover, which separates it from the many specialized sibling 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 explicitly states when to use: 'use it for anything the dedicated tools do not cover' and provides concrete use cases such as node graphs, drivers, custom rigging, numpy-style math, and bmesh work. This strongly implies the inverse—prefer dedicated tools when one applies—without needing further elaboration.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.