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

Annotations already declare readOnlyHint=true, idempotentHint=true, non-destructive, closed-world, so the safety profile is fully covered. The description adds genuinely useful domain context the annotations cannot: that the download link is short-lived and only present once the job succeeds, and that usage counters are scoped to the organisation. That is value beyond structured fields, but permissions, rate limits, and expiry specifics are still absent.

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?

A single dense sentence that front-loads the core purpose (the state of a render job) then layers the usage-accounting and result details. Efficient, though the nested parenthetical makes for a slightly heavy read rather than a crisp scannable structure.

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 an output schema present the description need not explain return shapes, and it instead flags the two conditional aspects an agent must handle: download link is short-lived and only appears on success, plus org-scoped usage accounting. Complete enough for a single-parameter read tool, though polling/eventual-consistency behaviour before success is unaddressed.

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?

Only one parameter (job_id) and schema coverage is 100%; the schema already documents that it is a job id from a create tool. The description adds the scoping notion that the job must have been created through this connection, but no 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 (get) and resource (the state of a render job created through this connection), and enumerates exactly what the returned state contains: usage accounting (meter, quantity admitted, committed) and result metadata plus download link on success. An agent can distinguish this from render.usage.get and render.batch.get at a glance.

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?

No explicit guidance on when to use this versus render.job.cancel, render.usage.get, or render.batch.get. The phrase 'created through this connection' implies a scope constraint but never states a when-to-use or when-not-to-use condition, leaving routing to inference.

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