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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: newest-first ordering, a hard 403 failure mode for unclaimed sandbox workspaces, and an explicit credential requirement. Those are exactly the operational facts an agent needs before calling and could not learn from the annotations.

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?

One dense paragraph, front-loaded with purpose and returned fields before prerequisites. A few phrases are wordy ('the price given and the inputs it was given for'), but no sentence is filler.

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?

There is no output schema, so the description's enumeration of returned fields carries real weight, and it covers ordering, auth, and the workspace-claim prerequisite. Coverage is solid for a 6-parameter read-only list; only the relationship to sibling listing tools is left implicit.

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 100%, so limit, offset, date bounds, function_id, and the buyer_agent enum are already fully documented. The description echoes the buyer_agent=verified semantics without adding syntax or defaults beyond the schema, so the schema does the heavy lifting and 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 and resource ('List your workspace's priced calls, newest first') and enumerates exactly what each record contains (id, function, cost, price, inputs, sender). This is far more than a restatement of the name. It does not, however, contrast itself with nearby siblings such as list_costs, list_outcomes, or list_llm_usage_events, so the agent must infer which listing tool to pick.

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 description gives prerequisites (Last Price credential, a claimed workspace, 403 for sandbox keys) and hints at the downstream use of the returned id by report_outcome, which implies the workflow. But it never says when to choose this over the other usage/cost listing tools, so selection guidance is only implied.

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