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

Beyond the annotations, the description discloses materially important behavior: it costs 0.05 USDC from the user's Circle Agent Wallet, opens an on-chain VRF request, has a five-minute free-repeat window, is subject to a daily spending cap, and returns request/fulfillment/proof links. This is far richer than the annotations alone.

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 dense but well-structured: the first sentence gives purpose and supported operations, and the following sentences add payment, repeat-behavior, and cap caveats without filler. Every sentence earns its 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 paid, multi-mode VRF tool with no output schema, the description covers purpose, operation variants, payment source, cost, repeat behavior, seed semantics, failure mode due to spending cap, and returned proof links. An agent has enough context to invoke it correctly and know what to expect.

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?

The schema already documents every parameter with 100% coverage, so the baseline is 3. The description adds a small but useful extra semantic layer—the seed is bound to the payment on chain, and one call returns every value of its operation—though most parameter meaning correctly lives in the 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 specifies a clear action—'Draw verifiable randomness'—and enumerates the concrete operation families (dice, coin flip, range, one/several winners, shuffle). It also states that the tool opens a VRF request and returns proof links, which clearly distinguishes it from the sibling get_result and setup_status 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 gives strong operational guidance: ask once and never repeat a call to re-roll, identical calls within five minutes return the earlier draw without paying, and separate draws need separate seeds. It references setup_status for the spending cap, though it could be more explicit about when to prefer get_result for fetching past results.

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

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

Annotations already mark it read-only, idempotent, and non-destructive; the description adds beyond that by warning that chosen items are returned as indices, not labels, and must be applied to the original list. This is useful behavioral context. No contradiction with annotations.

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 compact, purposeful sentences: purpose, when-to-use, and response interpretation. No filler; each sentence earns its place and the main action is front-loaded.

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?

Covers the core read workflow, return format, and the pending/unanswered use case, and annotations cover safety. It stops short of a 5 because it doesn't explicitly state that paymentId and requestId are mutually exclusive or what happens if neither is provided, which is relevant given both params are optional in the schema.

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 100%, so the schema already documents paymentId and requestId. The description adds the 'or' relationship and maps each ID to its resource type, but doesn't add format or additional semantics beyond the schema, so a 3 is appropriate.

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 specific action ('Read') with the exact resources ('paid draw by paymentId' or 'request by requestId') and the workaround ('for free'). It also clarifies the outcome ('finish a draw that came back pending or unanswered'), making it easy to differentiate from a sibling like draw that creates/executes draws.

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 a clear trigger for using the tool: when a draw came back pending or unanswered. It doesn't explicitly name excluded alternatives or contrast with draw/setup_status, so it earns a 4 rather than a 5.

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

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

Annotations already declare the tool read-only, idempotent, open-world, and non-destructive. The description adds meaningful behavior context by naming the exact checks performed (Circle CLI, login, agent wallet, Gateway balance, today's spending) and the return value ('the next setup step'). It does not contradict the annotations.

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 two compact sentences with no filler. It front-loads the action, lists the checked areas, and ends with the return value. Every sentence earns its 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 parameterless, read-only status tool with strong annotations, the description is complete enough: it names what is checked, what the result means, and what is returned. The lack of an output schema is mitigated by the explicit 'Returns the next setup step' statement.

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?

The tool has zero parameters, so parameter semantics are trivially satisfied and the input schema is complete. The description still contributes by clarifying what the caller receives in return, which is useful given the absence of an output 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 states a specific action ('Check whether draws can be paid') and a clear resource ('payment setup'), then enumerates the concrete components it inspects. It is easily distinguishable from siblings draw and get_result, which clearly perform execution and result retrieval rather than setup validation.

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 implies the tool should be used to verify payment readiness before draws, but it does not explicitly state when to use it versus alternatives or mention any exclusions. No sibling comparison is provided, so the agent must infer the proper usage context.

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