Border Outline

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

Annotations declare the safety profile (not readOnly, not destructive, openWorld), but the description adds meaningful behavior beyond them: outputs are written to disk and their paths returned, and "No settings" signals there is no artistic configuration. It stops short of describing auth or credit-charging details.

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?

Front-loaded with the action, then use cases, then a quality caveat and output behavior, in a compact run of sentences. Every sentence earns its place, though it is a dense colon-chained sentence rather than maximally crisp.

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?

With no output schema, the description usefully explains that results are saved to disk and paths returned, and it covers input suitability. For a 7-parameter tool, the reliance on 100%-covered schema for parameter detail is reasonable, leaving only minor gaps in return-value specifics.

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 100%, so the schema already documents all seven parameters in detail. The description adds only the "No settings" summary, which is helpful context but not syntax or format detail beyond the schema. Baseline 3 applies.

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?

States a specific verb and resource (trace the outline of the design) and names concrete use cases (screen printing, tech packs). It is clear enough to distinguish from most siblings like td_vectorizer or td_embroidery_effect, though it never explicitly contrasts them.

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 "Best for" clause gives clear conditions for use (outline-only version of a filled design, avoiding manual tracing) plus an input constraint (high-contrast, well-defined art). It does not name an alternative tool or when-not-to-use, so it falls short of 5.

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