cpu_fulfill_reveal

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

With no annotations provided, the description fully discloses behavioral traits: it costs gas but no new reveal fee, it processes all open requests by default, settled requests are reported as success not errors, and it refuses on networks where manual settlement is unnecessary. This goes far beyond basic safety and covers edge cases and error semantics.

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 a single dense paragraph where every sentence and clause carries distinct value: core purpose, prerequisite, mode dependency, parameter behavior, and error handling. Despite its length, there is no fluff or redundancy; it is efficiently packed and front-loaded with the main action. It could be split into sections for readability, but its compactness earns top marks.

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 tool has a complex interaction with network randomness modes and multiple argument paths, and no output schema. The description fully compensates by explaining prerequisites, alternative argument strategies, the distinction between settled and non-settled requests, and the refusal condition. It leaves little ambiguity about when and how to invoke the tool, making it highly complete for its complexity.

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 provides 100% coverage with descriptions for all three parameters, including tokensIds' behavior and requestId's bypass mechanism. The description adds context about the overall flow but doesn't meaningfully enrich parameter meaning beyond what the schema states, so the baseline 3 applies.

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 opens with a specific verb and resource: 'Finish reveal requests you already opened that have not delivered their draw yet.' It clearly distinguishes this tool from siblings like cpu_reveal by focusing on completing an already-opened request, and references cpu_get_game_config and cpu_authenticate to frame its unique role in the reveal flow.

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?

Explicit guidance is provided: 'call cpu_authenticate first' establishes a prerequisite, and the description explains when to use it based on the network's randomness mode, even stating when it refuses ('On a network where the randomness source delivers draws itself this call refuses'). The argument variations (no args, tokenIds, requestId+source) are clearly tied to use cases, though no explicit alternative tool is named, the context is unambiguous.

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