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

Annotations are all false/neutral, so the description carries the behavioral burden. It discloses pricing (0.01 USDC per query), session limits (max 20 queries), and the required funding sequence. However, it does not disclose what happens on insufficient balance, failed queries, or whether queries consume funds even on failure, which is important for a paid operation.

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 front-loads the most essential idea: this tool sells per-query access. The listing details are concise and the sequence is given in one short line. It is slightly promotional with 'first taste free,' but every sentence contributes useful operational context.

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?

The description provides the critical billing and sequencing context needed before calling the tool, which is good given the tool is paid and has prerequisites. However, it does not explain the return value or result format, and the purpose of the delivery receipt parameters is left unclear in the main description. No output schema exists, so the description should do more to explain what the agent will receive.

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 two parameters lack descriptions in either schema or tool description: 'query' and 'k'. The description mentions per-query pricing and max queries per session but does not clarify the semantics of these parameters or how they relate to the delivery_receipt and sandbox_receipt fields. The description does not compensate for the low schema coverage.

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 schema description explicitly says 'Run a prepaid query against a funded data session,' which clearly identifies the tool's action and resource. The tool description adds billing context but its phrasing 'Buy per-query access to live data listings' is more promotional than precise. Combined with the title 'Query Data Session,' the purpose is clear and distinguishable from sibling session-management tools.

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 the prerequisite sequence 'data_session_open → data_session_fund → data_session_query,' so an agent knows exactly when this tool should be called relative to its siblings. It also routes free first use to data_preview, giving an explicit alternative. This is strong usage guidance.

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