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

With no annotations, the description carries the full burden and does disclose meaningful behavior: the ledger validates signature, payee wallet and on-chain receipt, and booking is idempotent. However, it omits auth/permission requirements, failure behavior, and what a successful booking returns.

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 purpose is front-loaded and the text is short, but the trailing fragment 'agent: 0x agent address if not a local bot.' reads as a dangling note rather than an integrated sentence. It is efficient without being well structured.

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 mutation tool with no annotations, no output schema and 0% parameter documentation, the description should do much more. It covers validation and idempotency but leaves the required payload/settlement semantics and the other optional parameters unexplained.

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% across 5 parameters, so the description must compensate and largely does not. It adds meaning only for 'agent' (a 0x address when not a local bot), leaving bot, settlement, paymentPayload and paymentRequirements undocumented in both the schema and 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?

States a specific verb (book) and resource (a settled x402 payment received as income on the Agent Ledger), which cleanly separates it from the outbound sibling pay_x402. It is clear what the tool does, though it does not name siblings explicitly for differentiation.

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 'a settled x402 payment the agent received as income' implies the tool is used after settlement, and 'Booking twice is safe' hints at retry behavior, but no explicit when-to-use/when-not or named alternative is given. Guidance is only implied.

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, so the safety profile is covered. The description adds the address-format constraint, which is genuine behavioral context. It does not say what happens when the address format does not match the shard (error vs empty result) or how a nonexistent address is reported.

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 tight sentences with the core purpose front-loaded and the format constraint immediately after. No filler, no repetition of the tool name.

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?

There is no output schema, so the description is the only place to learn what comes back, yet it never says whether the balance is a raw integer, a decimal string, or in what units. For a balance-query tool that is a meaningful omission, though the input side is adequately covered.

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 parameter burden, and it does the important part: it ties the address format to the shard value (0x for shard 0, 1S.. for shards 1-4). It still never states the valid shard range explicitly (only implying 0-4) or the default of 0 that the schema sets.

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 resource and scope: the native SCDO balance of an address on one shard. An agent immediately understands this is a single-shard balance read. However, it does not distinguish itself from the sibling get_balance, leaving ambiguity about which balance tool to pick.

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 address-format rule ('Shard0 takes 0x addresses; shards 1-4 take 1S.. classic addresses') functions as an implied usage condition that tells the agent which shard/address pairing is valid. Beyond that there is no explicit when-to-use guidance and no comparison to get_balance, which is the obvious alternative for balance 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=true and openWorldHint=true, so the safety profile is covered. The description adds useful specifics—the scdo.com.au explorer API source and 25-per-page pagination—but omits auth needs, rate limits, and return format.

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 compact sentence with no wasted words. The essential scope and pagination detail are front-loaded.

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 read-only explorer query with no output schema, the description is adequate but incomplete. It says what is returned generally, yet gives no detail about transaction fields or how to navigate pages beyond the page size.

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 clarifies that the address is a 0x address and implies pagination with 25-per-page, but it does not explicitly explain the page parameter or its default.

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 the resource precisely: transaction history for a 0x address on Shard0. It is clear what the tool does, but it does not name or distinguish itself from nearby siblings such as chain_address_balance or chain_tx_status.

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 use this tool versus alternatives like chain_tx_status or chain_address_balance. The source API is named, but no usage conditions or exclusions are provided.

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, openWorldHint), so the bar is lower. The description still adds domain context by mapping shard IDs to networks (0 = EVM Shard0, chainId 5680; 1-4 = SCDO Classic), which is not derivable from the 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 tight sentences with the resource and scope front-loaded, followed immediately by the parameter semantics. No filler.

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 single-optional-parameter read tool with no output schema, the description covers purpose, scope, and parameter meaning adequately. It does not state the return shape when shard is omitted (single integer vs. per-shard mapping), which is the only remaining gap.

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 does so: it defines the shard value space, maps 0 and 1-4 to specific chains, and explains the null/omit behavior (returns all five). Nothing needed to call the parameter correctly is missing.

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+resource: current block height of the SCDO chain. It is clearly distinct from siblings like chain_tx_status and chain_address_balance, though it never explicitly names an alternative to route against.

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?

"Omit shard for all five" gives real usage instruction for the default case, but there is no explicit when-to-use/when-not guidance or reference to sibling tools. Usage is implied rather than 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 readOnlyHint and openWorldHint, yet the description adds real value by disclosing the possible result states (success, failed, pending, not_found) and that block and amounts are returned only 'when known' – i.e. partial results are possible. With no output schema, this return-shape disclosure is genuinely 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 that enumerates outcomes and return contents with zero filler. Every clause earns its place.

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 two-parameter read tool with no output schema, the description covers the outcome space and conditional return data adequately. The unexplained 'shard' parameter is the only notable gap.

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%, so the description carries the load; 'by hash' clarifies the role of tx_hash. However, the 'shard' parameter is never mentioned in either the schema or the description, leaving one of two parameters entirely opaque.

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 ('Look up a transaction by hash') and enumerates the outcome domain, which distinguishes it from list-style siblings such as chain_address_txs. It does not explicitly name an alternative, so it stops short of 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?

Usage is implied by 'by hash' – the agent can infer it applies when a tx hash is known – but there is no explicit when-to-use, when-not, or pointer to a sibling for other lookups. Minimum viable.

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 only declare readOnlyHint=false and openWorldHint=true; the description adds genuinely new traits — the code is one-time, expires in 300 s, and yields a browser session plus wallet address. Failure modes (reuse, expiry) are thereby inferable. It omits whether authentication or an existing wallet is required.

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?

One sentence, front-loaded with the action and the object, with the constraints and the return value packed in without waste.

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 one-parameter tool with no output schema, the description supplies both the input constraint and the outcome (browser session + wallet address). Only the upstream dependency on a code-issuing step is left implicit.

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% for the single 'code' parameter, so the description carries the burden — and it does add meaningful semantics: provenance (issued by SCDO Wallet), lifetime (300 s), and single-use. It stops short of format details such as length or character set.

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 (redeem/exchange) and resource (one-time return code from SCDO Wallet) with the exact payoff (browser session and wallet address). It is easy to distinguish from connect_start, though it never names the sibling flow that produces the code.

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 300 s TTL and single-use constraint imply this is a code-redemption step that must follow a code-generation step, but no alternative or prerequisite tool (e.g. connect_start) is named. Usage is implied rather than stated.

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 declare readOnlyHint=false and openWorldHint=true, consistent with creating a connect session. The description adds real value beyond them: it discloses the returned artifacts and reassures 'No keys are involved', which is important for a wallet-connect tool. It stops short of stating auth requirements or token lifetime.

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?

Three short sentences, front-loaded with the action, then the return payload, then the critical constraint. No filler; every sentence adds information.

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?

No output schema exists, yet the description names the return values (token, nonce, connect URL), covering the main return contract. The only shortfall is the undocumented 'src' parameter and absence of next-step guidance toward connect_exchange.

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%, so the description carries the burden. It fully specifies the returnUrl format constraint and implies 'game' selects the game, but the third parameter 'src' is undocumented in both schema and description, leaving a real gap.

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 ('Start an SCDO Wallet Connect flow for a game') and even names the return payload (token, nonce, connect URL). It is distinguishable from sibling connect_exchange as the initiating step, though it never explicitly references 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 one concrete usage constraint — returnUrl must be an scdo.com.au /games/ or /play/ URL — which is genuinely helpful. But it gives no guidance on when to use this versus connect_exchange or other wallet tools, and no prerequisites or flow sequencing.

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?

With no annotations, the description carries the full burden, and it does disclose meaningful side effects: the wallet is created or reused, bound on the Agent Ledger, and funded with USDC on Base with no ETH required. It omits permissions/auth requirements, what happens to an existing wallet's balance on reuse, and error behavior, so it stops short of a 5.

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 dense clauses, each carrying distinct information (provision/bind, funding, no gas, two limit parameters with ranges and defaults). Front-loaded with the action and free of filler.

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?

No output schema and no annotations, so the description is the only source of behavior. It covers the core effects and limits but says nothing about what is returned (address, balance), what 'bot' identifies, or how reuse differs from creation — gaps an agent needs for a provisioning tool.

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% (titles only), so the description must compensate. It usefully documents maxUsdc (0.001–1, default 0.10) and dailyUsdc (up to 20, default 1.00), but the required 'bot' parameter is never explained and the network enum (base/base-sepolia) is only implied by 'on Base', which could mislead about the testnet option.

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 ('Create or reuse the agent's x402 wallet and bind it on the Agent Ledger'), so the agent knows this provisions a wallet rather than querying one. It distinguishes itself from read siblings like get_balance and ledger_get_agent, though it never names the nearest alternatives (register_agent, connect_start).

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?

'Create or reuse' implies idempotent usage, and the funding detail implies this is a setup step, but there is no explicit when-to-use or when-not-to-use guidance and no routing to alternatives. Usage is inferable rather than stated.

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 safety profile is covered. The description adds genuine content context beyond that (hosted on scdo.com.au, free demo and SCDO points bookkeeping games), but says nothing about the shape of the returned list or whether the play links are external URLs.

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 compact sentence with no filler, and the identifying information is front-loaded. The parenthetical is dense but earns its place by characterizing the game types.

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 no-argument, read-only listing tool with annotations covering safety and no output schema, the description supplies enough to call it correctly. Only the return structure remains unspecified, which is a minor gap at this complexity.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate in the schema, and it does not need to.

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 names a specific resource (SCDO Games list) and says what it contains (play links), which lets an agent distinguish it from the catalog-like siblings such as x402_catalog and wallet_downloads. The verb is implicit ('list') rather than stated, but the purpose is clear.

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 statement of when to use this tool versus the other catalog/listing siblings, and no prerequisites or exclusions. The agent must infer usage entirely from the name and content hint.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses what is returned (on-chain USDC plus three ledger currencies), which signals a read-only aggregate view, but omits whether the bot must be registered, whether network defaults matter, or any rate/permission constraints.

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; the currency list is informative rather than redundant. It is appropriately sized, though it spends its one clause on return contents rather than on the required parameter.

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 annotations, no output schema, and 0% parameter coverage, the description should explain the required 'bot' argument and the network default. Instead it covers only the return composition, leaving gaps that could cause mis-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 description coverage is 0%, so the description must compensate, yet it never mentions the required 'bot' parameter or the 'network' enum (base/base-sepolia). The only indirect link is 'agent wallet', leaving the required identifier semantics unexplained.

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 gives a specific verb and resource: it returns the on-chain USDC balance of the agent wallet plus Agent Ledger balances in three named currencies. It implicitly separates itself from sibling chain_address_balance by scoping to the agent wallet, but never names siblings to make the distinction explicit.

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 when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as chain_address_balance or ledger_stats despite several balance-related siblings existing. The agent must infer the selection criteria itself.

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 safe-read profile is covered elsewhere. The description adds value by disclosing the conditional behavior (address yields that address's link) and the fields of the programme status, but says nothing about auth requirements, rate limits, or failure modes for an invalid/off-chain address.

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 dense sentence, front-loading the always-available programme status before the conditional address-dependent link. No filler sentences and no wasted clauses.

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 must describe return values, and it does enumerate the key programme-status fields (contract, limits, live) plus the invite link. However it leaves the link's format, the meaning of the status fields, and the address-format requirement unexplained, so it is adequate but not complete.

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 parameter's meaning. It partially does: it tells the agent the value must be a Shard0 address and implies the parameter is optional (programme status is returned regardless). It does not specify address format or encoding, so the gap is only partly closed.

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 resource (invite programme) and enumerates what it returns: programme status carried by the fields contract, limits, and live, plus a per-address invite link. The verb is implicit ('info'/'status') but the effect is unambiguous, and no sibling tool competes for this niche.

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 or when-not-to-use guidance. The description implies you call it to inspect invite-programme state or retrieve a specific address's invite link, but it never states conditions, prerequisites, or alternatives among the many sibling tools.

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 safe-read profile is covered. The description usefully discloses what the record contains (status, problems, wallets) and that the book carries WSCDO/USDC/test-USDC balances and entries, but says nothing about auth, rate limits, or error behavior.

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: the primary record first, then the optional book. Parentheticals are dense but every clause adds content; no wasted filler.

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 takes on return-value disclosure and does list the record's fields (status, problems, wallets) and book contents. It leaves the address format and the meaning of 'problems' unstated, but is largely sufficient for a simple read tool.

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 conveys that the book is optional (mapping to includeBook), but 'address' is never explained and the 'optionally' phrasing is loose given includeBook defaults to true.

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 identifies a specific resource — one agent's Agent Ledger record — and enumerates its contents (status, problems, wallets) plus the optional book. The singular 'One agent's' implicitly distinguishes it from the plural sibling ledger_list_agents, but it never names that sibling or states a verb 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 implied by the singular framing ('One agent's') and the required address, suggesting a single-agent lookup versus the list variant. However, there is no explicit when-to-use, no named alternative, and no exclusions or prerequisites.

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 safety profile is covered by structured data. The description adds useful context about the backing ledger and the fields returned, but says nothing about pagination behavior, result caps, or how limit interacts with the result set.

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?

One tight sentence plus a short filtering note; the action and data scope are front-loaded and nothing is redundant. The parenthetical return-field list earns its place given there is no output schema.

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-required-parameter list tool with no output schema, the enumeration of returned fields is a good compensation. However, the absence of any pagination or result-limit semantics and the unaddressed onlineOnly filter leave the agent guessing about defaults and scope.

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, yet it only accounts for two of the four parameters (platform, operator). 'limit' and 'onlineOnly' — the latter a meaningful behavioral filter — are never explained in either the schema or 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?

States a specific verb and resource ('List agents on the SCDO Agent Ledger') and enumerates the returned fields, so the agent knows exactly what this produces. The list-versus-single distinction from the sibling ledger_get_agent is implicit rather than spelled out, so it stops short of 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?

The sentence 'Filter by platform or operator address' implies the filtering use case, but there is no explicit when-to-use, no mention of when not to use it, and no named alternative (ledger_get_agent, ledger_stats). Usage is inferable but not guided.

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 safety profile is covered externally. The description adds that the returned documents concern the Agent Ledger and the main SCDO agent (services, endpoints), which is useful scoping, but says nothing about result shape, size, or what 'SCDO agent' refers to given there is no output 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?

A single compact sentence with no filler or redundancy. It is front-loaded and efficient, though the heavy jargon (ERC-8004, SCDO) makes it slightly opaque rather than maximally clear.

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 no-argument, read-only tool with no output schema, the description carries the burden of describing the return. It gestures at content (registration documents, services, endpoints) but does not explain structure, so an agent knows roughly what it gets but not the shape or how to use the 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?

The tool takes zero parameters, so the schema needs no elaboration and the baseline of 4 applies. Nothing in the description is required to clarify 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?

The description names a concrete resource (ERC-8004 registration documents of the Agent Ledger and the main SCDO agent) and hints at content (services, endpoints), so an agent can infer it is a lookup of registration metadata. However, it is a verbless noun phrase and does not distinguish itself from sibling ledger tools such as ledger_get_agent or register_agent, leaving the exact action ambiguous.

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 when-to-use guidance, no prerequisites, and no mention of alternatives despite several adjacent ledger tools (ledger_stats, ledger_list_agents, ledger_get_agent) and register_agent. The agent must infer the trigger condition 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful content context by enumerating the metrics returned, but says nothing about freshness, snapshot timing, or whether health figures are live — relevant given the openWorldHint.

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; the resource leads and the returned metrics follow in a tight list. Every clause carries information.

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 usefully declares the four metric groups an agent will receive, which is enough to decide whether to call it. It stops short of describing response shape or timing, but for a zero-parameter read-only stats endpoint this is largely sufficient.

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 nothing to disambiguate and the schema is trivially complete. Baseline 4 applies for a no-argument tool.

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 names a specific resource (Agent Ledger) and enumerates exactly what is aggregated: registered agents, online-now count, per-platform counts, and service health. That verb-less noun phrase still clearly separates an aggregate-stats tool from siblings like ledger_list_agents and ledger_get_agent, though it never says so 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 when-to-use guidance, no precondition, and no mention of the sibling tools an agent might pick instead. The agent must infer that this is the dashboard-style summary versus the per-agent lookups.

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?

With no annotations, the description carries real weight: it discloses that gas is borne by the facilitator, that payment uses an EIP-3009 authorization, and that spend is bounded by maxUsdc and caps (i.e., the call can be rejected on price). It omits the irreversible nature of the spend and error/failure behavior, keeping it from a 5.

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?

Three short sentences, front-loaded with the action and mechanism, then the cost/gas detail, then the cap constraint. Every sentence earns its place with no filler.

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 payment tool with no annotations and no output schema, the description adequately covers the mechanism and spend constraints, and the absent output schema means return values need not be explained. However, it leaves three of four parameters undefined and says nothing about failure/rollback behavior, so it is only minimally sufficient.

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%, so the description must document all four parameters, but it only gives meaning to maxUsdc (a spending ceiling the previewed price must fall within). The required 'bot' and 'url' and the 'network' enum (base/base-sepolia) are left entirely unexplained.

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 ('Pay an HTTP 402 (x402) resource from the agent wallet') and adds the mechanism (EIP-3009 authorization), which clearly separates it from read-only x402 siblings like x402_catalog and x402_quote. It stops short of naming those siblings to actively differentiate, so it lands at 4 rather than 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?

'The price is previewed first' implies a two-step quote-then-pay flow, which is usable context, but it never names x402_quote explicitly nor states when not to call this tool or what preconditions (wallet funded, prior quote) must hold. Usage is implied rather than spelled 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?

With no annotations, the description carries the full burden, and it does disclose real side effects: a key is generated and stored in the local data dir, and signed heartbeats begin flowing to the Agent Ledger. It omits whether a second call overwrites an existing identity, whether heartbeats can be suppressed, and what authorization the Agent Ledger requires. Useful but incomplete for a state-mutating identity tool.

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 tight sentences with the core action front-loaded and the key-storage fact appended as a secondary clause. No filler, no repetition of the title.

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?

Without annotations, an output schema, or any parameter documentation, the description is the only information source, and it leaves the four parameters, the response shape, and the auth/prerequisite story uncovered. For a tool that creates persistent identity and network heartbeats, that is thin.

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 explain all four parameters and does not. 'name' is implied by the identity concept and 'heartbeats' loosely maps to 'start signed heartbeats', but 'label' and 'payout' are never mentioned, leaving payout semantics (an address? a percentage?) entirely undefined.

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 concrete verb and resource: create (or reuse) a local SCDO agent identity and start signed heartbeats to the Agent Ledger. That is specific enough to separate it from read-only siblings like ledger_list_agents or ledger_get_agent. It does not, however, distinguish itself from the similarly named ledger_registration sibling, which an agent could easily confuse it with.

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, when-not-to-use, or prerequisite guidance. The parenthetical 'or reuse' hints at idempotency but never says when a caller should register a new agent versus querying an existing one via ledger_get_agent/ledger_list_agents, nor how it relates to ledger_registration.

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 carry readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, non-mutating external read. The description adds that the commit is 'fresh' (not a cached/reused value), 'free', and demo-scoped, which is useful beyond the annotations. It says nothing about rate limits, commit lifetime, or whether the commit is bound to a later call, so it does not earn higher.

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 sentence with no filler, front-loaded with the verb and the artifact produced. Every clause ('fresh', 'provably-fair', 'free', 'Stake Wheel demo') adds discriminating information.

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-only, free demo endpoint with no output schema, the description is nearly sufficient: it names the returned fields and the surface. The one real gap is the lifecycle — how long the commit stays valid and which sibling call verifies or reveals it, which an agent needs to chain calls 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?

The tool takes zero parameters, so the baseline of 4 applies; there is no parameter semantics for the description to add or omit. The description's mention of return fields is not a substitute for parameter documentation but is not needed here.

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 ('Get'), a specific resource ('a fresh provably-fair commit'), and names both returned fields (commit_id and server seed hash). The phrase 'server seed hash' precisely distinguishes the commit phase from a seed reveal, so an agent knows exactly what artifact it receives. None of the listed siblings overlap with this capability, so no ambiguity is possible.

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?

'for the free Stake Wheel demo' gives implied context for when this tool applies, and 'free' signals no payment path is required. However, it never states when not to use it, what follow-up call consumes the commit (e.g., a reveal or spin endpoint), or whether the commit expires, leaving the workflow to inference.

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 safety and network profile is covered. The description adds that results include version, URL and SHA-256, which is useful return context, but says nothing about freshness guarantees, caching, or failure behavior for the 'Latest' claim.

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 — it states the resource, platform coverage, and returned fields in one pass. Every clause earns its place.

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 partially compensates by naming the returned fields (version, URL, SHA-256). It could say more about whether checksums are per-artifact or what the platform breakdown looks like, but for a simple static listing it is close to sufficient.

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 no parameters, so there is no parameter semantics to convey; the description correctly avoids inventing any. Baseline for zero-param tools applies.

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

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

Names a specific resource (SCDO Wallet downloads) and enumerates the covered platforms (Windows, Mac, Linux scdo-agent) plus the data fields returned. This is clearly distinguishable from siblings like create_wallet, though it doesn't explicitly name an alternative since none exists for download retrieval.

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 purpose implies when to use it — fetching current wallet binaries — but there is no explicit when-to-use/when-not-to-use guidance, prerequisites, or mention of related siblings. For a zero-parameter lookup the intent is self-evident, so this is adequate but thin.

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 agent knows this is a safe, open-world read. The description adds that it exposes pay-to wallets and pay URLs, but says nothing about rate limits, auth needs, caching, or result shape. Modest added value over 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?

A single sentence with the resource front-loaded and the two network values explained after a colon. No filler, though it is short enough that it could have carried one more routing hint at no cost.

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?

There is no output schema, so the description must convey returns, and it does name the returned content (wallets and their pay URLs). Combined with readOnly/openWorld annotations, it is largely sufficient for a simple one-param lookup, with only 'when to use it' and the default value 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 description coverage is 0%, so the description must carry the parameter meaning, and it does: base = USDC on Base, scdo = native SCDO on Shard0. This gives the agent real semantics for both enum values beyond the bare names, though it omits that base is the default.

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 resource ('Catalog of SCDO x402 pay-to wallets and their pay URLs'), which is distinguishable from siblings like x402_quote and x402_relay_status. It does not explicitly name what it is not, but the wallet/pay-URL scope is clear enough for an agent to select it.

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 never states when to call this tool or what alternatives exist (e.g., vs x402_quote or pay_x402). Usage is only implied by the noun 'catalog'. No prerequisites or context for use are given.

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 safety profile and outbound-network nature are known. The description usefully adds that no payment is made, but says nothing about auth requirements, rate limits, or error behavior when the URL is not 402-protected.

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?

One front-loaded sentence with zero filler; the verb, resource, returned fields, and the key non-side-effect are all packed in 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?

With no output schema, the description compensates by naming the returned fields (price, asset, network, payTo), which is enough for an agent to use the result. A brief note on failure modes for non-402 URLs would make it complete.

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 single url parameter has 0% schema description coverage, so the description carries the burden; it does clarify that the url is an x402-protected resource to quote. However, it adds no format or validity constraints beyond that bare characterization.

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 (Fetch) and resource (HTTP 402 payment requirements of an x402 URL), and the phrase 'without paying' immediately separates it from the sibling pay_x402. An agent can tell this is the read-only price-discovery step without opening any schema.

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?

'without paying' implies the intended use case (inspect requirements before committing funds), which is clear context for choosing this over pay_x402. It stops short of an explicit 'use this before calling pay_x402' routing statement, so it is not a full 5.

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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is already covered. The description adds the relay's identity and the content returned, but does not disclose rate limits, auth requirements, or polling behavior.

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?

Single sentence, front-loaded with the resource and returned fields, and contains no wasted words.

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-argument read-only status endpoint with no output schema and minimal annotations, the description identifies the endpoint and the returned information. It is largely complete, though it does not clarify response format or frequency limits.

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 baseline 4 applies. Schema description coverage is 100% but there are no parameters to document, and the description adds no parameter semantics because none exist.

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 the specific resource (SCDO x402 Base settlement relay) and the information returned (health and supported schemes). It is a clear noun-phrase purpose but does not explicitly differentiate from siblings like x402_quote or pay_x402.

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?

No when-to-use or when-not-to-use guidance is provided. The description implies the tool is for checking relay health and supported schemes, but does not mention alternatives or prerequisites.

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