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

Annotations already cover read-only, idempotent, non-destructive behaviors, so the description doesn't need to. It does add a maxQueriesPerSession limit (20) and a no-API-key requirement, but it's buried in marketing text. It fails to mention that the preview returns only public metadata, which is a key behavioral trait that the schema mentions but the description ignores.

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 overloaded with marketing language, emojis, pricing, sample questions, and 'call now' CTA. It does not front-load the tool's core purpose; the most important functional information ('Listing: google preview') is buried in the middle. Every sentence is not earning its place; it's promotional copy, not a tool definition.

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 tool that provides a 'preview', the description never explains what the preview will return (it relies on the schema description). There is no output schema, so the description should explain the nature of the response. It also misses the fact that it's a guest-callable, public-metadata-only, which is exactly what an agent needs to know before using it. The presence of sample questions helps, but it's not enough.

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 coverage is 100%, so the baseline is 3. The description provides sample questions ('What did Google announce this week?') which are actually useful examples for the 'question' parameter, but it does not explain the 'slug' default behavior or the optional nature of both parameters. It adds a bit of meaning, but not enough to warrant a 4.

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 is promotional fluff ('No API key needed — call this now', 'FREE preview') rather than a clear statement of what the tool does. It never explicitly says 'preview this data listing' and instead dumps sample questions and pricing; the schema description ('Free, guest-callable taste of a listing') is clearer than the actual description.

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?

There's no explicit when-to-use, when-not-to-use, or any mention of alternatives like data_session_query or data_session_open. The phrase 'call this now' is a marketing imperative, not a usage condition. The only hint is 'no key, no payment', but it doesn't tell an agent under which situations to pick this tool over a paid session.

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