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

Annotations already mark readOnlyHint=false and destructiveHint=false. The description adds the commercial context: prepaid, metered, max 20 queries/session, and the specific cost per query. It does not mention billing failure or refund behavior, but the disclosed limits and cost model are useful beyond the annotations. No contradiction.

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?

Three crisp sentences: what it does, what it costs, and the order to call it. Every sentence earns its place, and the most important differentiator (paid vs free preview) is front-loaded.

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 two-required-parameter tool with no output schema, the description covers the main workflow, cost, and limits. The gaps — what k does, what delivery_receipt means, and expected return payload — are partially in the schema but not fully explained. Slightly more detail would make it complete.

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 low at 40% — only session_id and sandbox_receipt have inline descriptions; k, query, and delivery_receipt have none. The description does not explain k, delivery_receipt, or sandbox_receipt semantics. However, the description names the sequence and prepaid nature, which implies session_id and query roles. This only partially compensates for the low coverage, so a 3 is fair.

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 clearly states the tool sells per-query access to live data listings, names the specific listing and price, and gives the exact sequence (data_session_open → data_session_fund → data_session_query) that distinguishes it from siblings. The verb 'query' plus the resource 'funded data session' is specific and immediately differentiates it from data_preview or data_session_fund.

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 names data_preview as the free first taste, implies it is for paid queries after funding, and provides the sequence of operations. This is exactly the kind of when-to-use vs alternatives guidance an agent needs, especially in a 15-tool environment with multiple session-related siblings.

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