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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered and the description's 'read' framing adds nothing new. The one piece of behavioral context it contributes is the caller restriction to the speaking recorder card; it does not describe what a pending/low-scoring response looks like or any failure behavior.

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 with the core purpose front-loaded and no filler. The phrase 'speaking recorder card' is a bit internal/cryptic but costs only a few words.

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 need not be explained, and annotations cover the safety profile. Still, for a two-required-parameter read tool, the description leaves parameter meaning and the polling/status lifecycle unexplained, which are the remaining gaps an agent would hit.

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 0% for two required parameters (attemptId and deviceToken), both bare UUID patterns with no prose. The description does not explain what an attemptId refers to, where it comes from, or what deviceToken authorizes, so the agent gets no help beyond the schema's type constraints.

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 gives a specific verb and resource: 'Read the scoring status and scores for a recording.' That is clearly distinct from siblings like recorder_start, recorder_confirm, and score_writing, which cover starting, confirming, and writing scores. It does not explicitly name an alternative, but the resource 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?

The clause 'Called by the speaking recorder card only' restricts the caller context, which is useful routing information the schema does not carry. However, it says nothing about prerequisites (e.g., that a recorder_start/recorder_confirm must have happened first) or what to do if scoring is still pending.

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