drawing

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

With readOnlyHint=false, the tool is already marked as potentially mutating, and the description adds meaningful behavioral details: save mentions QSAVE fallback, undo/redo state operations, and purge targets unused objects. It does not disclose destructive side effects (e.g., purge deleting data permanently), but the per-operation explanations go well beyond the bare annotation.

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 tightly formatted bullet list with no filler. Each line adds one distinct operation plus a brief explanation and data hint, and the overall purpose is front-loaded in the first line.

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 ten-operation dispatcher, the description covers each operation's function and relevant data requirements, and an output schema exists to cover return values. The main gap is the unexplained `include_screenshot` parameter, which prevents the description from being fully complete.

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 is the only documentation of valid `operation` values and `data` structures. It lists all operations and gives per-operation data hints such as `data: {path}` for open and `data: {names: [...]}` for get_variables. However, the `include_screenshot` parameter is never mentioned, leaving one parameter undocumented.

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 "Drawing file management" and then enumerates ten distinct operations, each with a verb and a resource (e.g., "create — Create a new empty drawing," "plot_pdf — Plot to PDF"). This makes the dispatcher's purpose and each subcommand unambiguous. Although sibling tools are not referenced, the operations are clearly scoped to whole-drawing management, distinguishing it from entity/layer/block 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?

The operation list implicitly tells an agent when to use this tool (e.g., when saving or opening a drawing), but there are no explicit when-not-to-use statements or pointers to siblings like entity, layer, or block. Usage context is conveyed indirectly through the operation names, not through explicit routing guidance.

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