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

With no annotations, the description carries the full burden and does meaningful work: it discloses that the data is public, operator-ratified, and server-observed, and warns that 'counters are not independent proof.' It leaves unstated what happens when no grant or receipt exists for the day, and there is no rate-limit or error context.

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 dense sentences with no filler, front-loaded with what is read and what it is scoped to, followed by the provenance caveat. Slightly telegraphic in the second sentence but every clause carries information.

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 two-parameter read tool with no output schema and no annotations, the description covers what is returned (grant plus receipt), the provenance of each half, and the key trust caveat. It stops short of describing the response shape or empty-result behavior, which is the remaining gap.

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%, so the description must compensate. It adds the meaningful qualifier that 'day' is UTC, which the bare format:date schema does not convey, and ties both params to 'one agent and UTC day.' It does not explain the agentId format constraint or the semantics of a missing/invalid identifier.

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 ('Read') and a precise compound resource ('operator-ratified meter grant and server-observed vendor receipt') scoped to one agent and UTC day. It does not name sibling get_meter or run_meter_probe, so differentiation is only implied by the provenance qualifiers rather than stated.

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 line 'No vendor calls' implies this is the passive/historical read path as opposed to a live probe, but no alternative tool is named and no explicit when-to-use or when-not-to-use condition is given. Usage must be inferred from the provenance wording.

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