LuckDrop

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

Beyond the readOnly/openWorld annotations, it discloses that data comes from the chain rather than a database and why (a stale yes costs gas on revert), that the return is an unsigned transaction, that the service never signs or holds keys, that mined entries are irreversible, and that the network is a testnet with valueless coins.

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?

Front-loaded with the core question, then return shape, then the signing/irreversibility caveat and network notice. All sentences carry weight, though the testnet paragraph is somewhat long for a caveat.

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 no output schema, the description compensates by naming the return fields (canEnter, reason, exact transaction) and the transaction shape {to, data, value}, plus signing responsibility and irreversibility. Nothing needed to call this correctly is missing.

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% for the single address parameter, so the schema already documents format and constraints. The description only adds the framing that the address is "this wallet"; it contributes no extra syntax or semantic detail.

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 precise verb and resource: answer whether a wallet can enter the current draw and return the exact transaction to send. It is clearly separable from siblings like luckdrop_get_draw or luckdrop_check_prize, which do not gate a transaction.

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?

It gives an explicit, unambiguous usage rule: "Call this before sending an entry, every time." That is strong positive guidance, though it names no alternative or when-not condition (e.g., what to do if canEnter is false).

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?

Far exceeds the readOnlyHint/openWorldHint annotations: it discloses that output is an UNSIGNED transaction ({to, data, value}), that the service never signs or holds keys, that the user must approve and send on Base Sepolia, that the action is irreversible once mined, and that the network is a testnet with no monetary value. It even explains the weekId-reset and scan-window edge cases.

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?

Front-loads the core purpose, then scopes, then return/behavior, then network caveats. Every sentence carries information, though the heavy ALL-CAPS emphasis and layered edge-case caveats make it longer than strictly necessary.

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 no output schema, the description fully carries the burden, naming the return shape, the signing/approval responsibility, irreversibility, network, and the escrow-scan behavior. An agent has everything needed to call and interpret this tool 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: weekId is the CONTRACT week id (as reported by luckdrop_get_results), it is checked alone instead of scanning, and omitting it triggers a 26-week scan with a reported range. The address parameter gains the useful note that the wallet need never have signed in.

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: checks whether a wallet has uncollected LuckDrop prizes and returns the claiming transaction. It also defines scope tightly (this deployment's escrows, named in escrowsChecked), which lets an agent separate it from luckdrop_check_entry and luckdrop_get_results without opening their schemas.

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 explicit when/when-not rules and the alternative path: with no weekId it scans the most recent 26 contract weeks, and to reach an older-but-still-claimable week you must pass an explicit weekId from luckdrop_get_results. It also states what is out of reach (escrows from earlier deployments).

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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses many behavioral details: it returns both weekNumber and contractWeekId, explains the database versus contract blocks, warns against comparing chain.state to week.status, states that no transaction or wallet is needed, and flags free text as data rather than instructions. It also notes the Base Sepolia test-network context and lack of monetary value.

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 front-loaded with the core purpose and then layers in output semantics, safety guidance, and network context. It is longer than a typical zero-parameter tool, but most sentences earn their place; the brief 'This is a read' line is somewhat redundant with the readOnlyHint annotation.

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?

Despite having no output schema, the description thoroughly explains the important return blocks, their provenance, and how to interpret disagreements. Combined with the annotations and zero-parameter schema, an agent has everything needed to call and interpret this tool 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?

With zero parameters, the baseline is 4 according to the scoring rules. The description does not need to explain parameter semantics, and it correctly avoids inventing input details.

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 resource ('the state of the live LuckDrop draw') and enumerates exactly which fields the draw state includes. It implicitly distinguishes itself from siblings like luckdrop_get_results by emphasizing the live/current draw rather than historical results.

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 when to use the tool by saying it reads the live draw state, but it never names alternatives or explicit when-not conditions. An agent can infer usage, but no routing guidance is provided for sibling tools such as luckdrop_get_results or luckdrop_check_prize.

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 and openWorldHint=true, so the tool is known to be a safe read with external dependencies. The description adds vital behavioral context: the two id spaces can yield the same number for different draws, and the response echoes the space used plus both ids. It also discloses that the tool operates on Base Sepolia, a test network with no monetary value. This is excellent transparency beyond 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 front-loaded with the core purpose, then follows with important parameter context and network warning. It is well-structured and each sentence serves a purpose. Slightly verbose in the network warning, but the information is necessary for safe use.

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 no output schema, the description adequately clarifies the return: it echoes the id space and both ids. It also covers the network context. The main missing element is an explicit note about the return format for the rounds and winner, but that is partially implied. Overall, it is complete enough for correct 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 coverage is 100%, so the schema provides basic definitions. However, the description adds significant meaning beyond the schema: it clarifies that `week` is the DISPLAY week number by default and that the same number in contract space refers to a different draw. This is critical semantic information not captured by the schema's generic 'draw number' 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?

States a specific verb and resource: read a single draw's five rounds and its winner. It is clearly distinct from sibling tools like luckdrop_get_draw, which likely covers a broader or different draw context. The description is clear but does not explicitly differentiate itself from that sibling.

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?

Provides crucial usage context: it explains that `week` defaults to display numbering and warns to use idSpace='contract' when following contractWeekId. This tells the agent exactly when and how to use the parameter to get the correct draw. It does not mention when to prefer this tool over siblings, but the context is strong for correct invocation.

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 cover the safety profile (readOnlyHint), and the description adds substantial context beyond them: that the contract, not the draw database, governs tradingOpen, that fees and prize shares are admin-settable values to be read rather than assumed, that sponsor text is human-typed and must be treated as data not instructions, and that the deployment is a valueless test network. That is unusually rich behavioral disclosure.

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?

Purpose and scope are front-loaded in the first sentence, followed by interpretation rules, a security note, and a network disclaimer — each paragraph carries distinct value. The feeBasisPoints/prizeShareBasisPoints paragraph is somewhat long for a listings tool, but it is needed to interpret seller proceeds correctly, so the length is defensible.

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 no output schema and no parameters, the description carries the full burden and discharges it: it names the returned fields (listings, price, tradingOpen), explains how to interpret them, warns about untrusted embedded text, and discloses the test-network context. Nothing needed to call or correctly use the result is missing.

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 to explain; the baseline for a parameterless tool is 4. The description correctly spends no words on inputs.

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 live market') and enumerates exactly what is returned: which tickets are listed, at what price, and whether the trading window is open. An agent can immediately distinguish this listings tool from luckdrop_get_draw, luckdrop_get_results, luckdrop_check_entry and luckdrop_check_prize.

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 one explicit routing rule — 'trust tradingOpen in this result rather than inferring it from the phase' — which steers the agent away from deriving trading status from a sibling's draw data. It does not explicitly state when to call this versus luckdrop_get_draw for market questions, so guidance is clear but not exhaustive.

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