Server Quality Checklist

Tool Scores

• loot_list_tokensC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description must fully disclose behavior. It states a prerequisite ('Needs LOOT_API_URL') and implies a read-only 'Discover' action, but it does not confirm the operation is non-destructive, describe the response format, mention pagination, or disclose any side effects. The disclosure is minimal and insufficient for a tool with zero annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no redundant words. It front-loads the core purpose, then lists filters and options, then the prerequisite. Every sentence adds value, and the structure is efficient and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 5 optional parameters and no output schema. The description fails to mention the return structure, pagination behavior, or how 'limit' controls output. It also omits details on sort_order and does not explain the full set of sort_by options. For a discovery tool, this leaves significant gaps in what an agent needs to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It explains the 'filter' parameter by listing enum values and clarifying 'bonding (pre-graduation)', and it mentions 'Optional search and sorting.' However, it does not explain the 'limit' parameter, the meaning of 'sort_by' values (marketCap, volume, etc.), or the 'sort_order' options. Only partial parameter semantics are provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action ('Discover LOOT tokens') and resource ('from the platform feed'). It lists filters and mentions search/sorting, which is specific enough to distinguish it from action-oriented siblings like loot_buy or loot_sell. However, it does not explicitly contrast with other list-like tools (e.g., loot_status), so it is clear but not fully differentiated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies a common use case (listing tokens) but provides no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions or say 'use this when you need a list of tokens' or refer to sibling tools. Usage context is left entirely to inference.

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

• loot_wallet_statusB
  3.3/5.0
  Behavior3/5

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

  The description states 'Chain reads only,' which is a useful behavioral disclosure (no mutations), and it implies the tool returns current data without side effects. However, it does not describe potential errors, rate limits, or what happens with invalid addresses, and there are no annotations to supplement this. The read-only note is a positive but incomplete disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, information-dense sentence that front-loads the main purpose (wallet ETH balance and keys) before the optional token clause. It avoids redundancy and is appropriately sized for the tool's scope, though slightly long due to enumerating fields.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description lists the data returned but omits details like the response format, pagination (if any), and error handling. For a read-only tool with no output schema and no annotations, this is a moderate gap. The 'chain reads only' note helps, but an agent would still need to infer behavior around missing or malformed input.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It explains that 'with token' enables the full game position, implying token is an optional address, but it does not clarify the relationship between 'wallet' and 'token' (both appear to be addresses per the schema's $ref). The description adds some meaning but leaves ambiguity about why and when to supply the token parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool as retrieving a wallet's ETH balance, universal keys, welcome state, and optional full game position with a token. It uses specific terms (ETH balance, universal keys, unopened boxes) that distinguish it from generic 'status' tools, and the 'wallet' qualifier separates it from token-centric siblings like loot_token_state.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives. It does not mention loot_token_state, loot_status, or when to omit or include the optional token parameter. 'Chain reads only' is the only contextual hint, but it doesn't help select among siblings.

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

• loot_quoteA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the full behavioral burden. It discloses revert behavior ('A revert here means the trade would fail and the reason is reported'), which is valuable. It also implies read-only semantics via 'eth_call', but it does not explicitly state that no state is modified. The absence of an explicit read-only disclosure is a minor gap, but the revert disclosure adds transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each with a clear purpose: the first defines the tool's function, the second explains side-dependent parameter selection, and the third communicates failure behavior. Information is front-loaded with the primary purpose. No fluff or repetition. This is exemplary conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of annotations and output schema, the description covers the most critical points: what the quote provides, how to choose the correct amount parameter, and revert semantics. However, it does not explicitly state that the operation is read-only, describe the response format, or explain the 'token' and 'from' parameters. For a tool with 5 parameters and no output schema, this leaves some gaps that an agent might need to infer.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It does clarify the side-conditional usage of amount_eth and amount_tokens, which is essential for correct invocation. However, it does not explain the 'token' parameter (beyond the schema's pattern) or the optional 'from' parameter. This partial compensation keeps it at a baseline of 3 rather than higher.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it provides an execution-time quote via eth_call with exact tick math, fees, and caps for the calling wallet. This is a specific verb-resource pair and distinguishes it from execution tools like loot_buy/loot_sell, though it doesn't explicitly name alternatives. It leaves little ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives guidance on parameter usage ('side buy takes amount_eth, side sell takes amount_tokens'), which is useful for constructing the call, but it does not indicate when to use this tool versus siblings like loot_buy or loot_sell. It implies it's a pre-trade check but never explicitly states 'use this to validate a trade before executing' or contrasts with alternative tools.

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

• loot_standingsA
  3.5/5.0
  Behavior3/5

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

  No annotations are provided, so the description must disclose behavior. It mentions data comes from 'public tRPC lanes' implying a read-only operation, and notes the requirement for LOOT_API_URL. It does not explicitly state side effects, rate limits, or error behavior, but enough is implied for a likely safe read. It lacks explicit readOnly declaration but does not contradict any annotation (since none exist).

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tight, with three sentences that are front-loaded with purpose and then explain parameters. No wasted words, and the environment requirement is noted succinctly. Structure is logical and easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (two optional params, no output schema), and the description covers purpose, parameters, and environment requirement. However, it does not describe the return format or behavior when both wallet and day are given, or when neither is passed. This leaves some ambiguity for an agent, though not critical for a read-only data fetch.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage, so the description must add meaning. It does: it explains that wallet filters for a specific wallet's rank/standing, and day filters for a past day's final board, including the date format. This goes beyond the raw patterns and clarifies the purpose of each parameter, compensating well for the lack of schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear purpose: returning season clock and daily prize board data, with optional filtering by wallet or day. It uses specific resource terms ('season clock', 'daily prize board') and is distinct from siblings like loot_status or loot_list_tokens, which focus on other aspects. The verb is implied but clear enough.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives usage guidance for parameters (wallet for rank/standing, day for past board) and mentions the necessary environment variable LOOT_API_URL. However, it does not explicitly contrast with sibling tools or state when to choose this tool over alternatives. The guidance is functional but not comprehensive.

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

• loot_claim_lootA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries full responsibility. It discloses that the tool pays native ETH, determines amount from the receipt's Claimed event, and requires LOOT_AGENT_PRIVATE_KEY. However, it omits failure conditions, idempotency, or what happens if no pending share exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each with substantive information: the core action, the payment and amount derivation, and the authentication requirement. No redundancy, efficiently front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter mutation with no output schema, the description covers key aspects: what it does, how the amount is determined, and the required key. It lacks details about preconditions like checking outstanding shares, but overall adequate for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It clarifies that the single parameter 'token' is the address of the token for which to claim, adding meaning beyond the pattern-only schema. Still, it provides no further detail beyond that identification.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly identifies the action (claim), the resource (pending pot share for a specific token), and the source (ledger). It distinguishes itself from siblings like loot_claim_keys and loot_claim_rails by specifying 'pot share' and 'token'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives such as loot_claim_keys or loot_claim_rails. It implies a pending share exists but does not mention how to check or which conditions warrant this tool over others.

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

• loot_sellA
  3.6/5.0
  Behavior4/5

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

  With no annotations, the description carries full behavioral burden. It discloses the one-time approval, exact quote, refusal on unprotected floor, fixed gas, private key requirement, and that selling burns the game position. This is strong transparency, though it omits details like revert behavior, fee implications, or what happens on failure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense and front-loaded with the core action, then enumerates the two amount modes and the security/approval behavior. Every clause adds value, though it could be tightened by removing the 'Fixed 5,000,000 gas' and 'Needs LOOT_AGENT_PRIVATE_KEY' which are operational constants but not strictly necessary for basic invocation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with 5 parameters and no annotations or output schema, the description covers the essential flow (approve, quote, refuse) and the safety constraint, but it does not explain what the function returns (e.g., transaction hash, success message), how errors surface, or whether the token must come from loot_list_tokens. Some gaps remain for an agent to invoke correctly without external knowledge.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is only 40% (percent and amount_tokens have descriptions), and the tool description clarifies the mutual exclusivity of those two, which is helpful. But it does not explain slippage_bps (basis points meaning), deadline_seconds (until when), or the token address (which specific LOOT token). The description partially compensates but leaves key parameter semantics to inference.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool sells a LOOT token for ETH via a router, and mentions the two input modes (amount or percent). The action is specific and distinguishable from the buy/sell session, but it does not explicitly contrast with loot_buy or other siblings, so it's not a full 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It is obvious from the verb 'sell' when to use this tool, and the description gives the operational sequence (approve, quote, refuse). However, it does not state when NOT to use it (e.g., buying with loot_buy), nor does it suggest alternatives like loot_quote for pre-sell quotes. Usage context is implied but not explicitly scoped.

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

• loot_claim_railsA
  3.7/5.0
  Behavior4/5

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

  With zero annotations the description carries the full burden, and it does substantial work: it discloses the simulation-first flow ('simulated first, only paying days are sent'), the version incompatibility (no v3 cashback lane on v4), and the credential prerequisite (LOOT_AGENT_PRIVATE_KEY). It omits failure and reversibility semantics, but meaningful behavioral context is disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A compact single paragraph that is front-loaded with purpose, then enumerates the lanes, then closes with version and auth notes. Every clause earns its place and there is no wasted wording, though the content is dense enough that a reader must parse it carefully.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 1-optional-param tool with no output schema, the description covers the claim lanes, the simulation/paying-day filter, the version incompatibility, and the required credential. Missing are return-value semantics and failure behavior, but against the tool's low complexity these are minor gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the sole parameter days_back, including its range (1–30) and default (5), so the baseline of 3 applies. The description only loosely echoes the parameter via 'recent closed daily prize boards' and adds no format or syntax detail beyond what the schema already documents.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb ('Claim') with a scoped resource ('from the trader rails') and enumerates the exact lanes: closed daily prize boards, the 12h rank drip, and season promo keys. The v3/v4 note adds useful version-specific context. It's clear and distinctive, though it never explicitly contrasts with closely named siblings like loot_claim_keys and loot_claim_loot.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The 'everything this wallet can' phrasing implies a catch-all aggregator, which gives implicit when-to-use guidance. However, no alternative is named and no when-not condition is stated; with siblings loot_claim_keys and loot_claim_loot present, an agent gets no explicit direction on when to prefer a narrower claims tool over this aggregate.

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

• loot_claim_keysA
  3.9/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral burden. It discloses that claims are simulated first and only paying claims are sent, uses fixed gas per family, reads granted counts from receipts, and requires LOOT_AGENT_PRIVATE_KEY. This is substantial transparency, though it omits failure handling and return values, which are minor gaps for a transaction tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences with no redundancy. The primary action is front-loaded, followed by the simulation behavior, gas/receipt details, and auth requirement. Every sentence adds necessary information without filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the claim execution and requirements but lacks an explanation of the output format, error handling, or prerequisite state checks (e.g., how to verify claimability). Since there is no output schema, an agent does not know what the function returns or how to interpret success/failure. This is a notable gap for a transaction-relevant tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema defines 'token' with an address pattern and the description only adds 'for a token', clarifying the operation's target. It does not explain how to validate the token, prerequisites, or relation to other tools. Given 0% schema description coverage, the description should compensate more; it provides minimal added value beyond the schema's pattern.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the action ('claim') and the resource ('every key family'), listing specific types (universal drip, streak, etc.). It also distinguishes itself from siblings like loot_claim_loot and loot_claim_rails by focusing exclusively on keys. The simulation behavior is stated upfront, making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is the tool for claiming keys, but it does not explicitly contrast with sibling tools or provide when-not-to-use guidance. There is no mention of alternatives like loot_claim_loot or loot_claim_rails, leaving the routing to inference. The context is clear for the key-claim scenario, but exclusions are absent.

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

• loot_open_boxA
  3.9/5.0
  Behavior5/5

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

  With no annotations, the description carries full behavioral burden, and it succeeds: it discloses the key expenditure, pile reduction, drand round waiting, beacon fetching, on-chain settlement, key-source fallback logic, and the need for LOOT_AGENT_PRIVATE_KEY. It also states the reported outcome (tier counts and loot minted). This is comprehensive for a mutating tool and exceeds typical transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a dense but single-paragraph with no wasted words. It front-loads the core action and proceeds sequentially. Slightly long due to process details, but every sentence adds context. Could be broken into bullets for clarity, but for a single-sentence approach it is efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex on-chain operation with no output schema and no annotations, the description covers the process well but omits key parameter semantics (especially the required token) and does not mention optional parameters or defaults. It also doesn't state that the tool requires a token input, which is the only required field. The agent understands the flow but lacks parameter-level specificity, leaving room for invocation errors.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description should explain each parameter. While it mentions 'chosen tier' and 'key source', it does not explicitly map to the tier, token, and key_source parameters. The token parameter is required but completely undefined in the description; key_source's enum values are not explained beyond 'auto' behavior. This leaves the agent to infer parameter meanings from schema alone, which is insufficient given zero coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action (open loot boxes), describes the resource (loot boxes, keys, pile), and outlines the multi-step process: spending keys, waiting for drand round, fetching beacon, settling on-chain. This clearly distinguishes it from siblings like loot_settle_opens (which handles settlement separately) and loot_buy/sell. The purpose is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains the mechanics but gives no explicit guidance on when to use this tool versus alternatives such as loot_settle_opens or loot_claim_keys. It implies usage when the agent wants to open boxes, but does not state conditions, prerequisites, or alternatives. The key-source auto behavior hints at configuration, but not usage context.

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

• loot_statusA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of disclosing behavior. It lists the type of information returned (chain id, wallet balance, etc.) but does not explicitly state that this is a read-only, side-effect-free operation. The term 'status' strongly implies no mutations, but not as clearly as 'read-only' or 'does not modify state.' It also omits any mention of authentication, rate limits, or potential failures.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, information-dense sentence that front-loads the core purpose ('Server health and configuration') followed by a concise list of included data points. It avoids fluff and clearly communicates scope, though the enumerated list reads a bit like a bulleted list without formatting, which could be slightly more scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema and no annotations, the description effectively outlines the return content (chain id, RPC check, wallet info, mode, API reachability, contract addresses). It covers the essential fields an agent would need to interpret the tool's output. However, it does not describe the structure (e.g., is it a JSON object with those keys?), nor does it mention error conditions or return codes, which are minor gaps for a status tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there is nothing to explain. Per the baseline rule for tools with 0 parameters, a score of 4 is appropriate. The description actually goes beyond the schema by listing the specific categories of information returned, adding value despite having no parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it covers 'Server health and configuration' and enumerates specific data points (chain id, RPC check, wallet balance, armed/read-only mode, API reachability, contract addresses). This is a precise verb-resource combination that distinguishes it from sibling tools, which are all actions (buy, sell, claim, etc.) rather than status checks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The tool's purpose as a status/health check is clear, and sibling names (loot_buy, loot_sell, etc.) suggest it's for inspection rather than mutation. However, the description does not explicitly state when to use this versus other tools, nor does it mention any preconditions or timing (e.g., 'run before transactions'). Usage context is implied but not explicitly guided.

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

• loot_token_stateA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of disclosing side effects and safety. It explicitly states 'Chain reads only, no API needed,' which clearly signals a read-only, side-effect-free operation. While it doesn't detail error behavior or rate limits, the core safety trait is disclosed. This is strong for a read tool, though some nuance about failure modes is missing.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, well-structured sentence. It front-loads the purpose, then enumerates included data fields, and adds a safety note. Every word contributes meaning; there is no filler or redundancy. The length is appropriate for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only tool with one parameter and no output schema, the description covers the key data returned and the safety profile. It does not mention potential edge cases (e.g., unlaunched token, invalid address), but for a straightforward state query, the provided information is sufficient for an agent to call it correctly. A 4 is fair given the simple nature.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It does by stating 'One token's live on-chain state,' which implies the token parameter is the address of the token of interest. The parameter name 'token' and the schema pattern (Ethereum address) already convey the format. The description adds minimal semantic value beyond that, and given the simplicity, a 3 is appropriate—adequate but not rich.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb (retrieve) and resource (one token's live on-chain state) and enumerates specific data points (name, supply, pool, spot price, FDV, game ledger state). It is unambiguous and distinguishable from siblings: it focuses on a single token's detailed state, while siblings like loot_list_tokens list tokens and loot_quote provide quotes. No ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for a single token's on-chain state, but does not explicitly mention when to use this tool versus alternatives. For example, it doesn't say 'use loot_list_tokens for multiple tokens' or 'use loot_quote for pricing'. The context is clear, but exclusions and alternative guidance are absent, leaving the agent to infer the boundary.

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

• loot_settle_opensA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries full responsibility. It discloses that the operation is permissionless, requires LOOT_AGENT_PRIVATE_KEY to send transactions, credits loot to the requesting wallet, and skips settled/unpublished requests. This covers key trait implications (mutation, auth, idempotency) beyond what annotations might provide. Minor gap: no mention of return format, but not critical for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four terse sentences, each adding distinct information: purpose+permissions, invocation options, skip behavior, and key requirement. No fluff, front-loaded with the core action. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (mutation, optional params, drand dependency, permissionless), the description covers the essential points: when to use, how to invoke, key requirement, and side effects. It does not detail output format or error conditions, but with no output schema and the described specifics, it is sufficiently complete for an agent to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 67% (wallet and scan_last have descriptions; ids does not). The description adds value by explaining the relationship between ids and scan_last ('Pass ids, or let it scan the newest requests') and defaults for scanning. This clarifies parameter usage beyond the schema's bare properties, partly compensating for the coverage gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Finish' and resource 'pending box opens', and explains the permissionless nature of submitOpen. It distinguishes from siblings like loot_open_box (initiation) and loot_claim_loot (claiming) by focusing on the settlement step, though it does not explicitly name alternatives. This is specific and actionable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear usage context: settle when drand round is published, and options to pass ids or scan newest requests. It also notes skipping of settled requests and unpublished rounds, which defines when the tool is applicable. It does not explicitly mention when to use an alternative tool, but the conditions are well-articulated.

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

• loot_buyA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full burden. It discloses several behavioral traits: it performs a quote before executing, applies slippage, uses fixed gas (5,000,000) and never estimates, and requires a specific environment variable. This exceeds what one might expect from a typical buy tool, though it does not detail failure modes or confirmation behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise (two sentences) yet packs essential details: purpose, quoting behavior, slippage, gas, and key requirement. The main purpose is front-loaded, and no superfluous wording exists.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a buy transaction with 4 parameters and no output schema, the description covers the critical operational details: quote-before-execute, slippage, gas, and key requirement. It does not explicitly explain token address format or deadline semantics, but those are inferable from their names and types. The description is sufficient for an agent to correctly invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is only 25% (only eth_in has a description). The description adds value for slippage_bps by specifying a default (200) and explains that the trade executes at quote minus slippage. It does not add semantics for token or deadline_seconds. Since coverage is low, this partially compensates but leaves gaps for two parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Buy'), a specific resource ('LOOT token with ETH'), and the mechanism ('through the deployed router'). It cleanly distinguishes from siblings like loot_sell (selling) and loot_claim (claiming) by explicitly naming the action and asset.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains the internal process ('Quotes the exact trade first via eth_call') and the slippage handling, which implies when this tool is appropriate (when buying LOOT). It does not explicitly state exclusions or alternatives, but the context of buying is clear from the name and purpose. It also notes a prerequisite (private key), which is a practical usage hint.

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

• loot_launchA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full disclosure burden and meets it comprehensively: it states the escrow amount (0.01 ETH + dev buy), the contingent policy actions, the auto-cancel on failure with the exact refund split (0.009 ETH + dev buy back, factory keeps 0.001), and the environment needs. For a tool that moves funds, this level of failure-path and fee transparency is exceptional.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Every clause earns its place — ceremony steps, policy branches, failure refund, fees, prerequisites — yet it is delivered as one dense ~130-word paragraph with no bullets or line breaks. Highly informative but harder to scan than the complexity warrants.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a multi-step, fund-moving tool with nested params and zero annotations, the description covers process, contingency, funds flow, and readiness conditions thoroughly. The single meaningful gap is the return value: since there is no output schema, the agent is never told what a successful call yields (only the internal 'signed launch ticket' is mentioned).

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is only 29%, so the description must compensate, and it does for the most complex params: policy is explained mode-by-mode, max_buyout_wei is contextualized as a hard budget against the live quote, and dev_buy_eth is tied into the escrow math. Rate-limited to 4 because plainly-named params (name, ticker, socials, description) get no added explanation, which is acceptable since they are self-evident.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a precise verb+resource ('Launch a new LOOT token through the factory ceremony') and immediately distinguishes itself from siblings like loot_buy/loot_sell (trading existing tokens) and loot_claim_* (claiming rewards). The ceremony framing makes the tool's unique role in the family unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The policy modes (clean_only, tribute_ok, buyout) each get a behavioral consequence, giving an agent clear conditions for when each path fires. The prerequisites (LOOT_AGENT_PRIVATE_KEY, LOOT_API_URL) hint at readiness conditions. It doesn't explicitly say 'prefer loot_buy when trading an existing token, not this,' so it stops short of fully contrasting with siblings, but the mode explanations serve as strong situational guidance.

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