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

Annotations are all false hints, so the description carries the burden of behavioral disclosure. It adds valuable behavioral context by stating the cost per query (0.01 USDC), the session quota (max 20 queries/session), and that this is a paid per-query operation. It does not detail side effects, idempotency, or what happens on failed payment, but the cost/quota disclosure is meaningful.

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: two sentences cover pricing, quota, the free alternative, and the required sequence. It is reasonably front-loaded, though the opening emphasizes the purchase/commercial aspect rather than the core action of querying.

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?

Given five parameters, no output schema, and weak annotations, the description is incomplete. It provides the lifecycle and pricing context but does not explain the delivery_receipt and sandbox_receipt mechanism, the meaning of k, or what the agent should expect as a result. An agent could sequence the tool correctly but would still lack details needed for a well-formed invocation.

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%, and the tool description does not compensate for the missing parameter documentation. It never explains k, delivery_receipt, or the query format, and while session_id and sandbox_receipt have schema descriptions, the main description adds no parameter-level meaning. This leaves important invocation details unclear.

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 communicates the paid per-query nature and clearly places this tool as the final step in the data_session_open → data_session_fund → data_session_query sequence, so an agent can infer it runs the actual query. However, the lead phrase 'Buy per-query access to live data listings' describes purchasing access rather than explicitly saying 'run a query against a funded session', which introduces slight ambiguity.

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 description explicitly names data_preview as the free alternative and gives the required lifecycle sequence data_session_open → data_session_fund → data_session_query. This tells an agent when to use this tool versus the free-preview sibling and what prerequisites must be satisfied first.

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