blender_batch

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

The annotations are all false and provide little behavioral signal, so the description carries the burden. It discloses key runtime behavior: results come back per step, one failure does not hide successful steps, and arbitrary addon commands are dispatched. This is genuinely useful beyond the schema, though it does not detail output shapes or side effects of individual commands.

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?

Every sentence earns its place: definition, step format, result semantics, use-case justification, and the critical command-naming caveat. The layout is scannable and front-loads the most important information first, with no filler or redundancy.

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?

Given no output schema and neutral annotations, the description gives an agent enough to invoke the tool sensibly: how to structure steps, what command namespace to use, and what to expect from failures. It could be more complete by listing the full set of accepted addon command names or the exact result envelope, but the examples and per-step behavior note are sufficient for a generic batch runner.

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 100%, so the baseline is 3. The description repeats and slightly clarifies the steps structure and the example command names, adding the useful note that command names are not the tool names. However, it does not materially expand on stop_on_error or response_format, which are already well documented in the schema.

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: 'Run many bridge commands in a single round trip.' It clearly distinguishes itself from the many single-command sibling tools by emphasizing batching, and it reinforces this with concrete command-name examples. There is no ambiguity about what the tool does.

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 gives clear context: use this when building a scene efficiently, because it collapses dozens of round trips into one. It also warns that command names are the addon's names, not the tool names, which prevents a likely misuse. It does not explicitly name individual alternatives or state when not to use it, so it stops short of a 5.

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