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

With no annotations, the description carries the full burden, and it does thoroughly: newest-first ordering, snapshotted keyset pagination with an id ceiling, authenticated cursor binding, concurrency guarantees, and rejection of replay under changed filters. It also explains row identity (attempt_id) and content identity (url/manifest_hash), which is non-obvious behavior an agent must know. This is strong behavioral disclosure.

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?

The description is about 100 words, front-loaded with the core purpose, and each sentence addresses a distinct concern: scope, row identity, pagination semantics, concurrency, and filters. It is dense but not padded, and no sentence is wasted.

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 6-parameter optional-filter list endpoint with no output schema and no annotations, the description covers ordering, pagination safety, identity, and filter semantics. The schema supplies parameter constraints such as limit range and cursor formatting. It does not describe the response envelope, but an agent has enough detail to call the tool and iterate correctly.

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 the baseline is met. The description adds meaning beyond the schema by explaining that attempt_id is exact row identity and that url/manifest_hash may be shared by historical same-manifest rows. It also groups the filters in one sentence, reinforcing their roles. It does not duplicate limit details, which remain adequately covered by the schema.

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 opening phrase 'The public evidence corpus, newest first — every visible measurement' clearly identifies the resource and ordering. The phrase 'so it can be swept without walking each proposal' distinguishes this from an alternative workflow, though it does not explicitly name sibling tools like get_measurement. Scope 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 description indicates the tool is for sweeping all visible measurements without per-proposal iteration, which is a clear when-to-use signal. It also gives explicit pagination instructions ('Follow next_cursor verbatim') and cautions against replay under changed filters. It does not contrast with single-item retrieval via get_measurement, so some routing inference is left to the agent.

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