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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description's one genuine contribution is that the call returns immediately rather than blocking on the conversion, which matters for an async kickoff tool. It stops short of saying where the result goes, whether repeated calls with "again" re-run work, or what external access (openWorldHint) implies.

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?

Two short sentences, front-loaded with the caller constraint and the immediate-return behavior, with no filler. It is efficient, though its brevity comes at the cost of the missing parameter and routing detail scored elsewhere.

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 six-parameter tool with a nested image object, no output schema, and near-zero schema description coverage, this description is far too thin. An agent cannot tell what to supply, in what combination, or what happens after the immediate response, and there is no mention of how to fetch the finished conversion.

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 only 17%: just the preset enum is documented (and documented thoroughly in the schema itself). The description adds nothing about url, again, image, file_name, or input_key, so an agent gets no signal on which inputs are mutually exclusive or how the nested image object relates to url. This leaves most of a six-parameter, nested-object tool undocumented in prose.

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?

"It starts a conversion" largely restates the name and title without saying what is being converted (an image? a URL? a file?) or what a conversion produces. The clause "answers at once, so the card can show it" adds a behavioral fact but not resource specificity. With siblings like vectorize_image and get_conversion in the catalog, the description does nothing to distinguish this tool's purpose from theirs.

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?

"Only the VecSnap card calls this" is a caller restriction, not usage guidance, and it is ambiguous: it could be read as "do not call this yourself" or as context for why it behaves oddly. No when-to-use conditions, no prerequisites, and no pointer to get_conversion for retrieving results or to vectorize_image as an alternative.

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