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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful domain context (gas is billed on the gas limit, MON is required to transact) and the default-wallet behavior, but says nothing about failure modes for a malformed address, response shape, or rate limits.

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

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

Front-loaded with the core action and resource in the first sentence, so an agent gets the gist immediately. The trailing gas-billing aside is somewhat tangential for a read tool, but it is short and operationally relevant rather than 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 2-parameter read-only tool with no output schema, the description covers what is returned (USDC, MON, parked USDC) and the default target wallet, which is what an agent needs to call it correctly. Only minor gaps remain around result formatting and chain/address handling.

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

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

Schema coverage is 100% with detailed patterns and descriptions for both parameters, so the baseline is 3. The description reinforces the default-wallet behavior and hints that the returned 'parked USDC' relates to the agentId/ERC-8004 identity, but adds no new syntax or formatting detail beyond the schema.

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

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

States a specific verb and resource (read a wallet's USDC and MON balances) and adds scope detail the name alone doesn't carry: default server wallet, plus USDC parked for withdrawal. It is clearly distinguishable from siblings like get_pending_actions or get_bounty, which retrieve different resources.

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 rather than stated: the gas explanation tells the agent why balances matter ('a wallet with USDC but no MON cannot send any transaction'). There is no explicit when-to-use or when-not-to-use rule, and no named alternative tool for cases like checking another agent's balance history.

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

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

Goes beyond the annotations by disclosing that the private key stays in-process and is never pinned or sent to an RPC, and by advising the use of a contest-specific key — non-obvious security behavior for a decryption call. It also notes the ciphertext is fetched from IPFS when entryCid is used, adding operational context the readOnlyHint/openWorldHint flags do not convey.

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

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

Two sentences with zero padding; the core action and input choice come first, with the security caveat front-loaded at the end of the second sentence. 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?

For a read-only, nested-schema decryption tool with no output schema, the description covers the input alternatives, the key-handling model, and the IPFS fetch path. It does not hint at the return value (plaintext entry), but annotations cover the safety profile and the schema is fully documented, so the gap is minor.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds the either/or semantics between entry and entryCid that the schema alone leaves ambiguous (both are optional with additionalProperties false). It does not elaborate on the publicKey/privateKey pairing beyond the schema text, which is already explicit.

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

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

States a specific verb+resource ('Decrypt a contest entry') plus the cryptographic context ('with the poster key pair'), clearly distinguishing it from the sibling encrypt_contest_entry. An agent knows exactly what operation this performs without opening the 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?

Explains the two mutually exclusive input paths ('Give either entryCid... or the envelope itself') and cross-references get_contest for where the CID comes from, which is genuine routing guidance. It stops short of stating when not to use the tool, but the context is clear.

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 destructiveHint=false, so the safety profile is covered; the description adds genuinely new behavior: encryption happens locally, the plaintext never leaves the process, and only the envelope is safe to pin. It does not describe determinism or error behavior for a malformed key.

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 output, followed by the pinning rule and the one-step alternative. 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 two-parameter local transform with no output schema, the description covers what is produced (an envelope) and how it may be used, which is sufficient. It lacks any note on envelope format or failure modes for an invalid public key, which would round it out.

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 100%, with both parameters documented including the base64url pattern, so the baseline is 3. The description reinforces locality for the plaintext but adds no format or source detail beyond what the schema already states.

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 (seal/encrypt), the resource (plaintext contest answer), the key used (poster public key), and the output (encrypted envelope). It is clearly distinguishable from siblings like decrypt_contest_entry and enter_contest.

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?

Names an alternative path ('enter_contest with content does all of this in one step') and a hard rule about what may be pinned, so the agent knows both the shortcut and the constraint. It stops short of stating explicit when-not conditions beyond that routing 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?

The description carries the full behavioral burden for an unannotated-rich operation: it discloses that the private key is returned in this result and must be stored immediately, that losing it makes entries permanently unreadable, and that entries on IPFS cannot be retracted. That is critical, non-obvious context beyond what readOnlyHint/destructiveHint provide.

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 what is produced, then the publish/keep instruction, then the save-now warning. 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?

There is no output schema, so the description must explain the return — and it does, naming both publicKey and privateKey and warning that the private key is shown here. An agent has everything needed to call and act on the result 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 input parameters, so there is nothing to document and the baseline is 4. The description's mention of publicKey/privateKey concerns output fields rather than input, which is not a parameter-semantics 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?

The description states a specific verb and resource ("Generate a fresh X25519 key pair") plus the purpose ("for running a contest"). It is clearly distinguishable from siblings like encrypt_contest_entry / decrypt_contest_entry and get_identity, which cover different key/entry operations.

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

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

It establishes the operating context — generate this before running a contest, publish the publicKey as post_bounty contestPublicKey — which is clear usage guidance. It does not, however, explicitly state when to use this versus alternatives such as get_identity for existing keys, nor any exclusions.

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 (readOnly, idempotent, openWorld, non-destructive), so the bar is lower, yet the description adds real behavioral context: it discloses that mirrored Base/Arc data is relayed rather than trustless and that history is adapter-local, which materially affects how much the caller should trust the result. It still says nothing about failure behavior for an unknown agentId.

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 dense sentence enumerating the returned components, followed by a short provenance caveat that earns its place. Front-loaded with the resource and 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?

With no output schema, the description correctly carries the burden of listing what is returned, and it adds the trust caveat about mirrored data. The only gaps are edge behavior (unknown agentId, empty history) and any differentiation from the sibling reputation 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?

There is a single parameter and schema description coverage is 100%, so the schema already fully documents agentId (pattern, decimal integer, example '48'). The description adds no syntax or format detail beyond that, which is the expected baseline when the schema does the work.

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 ('Get the full reputation picture of an ERC-8004 identity') and enumerates the concrete components returned, so the agent knows exactly what this retrieves. However, it never distinguishes itself from the sibling 'get_identity_reputation', which sounds like it covers similar ground, leaving the agent to guess which to call.

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

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

Usage is only implied: the caller supplies an agentId and receives reputation data. There is no explicit when-to-use statement, no exclusions, and no routing away from the similarly named 'get_identity_reputation' sibling.

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?

The annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), so the bar is lower, yet the description still adds real behavior: a *derived* status field, and conditional retrieval of submission text 'for a submitted single-taker job'. It omits any note on failure modes or auth, and the IPFS latency caveat lives in the schema rather than here.

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 that front-loads the core action ('Get one bounty in full') and then attaches the return content and the workflow pointer. No filler, no restatement of the tool name or the 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?

There is no output schema, so the description must characterize returns, and it does so well by enumerating on-chain fields, derived status, and IPFS-fetched content. Missing only edge-case behavior (missing id, unreachable IPFS), which is a minor gap for a two-parameter 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 100%, so both jobId and includeContent are fully documented in the schema itself, including the default and the IPFS-latency warning. The description's 'by default' phrasing adds nothing beyond the schema's documented default, so the baseline 3 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?

The description names a specific verb and resource ('Get one bounty in full') and enumerates exactly what comes back: on-chain fields, a derived status, the description, and delivered work from IPFS. The 'one bounty' framing plus the mention of approve_bounty cleanly separates it from the list-style siblings (list_open_bounties, get_my_bounties) and from get_contest.

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

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

It gives a concrete workflow cue: 'Review a delivery here before approve_bounty', which tells the agent this is the verification step preceding approval. It does not state exclusions (e.g., use get_contest for contests, use list_open_bounties to discover ids), but the context is clear enough to place the tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds meaningful context beyond that: entries are encrypted, viewing them requires the poster's private key, and entries include encrypted CIDs plus sender info. That is real behavioral value.

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

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

A single efficient sentence that front-loads the action and then lists the meaningful return contents. No filler, though the trailing access-restriction clause is slightly tacked on.

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, one-parameter tool with an annotation-declared safety profile, the description covers what state is returned and the key access constraint. Without an output schema the field list is helpful, though it stops short of explaining null/empty states or error conditions.

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

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

Schema coverage is 100% and the jobId description already tells the agent the pattern, format, and how to find ids via list_open_bounties/get_my_bounties. The description adds nothing about jobId, so the baseline 3 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?

States a specific verb and resource ('Get the state of an encrypted contest') and enumerates the returned fields (entry count, close time, review deadline, entries, challenges). This clearly distinguishes it from siblings like get_bounty or decrypt_contest_entry.

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 notes that 'Only the poster holding the private key can read entries,' which implies who should use it, but it doesn't name alternatives or say when not to use it. No sibling routing like get_bounty vs get_contest.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuine context beyond that: the owner-vs-working-wallet distinction (payouts and reputation accrue to the owner) and the error behavior when the id is unknown.

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 verb and resource, then the semantic distinction, then the failure mode. Every sentence carries information an agent needs.

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 carries the burden of describing returns, and it names the two meaningful fields plus the failure case. It stops short of enumerating any other identity fields (e.g. metadata or URIs) an agent might receive, so it is strong but not exhaustive.

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

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

Schema coverage is 100% and the single agentId parameter is fully documented with a pattern and example. The description only restates the parameter name in parentheses, adding no format or constraint detail beyond the schema, so the baseline 3 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?

States a specific verb (Get) and resource (ERC-8004 identity) and names exactly what is returned: the owner and working wallet. It implicitly separates itself from siblings like get_identity_reputation or balances by scoping the payload, but never names an alternative tool 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 payload description (call it when you need to know who owns an agent or which wallet operates it), and the failure condition 'Fails if the id does not exist' gives a useful boundary hint. There is no explicit when-to-use/when-not guidance and no routing to 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 readOnly/idempotent/non-destructive/open-world, so the safety profile is covered. The description adds real behavioral context beyond that: results aggregate this adapter plus mirrored Base and Arc history, and the exposed numbers are the exact quantities the reputation gates consume rather than a derived display score.

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 tight sentences with no filler; the core purpose is front-loaded and the special-case routing instruction comes last where it belongs. Slightly dense phrasing ('exact score sum that reputation gates use') but still economical.

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 carries the return-value burden and does so reasonably: it specifies the three outputs (paid jobs, score sum, average) and the cross-chain aggregation scope. The remaining gap is the unresolved overlap with get_agent_reputation, which an agent cannot settle from this text.

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

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

With 100% schema description coverage, the schema already documents both agentId and humanWallet including the agentId=0 rule and formats. The description only restates the human/agentId-0 case without adding syntax or constraints, so the baseline of 3 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?

The description names a specific verb and resource and pins down exactly what is returned: the paid jobs, the exact score sum behind the minJobs/minAvgScore gates, and the average. It is clear on its own, but it never distinguishes itself from the sibling 'get_agent_reputation', which sounds like it could return the same thing.

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

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

It gives one concrete routing rule (use agentId 0 with a wallet for a human with no identity), which is genuine when-to-use guidance. However, it offers no guidance on when to prefer this over get_agent_reputation or get_identity, which is the most likely source of misselection given the sibling list.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered. The description adds useful behavior beyond that: results are newest first, they carry status/reward/deadline, and the lookup defaults to the server wallet (required on a read-only server). No contradictions.

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

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

Two sentences, front-loaded with what is listed and how it is ordered, then the wallet-targeting rule. Every clause 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 read-only listing tool with full schema coverage and no output schema, the description supplies the missing return-value context (status, reward, deadline, newest first) and the default-target rule. An agent has everything needed to call and interpret it.

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 100%, so role, limit and address are already fully documented with enum values, defaults and the address pattern. The description restates the posted/took-or-entered split but adds no syntax or semantics beyond the schema, which is the baseline 3 case.

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 (list) plus resource (bounties) and narrows the scope to bounties a wallet posted, took or entered, with returned fields (status, reward, deadline) and ordering. This clearly separates it from siblings like list_open_bounties (all open bounties) and get_bounty (single bounty).

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?

Tells the agent the default target (this server wallet) and the alternative path (pass address for another wallet), which is the key routing decision. It stops short of explicitly naming competing tools or stating when not to use this one, so it is clear context without exclusions.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds substantive behavior: the two action kinds, the 48-hour deadline risk, and that each item carries a follow-up tool name. It does not cover result shape, count, or pagination limits.

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

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

Two tightly written sentences: the capability and its two action kinds come first, then the urgency rationale. No filler, no repetition of the schema, and the actionable warning is front-loaded rather than buried.

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 does describe what comes back (settlements and decisions, each with the tool to call), which is the key thing an agent needs. Minor gaps remain around volume, ordering, and what an empty result means, but the core is 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 coverage is 100%, so address, agentId and maxJobs are fully documented in the schema. The description only gestures at "a wallet or identity", adding no format, defaults, or scoping detail beyond the schema, so the baseline 3 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?

States a specific verb (List) and resource (pending actions on a wallet's/identity's bounties), and disambiguates the content into two named kinds (claim settlements, respond decisions). This clearly separates it from siblings like list_open_bounties and get_my_bounties, which list bounties rather than actionable items.

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?

"Check it regularly" plus the concrete consequence (missing a 48-hour window can lose a dispute by default) tells the agent when and why to invoke it. It also implies the next hop ("each with the tool to call"), but it does not explicitly name an alternative sibling or a when-not condition, so it falls short of a 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?

The annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds useful context beyond that: newest-first ordering within a page, and the payload contents (reward, deadline, gates, description CID). It does not mention whether a total count or end-of-list signal is returned, which is a minor gap.

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 plus a short usage clause; the what, the ordering, the returned fields and the paging mechanism are all front-loaded 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 read-only list tool with no output schema, the description usefully enumerates the returned fields (reward, deadline, gates, CID) and ordering, which is what an agent needs to consume the result. Only the absence of any end-of-list/pagination-completeness hint keeps it from the top.

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 100%, so limit, offset and category are all fully documented in the schema and the baseline is 3. The description only echoes the paging idea ('page with offset') and adds no format or edge-case detail beyond the schema.

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

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

States a specific verb and resource ('List open NadBounty jobs that can still be taken or entered') plus the ordering and the fields returned, so the agent knows exactly what comes back. It implicitly distinguishes itself from get_my_bounties by scoping to open/public work, but never names a sibling explicitly, which keeps it 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?

'Use it to find work or to survey the market' gives clear intent-based context for when this tool applies, and 'page with offset' tells the agent how to iterate. There is no explicit when-not guidance or named alternative (e.g. get_my_bounties for the agent's own posts), so it stops short of the top band.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond them: the 'call it first' ordering convention, the gas/reward denomination ('Gas is paid in MON, rewards in 6-decimal USDC'), and the live pause state. It doesn't cover pagination or refresh semantics, but for a config readout that is minor.

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 tight sentences, front-loaded with what is shown and immediately followed by the call-first instruction. The units sentence is slightly tangential but earns its place by clarifying returned values.

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 enumerating the fields returned (network, contracts, signing mode, caps, board settings) and their units. That is close to complete for a zero-parameter, side-effect-free config tool; only the response shape's exact structure is left unstated.

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. The description correctly implies a no-argument readout and adds unit semantics (MON, 6-decimal USDC) that contextualize the values returned.

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 (Show) and enumerates the exact resource contents: network, contracts, signing mode, spend caps, board settings including paused, maximum reward, fee. An agent knows precisely what this returns. It doesn't explicitly distinguish itself from siblings like balances or get_identity, which is the only gap.

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 directive 'Call it first' gives explicit ordering guidance that is unusually actionable. There is no stated when-not-to-use or named alternative, so it stops short of a 5.

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