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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered; the description adds genuinely new behavior: the billing model (free for snapshots a buyer/deep report included, charged only for ones actually fetched) and an auth requirement (a free SnoopScan key). It also previews the returned content. Only the exact charged-credits mechanics are left unstated.

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?

Purpose is front-loaded, which is good, but the prose is wordy and the line breaks/phrasing ('A buyer report answers at once with the Internet Archive's timeline and the snapshots already held') are convoluted for what is a simple dependency explanation. Billing and auth details are useful but could be tightened.

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?

An output schema exists, so return values needn't be explained, yet the description still previews them helpfully. Auth and cost behavior are covered and the report dependency is clear; the only real hole is the unexplained 'snapshots' parameter against 0% schema coverage.

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 carry all parameter meaning. It loosely covers 'url' ('the same domain') and 'years' ('optionally the pending years'), but never mentions the 'snapshots' integer parameter (default 6), leaving one of three parameters completely undocumented in both schema and description.

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+resource: reading archived homepage snapshots left pending by a buyer domainReport. It explicitly positions itself relative to the sibling domainReport (which returns the timeline and held snapshots 'at once'), so an agent can tell them apart without opening either 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 the exact triggering condition ('snapshots a buyer domainReport left pending') and how to call it ('same domain, and optionally the pending years'). The alternative path (use domainReport for the immediate timeline/held snapshots, this for the rest) is named, leaving little to inference.

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