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

With no annotations, the description carries the full disclosure burden and does it well: it reveals the tool is asynchronous ('returns a task... call wait_for_task'), costs 4 credits, and produces real vector paths on a transparent background rather than an embedded bitmap. It does not cover failure modes, auth, or rate limits, but the most decision-relevant behaviors are disclosed.

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?

Four sentences, all load-bearing: purpose, output-format distinction, async flow, and the mascot parameter. The key scoping information is front-loaded before operational details, and there is no filler.

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 tool that is asynchronous, credit-priced, and integrated with a mascot system, the description covers the full call flow: trigger, poll via wait_for_task, and optional mascot reuse. It falls slightly short by not clarifying the relationship to download_svg/download_png siblings or typical failure behavior, but the essential contract is 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 coverage is 75%, below the 80% threshold, so the description must add some weight. It does: mascot_id is enriched with its semantic ('keep a consistent character across scenes') and its source (list_mascots), and the 'text prompt' phrase reinforces prompt. aspect_ratio gets no extra help, but its enum values are self-explanatory.

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: 'Generate professional, editable SVG artwork from a text prompt', and enumerates the artifact genres ('illustrations, icons, stickers and mascot scenes'). The 'not an embedded bitmap' clause plus the genre list implicitly separates it from generate_logo and vectorize_image, though no sibling is named explicitly.

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?

Gives clear operating context: it names wait_for_task for the async result flow and list_mascots as the source for mascot_id. However, it stops short of explicit when-not guidance — it never routes logo requests to generate_logo or raster-to-vector jobs to vectorize_image, so 4 rather than 5.

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