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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so safety is covered; the description adds genuinely new behavioral facts: prepaid metering at 0.01 USDC per query and a hard cap of 20 queries per session. It does not explain failure modes, refund behavior, or what the delivery_receipt/sandbox_receipt params do, which keeps it below 5.

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 short, front-loaded sentences with the price and sequence readily scannable. Mild marketing phrasing ('first taste free', 'Buy per-query access') and a hardcoded listing name are slightly expendable but the core facts earn their place.

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 billable prepay-style call with 5 params, no output schema, and 40% schema coverage, the description covers cost and caps but leaves return shape and two parameters undefined. Adequate to invoke correctly in the happy path, but not complete enough for edge cases.

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 only 40%, and the description says nothing about any parameter. The top-k parameter 'k' and 'delivery_receipt' are undocumented in both schema and description, so an agent must guess their meaning and valid usage.

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 concrete action (run a paid per-query query against a live data listing) and names the specific listing and price, which is far beyond a tautology. It distinguishes itself from data_preview (free sample) and from the session setup tools, though the framing is purchase-oriented rather than describing what the query returns.

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 explicit prerequisite chain 'data_session_open → data_session_fund → data_session_query' and names the cheaper alternative (data_preview) for a free sample. Missing an explicit statement of when a call would fail or should not be made (e.g., unfunded session, cap exhausted), so not quite a 5.

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