rna-call_operator

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

With no annotations, the description carries full responsibility for behavioral disclosure. It adds one detail: 'args validated against its RNA', which hints at argument checking. But it does not disclose that running bpy.ops operators can mutate scene state, may fail due to context/poll requirements, or what happens on error. This is a significant transparency gap for a tool that executes arbitrary operators.

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 is a single sentence that is front-loaded and contains no filler. It efficiently conveys the core purpose and the key value-add (RNA validation). Every word earns its place.

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?

This is a complex generic tool with no output schema and no annotations. The description is far too minimal to be complete: it doesn't explain return values, error handling, how selection/object/mode affect execution, or how the JSON arguments should be structured. Given the breadth of bpy.ops, significantly more detail is needed for reliable invocation.

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 input schema has 0% description coverage, so the description must compensate. It only mentions 'args' and validation, but does not explain the JSON format for args, the purpose of mode/object/select, or how idname maps to an operator. The schema titles provide some examples, but the description adds little beyond what the schema already shows.

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 clearly states the tool's function: 'Run any bpy.ops operator'. The verb 'Run' and resource 'bpy.ops operator' are specific, and the phrase 'any' differentiates it from dedicated sibling tools like mesh-bevel or object-shade_smooth. However, it doesn't explicitly distinguish itself from similar generic tools like ui-operator_invoke.

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?

There is no guidance on when to use this generic operator runner instead of a dedicated operator tool or ui-operator_invoke. The description implies it can handle any operator, but doesn't state that it should be used as a fallback or for unsupported operators. No exclusions, alternatives, or context are provided.

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