system

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

The description directly contradicts the readOnlyHint=true annotation: init re-initializes the backend, execute_lisp runs arbitrary AutoLISP code, and batch executes multiple drawing commands. These are not read-only behaviors, making the safety metadata unreliable. It adds useful context like 'File IPC only' and the UNDO grouping, but the contradiction is severe.

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 bullet-list format is well structured and front-loaded with a clear header. The batch example is long but justified by its complexity. There is mild redundancy among status, health, and get_backend, but overall each line 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?

All operation names and the two data-carrying operations are covered, and an output schema exists so return values need not be explained. However, it omits include_screenshot semantics, side-effect warnings for execute_lisp/init, and an explanation of 'File IPC only'. The readOnly annotation contradiction also undermines the overall completeness.

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. It explains the operation string values and gives concrete data shapes for execute_lisp and batch, including a full example. It does not describe include_screenshot or data for the simpler operations, but those are less critical.

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 defines a server/system command dispatcher with seven explicit operations, each with a specific purpose. It distinguishes itself from drawing/entity/layer siblings by framing the scope as 'Server status and management.'

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?

Each operation states its use case (health check, backend info, runtime diagnostics, etc.), and batch explicitly says to use it for bulk drawing instead of one call per entity. It does not explicitly name alternatives for every operation, but the usage context is clear.

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