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

Annotations already cover read-only, idempotent, closed-world semantics, so the description earns credit for the extra disclosure that the active claim receipt and role tokens are never returned — a real security-relevant behavior not present in the schema. It does not describe behavior on unknown job_id or invalid read_token, which keeps it below a 5.

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 sentences, front-loaded with the action and resource, second sentence dedicated to the exclusion set. No filler and nothing buried.

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?

An output schema exists, so return values needn't be itemized, and the description adds the key exclusion about claim receipts and role tokens. Missing only error/empty behavior for a stale job_id or read_token, which an agent calling this repeatedly would want.

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 100% and each parameter carries a description naming its source tool and format pattern, so the schema does the heavy lifting. The phrase 'using the read token' merely restates what the schema already documents.

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 (read one job) plus what is returned (JSON payload and status), and the qualifier 'one known job' implicitly separates it from the queue-listing sibling read_agent_queue. It stops short of naming that sibling explicitly, so an agent must infer the boundary.

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?

'Read one known job' implies you must already hold a job_id, which is the main precondition, but the description never states when to use this versus read_agent_queue, claim_agent_queue_job, or ack/release variants. Usage is implied rather than guided.

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