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

The description goes well beyond the annotations, disclosing the 203 dpi assumption, the core command subset limitation, the lack of physical printer validation, and the meaning of `labels` and `index` in a multi-label stream. This gives the agent important behavioral context that readOnlyHint and idempotentHint do not cover.

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 three sentences with no filler. It opens with the action and output, then packs important assumptions and response semantics into the remaining sentences. Every sentence earns its place and the most decision-relevant details are front-loaded.

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?

Despite having no output schema, the description covers the key return semantics (`PNG preview` and `labels`), the rendering limitations, and the index behavior. For an agent deciding whether and how to invoke this tool, the essential context is present, especially when combined with the parameter descriptions in the schema.

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 schema already documents both parameters at 100% coverage. The description adds useful semantics for `index` by explaining that streams may contain multiple labels ending in `P`, that `labels` is the total count, and that `index` selects which label to render. This enriches the schema's minimal 'Label index in the stream' description.

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 uses a specific verb ('Render') and resource ('EPL/EPL2 label code') and states the exact output ('PNG preview'). It also differentiates itself from validation tools by noting it is an interpretation with no physical printer validation, making its scope clear alongside siblings like epl_validate and zpl_preview.

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 implies when to use it: when you need a PNG preview of EPL code. It also states what it is not for ('no physical printer validation'), which is an implicit exclusion, but it never explicitly names an alternative tool such as epl_validate or explains when to choose it over other preview tools.

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