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

The annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add operational context — and it does supply some: no API key required, a 20-queries-per-session cap, and a stated price. However, the pricing sentence ('Price 0.01 USDC/query') directly undercuts the repeated 'FREE preview — no key, no payment' claim, leaving the agent unsure whether invoking this has a cost. It also never says what the preview actually returns.

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 text is padded marketing: an emoji checkmark, 'free'/'no key, no payment' asserted three times, and two example questions that function as ad copy rather than specification. The most decision-relevant fact for an agent — that this returns public listing metadata without auth — is neither front-loaded nor stated at all.

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?

With full schema coverage, rich annotations, and no output schema, a short statement of what a preview contains would suffice — and the schema description ('Free, guest-callable taste of a listing (public metadata only)') supplies most of it. The tool description instead spends its length on pricing and promotion, omitting return content and leaving the free-vs-paid question unresolved.

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% and the schema already explains both optional parameters, including that slug defaults to the routed session's listing and that question is echoed back. The description adds nothing about slug (its single hardcoded listing name arguably muddies it) and only gestures at question via 'sample questions'. Baseline 3 is appropriate when the schema does all the work.

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 never states the action cleanly; it leads with a sales pitch ('✅ No API key needed — call this now') and then presents content for one hardcoded listing ('statwatch: STAT News pharma & biotech industry press') as if that were the tool's purpose. An agent reading it cannot tell that this is a generic free preview of any listing's public metadata, nor how it differs from a real query tool. The verb/resource pair 'FREE preview' appears only near the end and is buried in repetition.

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?

'Call this now' and 'Try one of the sample questions now' are calls to action, not usage guidance. There is no statement of when to prefer this over siblings such as data_session_query or discover_agents, and no conditions or exclusions. The only implicit guidance is 'free, so use it before paying', which is never spelled out.

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