maya_execute

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

Without annotations, the description carries the full burden and discloses key runtime behaviors: which API namespaces are available (cmds, mel, om), return value conventions, stdout/error capture, and undo chunk semantics. It does not explicitly warn about the potential destructive side effects of arbitrary code execution, but the '임의의 Python 코드' statement makes the power and risk inherently clear.

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 well-structured with a lead sentence, usage guidance, a clear list of available names, and a concise return-contract section. Every sentence adds unique value—no filler or repetition of schema fields—and the content is front-loaded with the core purpose.

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 powerful code-execution tool with no annotations and no output schema, the description is remarkably complete. It explains how to invoke, what parameters mean, how return values and errors are delivered, and when to prefer this tool over dedicated ones. This gives an agent everything needed to use and recover from failures.

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 0%, so the description must compensate entirely. It thoroughly explains both parameters: 'code' is the Python code to execute, and 'undo_chunk' is described with its default behavior and user-facing undo impact (Ctrl+Z). It also adds valuable return-format semantics tied to the code input.

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 executes arbitrary Python code inside Maya ('Maya 안에서 임의의 Python 코드를 실행합니다') and positions it as the general-purpose gateway for operations lacking dedicated tools. This distinguishes it from specialized sibling tools like maya_scene_info or maya_unreal_export_fbx by explicitly naming unsupported task categories (rigging, UV, deformers, etc.).

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 explicitly says to use this tool for tasks without dedicated tools ('전용 툴이 없는 작업...은 전부 이 툴로 하세요'), implying use dedicated tools when available. It also provides batching guidance, stating that combining multiple tasks in one call is faster and cheaper than separate calls, and instructs the agent to read errors and retry on failure.

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