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

With all annotations false (no read-only, idempotency, or safety hints), the description carries the disclosure burden. It adds genuinely useful behavioral context: the 0.01 USDC per-query cost and the 20-queries/session cap, which signal that this is a fund-consuming, non-idempotent operation. However, it omits failure/refund behavior and the receipt-signing mechanics tied to sandbox_receipt and delivery_receipt, which matter for a paid call.

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 tight sentences with no filler: the core idea is front-loaded, the listing specifics (ghmcp, price, cap) occupy one sentence, and the workflow sequence another. The only structural weakness is that the 'Buy' framing in sentence one is slightly misleading, so the opening is not as accurate as it could be.

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 paid, non-idempotent tool in a three-step flow with five parameters and no output schema, the description covers the workflow position and cost economics well. But it leaves significant gaps: the meaning of k, the delivery_receipt flow, and any sense of what the query returns or what happens on failure. It is adequate for navigating the sequence but incomplete for invoking the tool correctly with all parameters.

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 only 40%, below the 50% threshold, so the description must compensate for the undocumented k, query, and delivery_receipt parameters — it does not. The description is entirely about workflow, pricing, and the listing; it adds nothing about what any of the five parameters mean, leaving the agent dependent on a sparse schema.

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 positions the tool via the sequence 'data_session_open → data_session_fund → data_session_query' and references the data_preview sibling, so an agent can roughly place it. However, the opening verb 'Buy per-query access' mischaracterizes the operation — the schema's own description says 'Run a prepaid query against a funded data session,' and purchasing is actually data_session_fund's role. The core action (running a query against a session) is implied by the sequence and name but never stated plainly.

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?

The explicit three-step sequence tells the agent that this is the final step, to be used only after data_session_open and data_session_fund. The phrase 'first taste free via data_preview' additionally routes the agent to the free alternative before paying. It lacks an explicit 'do not call before funding' exclusion, but the ordered workflow makes that condition strongly inferable.

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