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

Annotations give the safety profile (write, non-destructive, non-idempotent, closed-world), and the description adds genuinely new behavior: it returns a durable job rather than a finished asset, Blender packages GLB/OBJ/STL/blend outputs, and idempotency-key replay adopts existing work. The 'stable idempotency key' framing sits slightly at odds with idempotentHint=false, but it reads as scoped idempotency rather than a contradiction.

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?

Three tight sentences, purpose front-loaded, each sentence adding a distinct fact (what it does, what to supply, how to follow up). No filler, though the follow-up sentence packs return-handling and polling together and could be split for scanning.

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 complex, async, multi-template creation tool with an output schema present, the description covers the job lifecycle, the output packaging, and the idempotency contract, so an agent can call it and handle the result. The remaining gap is the recipe itself and generatePreview, which is meaningful but not fatal since the schema enumerates them.

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 20%, so the description must carry the load, and it compensates for baseRevisionId ('explicit') and the idempotency key ('stable') and gestures at recipe bounds ('bounded template controls'). However it says nothing about the six templateId variants, the seed/color/detail fields, or the generatePreview default, leaving the largest parameter effectively unexplained beyond the raw schema.

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 states a specific verb and resource ('Author a procedural plant with ngPlant') and adds a scoping constraint ('in an empty ngplant project'), which implicitly distinguishes it from vegetation_edit. It does not name any sibling explicitly, so an agent must infer the create-vs-edit split, but the purpose itself is unambiguous.

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?

It supplies a real usage condition ('empty ngplant project') and a post-call workflow ('poll job_get/job_wait and use vegetation_inspect after commit'), which tells the agent how the tool fits between siblings. It stops short of naming when to prefer vegetation_edit or the alternatives, so no explicit exclusions are given.

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