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?

Rich disclosure beyond the annotations: returns an unsigned {to, data, value} transaction, never signs or holds keys, requires user approval on Base Sepolia, is irreversible once mined, and is on a test network with valueless LUCK coins. The 180-day claim window and the 26-week scan window are also surfaced. The only minor gap is it does not say explicitly whether a no-prize result is an empty response or an error.

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 action, then clearly delimited SCOPE and NETWORK sections that each carry necessary constraints. It runs long and repeats the unsigned-transaction point once, but nearly every sentence prevents a concrete misuse, so the length is largely justified.

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 describing the return shape ({to, data, value}) and the fact it is unsigned. Combined with scope limits, week semantics, and the test-network caveat, an agent has everything needed to call and interpret 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 coverage is 100%, so the baseline is 3, but the description genuinely enriches weekId: it is a CONTRACT week id that overrides the scan, reaches older weeks only on this deployment's escrows, and is the same id luckdrop_get_results reports. That context is not derivable from the schema's min/max bounds alone.

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+resource+outcome: checking whether a wallet has an uncollected prize and returning the transaction that claims it. It also clarifies the mechanism (read from chain, works without website sign-in), which separates it from luckdrop_check_entry and luckdrop_get_results, which deal with entries and results rather than claimable prizes.

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 when/when-not guidance: default behavior scans the most recent 26 contract weeks, and passing an explicit weekId is prescribed for reaching older weeks on the same escrows. It also states the hard boundary that prizes in earlier deployments are unreachable and names luckdrop_get_results as the source of the contract week id.

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.