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

Annotations only say readOnlyHint=false, openWorldHint=false, destructiveHint=falsehol. The description adds the essential behavioral traits: the call is paid and billed even when there is no drift, the comparison is from 'OUR vantage point', the x402 payment flow and receipt location in _meta, and the fact that no account or API key is needed. This far exceeds what annotations alone would tell an agent.

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 front-loaded with the core purpose and billing model, which is good mud, but it includes extra support-channel boilerplate about posting to /feedback and stating that every report is read daily. While informative, those sentences are not needed for selecting or invoking the tool and make the description longer than necessary. A tighter ending would earn a higher score.

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 must explain what the tool returns; it does so by describing the diff outcome and noting that 'no drift is still an answer'. It also covers prerequisites, the two-step x402 payment sequence, the receipt location, and authentication-free access, leaving no major gap for an agent trying to call this 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?

The schema already provides 100% coverage for the single 'venue' parameter, including the fact that a never-snapshotted venue returns a free 404. The description reinforces this by saying the venue must have been snapshotted before)SkipEvent and references drift_venues, but it does not add new parameter-level syntax or constraints beyond what the schema already gives. Baseline 3 is appropriate.

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 states a specific verb and resource: 're-fetch a venue' and 'return what changed since the baseline'. It further distinguishes the diff kind ('schema/rubric fields that moved, were added and were removed, not a byte diff') and names sibling tools drift_venues and drift_baseline so an agent can separate them.

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?

It explicitly says to pair the tool with drift_venues and drift_baseline, and lays out the payment workflow: call once without payment to get the x402 price, then call again with a signed payment in _meta['x402/payment']. This gives concrete when-to-use and how-to-invoke guidance beyond a generic alternative list.

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