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

The annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds only chain scoping ('Base wallet') and does not explain what a 'failed automatic prize payout' is, how a failure is determined, or what a positive result implies for recovery.

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?

A single front-loaded sentence with no filler or redundant restatement of the name. Its brevity is close to the limit of usefulness given the unexplained domain terminology.

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?

An output schema exists, so return values need not be described, and annotations cover safety. For a one-parameter read tool this is minimally adequate, but the agent is left unsure what constitutes an 'outstanding failed' payout or what action to take on a positive result.

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 0%, so the description must compensate for the single parameter. It only implies the address is a Base-chain wallet address, but gives no format expectation (0x hex, length) or validation behavior, leaving most parameter semantics undocumented.

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 verb ('Check whether') and a specific resource ('outstanding failed automatic prize payout') scoped to a Base wallet, which is clearly distinct from sibling tools like get_wallet_tickets or get_jackpot. It loses a point only because 'failed automatic prize payout' is a domain term left unexplained.

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 no when-to-use or when-not-to-use guidance and names no alternatives, even though siblings such as get_wallet_tickets and get_jackpot cover adjacent wallet/prize queries. The agent must infer that this tool is for troubleshooting a missing payout.

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 idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral claim that this is the sole completion gate, but says nothing about failure behavior, retry semantics, or that it hits the chain. Note the mild tension: the description reads like a read-only verification while readOnlyHint=false, though a state-marking confirmation step would explain the discrepancy.

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?

Two short sentences, front-loaded with the verification scope and no filler. It is efficient, though the terseness contributes to the missing parameter and failure-behavior detail.

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?

An output schema exists, so return values need not be spelled out, and annotations cover much of the safety profile. However, for a 4-parameter tool with 0% schema coverage, the unexplained agent_id/execution_id and absent failure semantics leave meaningful gaps.

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 0% and the description explains no parameters at all. 'sender' loosely maps to wallet_address and 'receipt' to tx_hash, but agent_id and execution_id are entirely undocumented, and no format guidance (e.g., tx hash format, chain) is given.

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 verb (verify) plus the exact artifacts checked: Base receipt, sender, contract, method, and TicketPurchased event. This clearly separates it from prepare_ticket_purchase, though the description never explicitly says it confirms a ticket purchase outcome, leaving that to the tool name.

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?

"This is the only completion check" implies it is the terminal step after prepare_ticket_purchase, but the sequencing is only implied. There is no explicit statement of prerequisites (e.g., must a purchase be prepared first) or of what to do when verification fails.

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 readOnly, idempotent, openWorld, non-destructive, so the safety profile needs no restating. The description's contribution is the 'authoritative' qualifier, signalling the values are canonical rather than stale, plus a content inventory; it does not disclose freshness, caching, or on-chain vs off-chain sourcing, which for an openWorld hint would be useful.

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?

A single front-loaded sentence: verb, authority claim, then a tight list of the returned content categories. Nothing is repeated from annotations or schema, and nothing extraneous is present.

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?

A zero-param, output-schema-backed tool with full annotation coverage needs little more than a statement of what it returns, which the description supplies. The one omission is any hint about when in the agent workflow to call it relative to the purchase/referral tools.

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?

Zero parameters, so the schema carries nothing an agent must interpret and there is no semantic gap to fill. Baseline 4 applies; the description correctly spends no words on nonexistent arguments.

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?

Specific verb ('Read') plus a concrete inventory of the resource's contents: game config, USDC pricing, gas, workflow, payout, and safety details. An agent knows this is the discovery/config tool rather than a data-fetch tool like get_stats or get_draw_history. It stops short of naming itself against any sibling explicitly.

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?

There is no explicit when-to-use statement, no prerequisites, and no named alternative. The word 'authoritative' and the enumerated contents imply this is the canonical first-call/config lookup (e.g., before prepare_ticket_purchase to learn price and gas), but the agent must infer that routing on its own.

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 establish that this is a safe, idempotent read-only operation. The description adds that only completed draws are returned and that the limit is one to ten, which is useful behavioral context, but it does not describe ordering, pagination, or what happens for an unknown draw ID.

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 front-loaded sentence with no wasted words. The scope constraint and draw_id behavior are both stated efficiently.

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 simple read tool with an output schema and safety annotations, the description is nearly complete: it covers scope, limit bounds, and draw_id behavior. It leaves minor gaps around ordering and invalid-ID behavior, but these are modest given the structured metadata.

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 0%, so the description must carry parameter meaning. It explains that limit reads one to ten draws and that draw_id selects a starting public draw ID, covering both parameters well, though it does not state the default behavior when draw_id is null.

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 verb and resource: reading completed Base draws, with a bounded scope of one to ten or starting from a public draw ID. It is clear what the tool does, though it does not explicitly distinguish itself from siblings such as get_draw_proof or get_stats.

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 phrase 'or begin at a specified public draw ID' implies how draw_id is used versus limit-only retrieval, but there is no explicit guidance on when to choose this tool over get_draw_proof or get_stats. Usage is inferable but not fully directed.

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 readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds that the proof is public and that 'current' proof is returned 'when available', hinting at a possible absence case, but it never says what happens if no current proof exists.

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?

Two sentences, zero waste, with the core action front-loaded and the optional-parameter behavior immediately after.

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?

An output schema exists, so return values need no explanation. The only meaningful gap is the undefined behavior when no current proof is available, which 'when available' gestures at but does not resolve.

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 0% — the schema only declares a nullable integer with default null. The description compensates by explaining that omitting draw_id returns the current proof, which is the single most important semantic an agent needs for this parameter.

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 verb and resource: 'Read the public proof for a Base draw.' This clearly distinguishes it from siblings like get_draw_history or get_stats, though it never explicitly names those alternatives.

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 second sentence gives parameter-level guidance ('Omit draw_id for the current public proof') but frames it as usage rather than when-to-use-this-vs-another-tool. No exclusions or alternative tools are mentioned.

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 readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds real semantic value by explaining that the returned value is the max of a floor (100 USDC on Base / 100 POL on Polygon) and the live jackpot, which is not derivable from annotations or schema.

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?

Two compact sentences with no filler, and the core definition of the returned value is front-loaded right after the purpose statement.

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?

With an output schema present, return formatting needn't be described, and the read-only annotations cover the safety profile. The chain/currency floor rule is stated; only the default value and the absence of any error/edge-case behavior (e.g., unsupported chain) leave minor gaps.

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 0%, so the description must carry the burden for the single 'chain' param. It names both chain values and associates each with its currency unit (USDC/Base, POL/Polygon), but never states that the parameter is called 'chain' or that 'base' is the default, leaving part of the semantics undocumented.

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 verb and resource ('Read the effective jackpot') and immediately defines what 'effective' means via the minimum/live-jackpot rule. It is clearly distinct from sibling tools like get_stats or get_draw_history, though it does not name or contrast them explicitly.

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?

Usage is only implied: an agent can infer this is the tool for fetching the current jackpot amount per chain. There is no explicit 'use this when...' guidance, no mention of when to prefer it over get_stats, and no stated prerequisites (e.g., whether it requires an active draw).

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?

Goes beyond the annotations by disclosing that a signing step is required, that the returned management token is one-time, which wallets it protects, and that 'no funds move.' This meaningfully clarifies the destructiveHint=false safety profile for a mutation tool. The 'one-time token' wording sits slightly uneasily against idempotentHint=true but does not outright contradict it.

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?

Four tight sentences that front-load the two-phase flow and the safety note. A little marketing gloss ('secure shared affiliate enrollment') but no wasted sentences.

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?

An output schema exists so return structure needn't be explained, and the signing flow is covered. However, for a 10-parameter, 0%-coverage, two-step auth tool, the description leaves the majority of parameters and the management_token round-trip ambiguous.

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 0% across 10 parameters, so the description must compensate. It only names challenge_id and signature (and implies the chain-specific wallet params), leaving agent_id, wallet_address, connected_wallet, management_token, and primary_chain completely unexplained in both description and 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?

States a specific two-phase action (begin/finish affiliate enrollment) that an agent can distinguish from the sibling jackpot/ticket tools. The 'referral' name vs 'affiliate enrollment' wording is slightly inconsistent, keeping it from a 5.

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?

Explicitly describes the two-step invocation: first call returns a signable message, then resubmit challenge_id plus signature. No alternatives or when-not guidance, but the operational flow is clearly laid out.

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 readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it reads current values and contract metadata, but does not add notable behavioral details beyond 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 a single front-loaded sentence listing the exact returned data. There is no filler and every clause contributes to identifying the tool's output.

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 zero-parameter read tool with rich annotations and an output schema, the description is largely complete. The only missing context is how this differs from closely related sibling tools such as get_jackpot.

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 takes zero parameters, so there is no parameter semantics burden. The description correctly does not invent parameters, and the empty schema is consistent with the description.

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 uses a specific verb ("Read") and names concrete resources: current Base draw number, jackpot, next draw time, and contract metadata. It is clear what the tool returns, but it does not explicitly distinguish itself from overlapping siblings such as get_jackpot or get_capabilities.

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?

Usage is implied by "current" and the aggregate nature of the fields, suggesting a snapshot/overview use case. However, the description gives no explicit when-to-use guidance or alternatives such as get_jackpot for jackpot-specific queries.

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 readOnlyHint, idempotentHint, and destructiveHint=false, so 'This does not move funds' largely restates structured data. The one genuinely additive detail is the scope limit to the active draw, but nothing is said about openWorldHint behavior (live chain read), failure modes for an invalid address, or rate limits.

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?

Two short sentences with the operation and scope front-loaded and no filler. The funds sentence is mildly redundant with readOnlyHint, keeping it just below 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?

An output schema exists, so return values need not be explained. However, the definition leaves 'active draw' undefined (presumably discoverable via get_jackpot) and gives no address format, which are the two things an agent needs to invoke this correctly.

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 0% for the single wallet_address parameter, so the description must compensate. 'Base wallet' implies an EVM-style address and the chain context, but no format, checksum, or validation expectations are given.

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 verb and resource ('Read a Base wallet's tickets') and scopes it to 'the active draw', which separates it from get_draw_history and check_wallet_prizes. It never names a sibling tool or says what it is not, so differentiation is inferred rather than stated.

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?

There is no guidance on when to call this versus check_wallet_prizes, get_draw_history, or prepare_ticket_purchase. The second sentence ('This does not move funds') is a safety reassurance, not a usage condition, so the agent must guess at the call context.

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?

Goes beyond the annotations with the two facts that matter most: the output is unsigned wallet transactions and the tool itself never signs or broadcasts. The approval/policy requirement is real operational context. It does not reconcile the destructiveHint=true annotation with the 'nothing happens yet' framing, nor explain that the returned payload becomes destructive only on submission.

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?

Two short sentences with the hard constraints front-loaded and zero filler. Every clause carries either scope or a safety condition.

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?

An output schema covers return values, but a 7-parameter financial tool with zero parameter documentation anywhere leaves the agent unable to correctly form the 'numbers' array or reason about idempotency/expiry. The description also never resolves why idempotency_key exists alongside idempotentHint=false.

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 0%, so the description carries the full burden and largely fails. 'numbers' (count, range, uniqueness), 'idempotency_key', 'agent_id', 'referral_id', and 'valid_until' formats are never explained; only the 1-USDC price ceiling is hinted at.

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?

Names a specific verb (prepare), a precisely bounded resource (exactly one unsigned 1-USDC Base ticket purchase), and the key scope constraint that it never signs or broadcasts. That scope statement implicitly but clearly separates it from confirm_ticket_purchase among the siblings.

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?

Explicitly states the required precondition: obtain owner approval or apply a narrow owner policy before submitting the returned wallet transactions. It implies prepare-then-confirm workflow but never names confirm_ticket_purchase as the follow-up step, so routing among siblings is inferred rather than stated.

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