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

The annotations declare readOnlyHint=true and idempotentHint=true, while the description says 'Buy per-query access,' which strongly implies a financial or state-changing operation. The description does not clarify that this call only returns fund instructions and does not actually charge or execute a purchase. This is an annotation 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?

The description is compact and readable, front-loading the purpose and then giving listing details. It loses a point because the misleading 'Buy' framing and the marketing-style 'first taste free' clause consume space that could have clarified actual behavior.

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 payment-related tool with no output schema, the description is incomplete: it does not state whether invoking this tool costs money, what the returned fund instructions look like, or how they lead to data_session_fund or attach_escrow. An agent cannot build a safe mental model of the full purchase workflow.

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?

There is only one parameter, session_id, and its schema description already explains it is a UUID from data_session_open. The description reinforces the 'after data_session_open' prerequisite but adds no additional parameter-level detail, so the schema carries the weight and the baseline is 3.

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 resource (live data listings), a concrete listing and price, and the primary output ('Returns fund instructions after data_session_open'). It is clear enough to convey intent, but the opening verb 'Buy' blurs whether this tool executes a purchase or merely returns payment instructions, so it is not a 5.

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 provides some workflow context: use after data_session_open and try data_preview for a free taste. However, it never contrasts this with closely related siblings like data_session_fund or data_session_attach_escrow, leaving the agent to infer when to choose this tool over the alternatives.

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