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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real context beyond that: pages are bounded, the wallet is API-key-attributed, 'recorded spend/allocation is not a payment receipt,' and storeNetwork describes deployment rather than per-run settlement. It does not describe the row shape or what a page contains, and 'storeNetwork' refers to an output field that is never defined here.

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?

Dense but front-loaded: the read scope comes first, then the auth requirement, then behavior caveats, then exclusions. Every clause carries information; the only wobble is the abrupt mention of 'storeNetwork' and the staccato exclusion fragment, which read as shorthand rather than full sentences.

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 seven-parameter read tool with no output schema, the description covers the essential behavioral facts an agent needs: bounded pagination, auth scope, case-sensitive literal search, and the warning that recorded spend is not settlement. It does not indicate what a returned row contains, but the caveats and exclusions compensate for much of that 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 100%, so every parameter (from/to/limit/cursor/search/funding/surface) is already documented in the schema, including enum meanings and the cursor contract. The description restates only the literal, case-sensitive search behavior and adds nothing about filter interaction or date-bound semantics, so the 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 plus scope: 'Read bounded pages of the verified API-key wallet's ordinary current-store runs.' The closing exclusion list (no wallet selector, archive, private jobs, research or payment) separates it from history_owned_read, history_private_jobs_list, history_export and research siblings without opening any schema.

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?

Gives a clear scope condition (ordinary current-store runs), an explicit auth prerequisite ('Requires explicit history:read'), and explicit exclusions. It stops short of naming which sibling to use for the excluded cases (archive, private jobs, research, payment), leaving the agent to infer the redirect.

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