agentpay — card-funded wallets for AI agents

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 does add useful behavioral context: the reward is credited on settle and the response includes payout instructions, which hints at a state-changing, wallet-bound operation. However it doesn't state auth/permission requirements, whether claiming is idempotent or reversible, or what happens if the wallet is mismatched.

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 the core action and then the wallet-binding consequence. No wasted filler; flows from action to effect to identity requirement.

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?

Adequate: with 100% schema coverage and no output schema, the main gaps are where it sits in the bounty lifecycle (claim -> submit_work -> settle) and permission requirements. The description covers action, outcome, and a key optional param but leaves lifecycle context 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 coverage is 100%, so the schema already documents all five parameters including identity binding. The description's mention of workerAccount/workerPubKey as 'BSV identity' to 'bind trust' adds semantic color beyond the schema, but not enough to exceed the baseline 3.

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?

Clear specific verb+resource ('Claim a bounty') and it explicitly states the side effect — linking the bounty to the agentpay wallet so the reward is credited on settle. This distinguishes it from siblings like get_bounty (read) and settle_bounty (settlement).

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 implies usage context (you claim bounties found via list_bounties, and the wallet binding matters for crediting), but never states when NOT to use it or how it relates to submit_work/settle_bounty in the workflow. No explicit alternatives or preconditions named.

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 does well: it discloses the rate limit (one per IP per day), the source constraint (limited operator budget), the failure mode (403 when the faucet is disabled), and cost (free). It omits auth requirements and what the response actually contains.

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 paragraph with the core action front-loaded followed by constraints and failure conditions. Every clause earns its place; there is 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 mutation tool with no annotations and no output schema, the description covers the essential operational facts — rate limit, budget, failure code, and cost. The main gap is that it does not describe what the agent receives back (wallet address, key format), which matters since no output schema exists.

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 the single optional 'name' parameter is already documented. The description adds no syntax or format guidance beyond the schema, 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?

The description states a specific verb and resource — minting a pre-funded trial wallet plus a tight agent key — and frames it as self-serve onboarding. This distinguishes it from siblings like claim_bounty (bounties) and create_topup_link (funding), so an agent can route correctly without opening schemas.

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

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

It gives implied usage context ('self-serve onboarding', 'no human or card needed') and a hard limit (one per IP per day), but never names an alternative or states when not to use it versus onboard or claim_bounty. The routing decision is left 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?

With no annotations, the description carries the full burden. It discloses that the action creates a Stripe Checkout URL, requires human action, and enforces an amount range of 100–100000 cents. It does not state auth requirements, URL expiry, or return format, but the core behavior is reasonably transparent for a simple creation 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?

The description is a single, front-loaded sentence with no filler. It conveys the action, the payment provider, the user's role, and the amount constraint 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?

For a low-complexity tool with no output schema, the description covers the key facts an agent needs: what is created, who uses it, and the valid amount range. It could explicitly state that the URL is returned, but 'Create a ... URL' strongly implies that outcome, 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%, but the description adds meaningful constraints beyond the schema by specifying an exact allowed amount range (100–100000 cents) and clarifying the purpose of the amount. The schema only gives broad integer limits, so the description materially improves parameter understanding.

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 action ('Create a Stripe Checkout URL') tied to a clear resource (funding the wallet). It also adds the payment mechanism and currency, making the tool's role unambiguous and distinguishing it from siblings like pay_service or spend.

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 clearly conveys when to use the tool: when a human needs a checkout link to fund the wallet. It does not explicitly mention alternatives or say when not to use it, but the intended context is evident from the wording.

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. It transparently states that the tool creates a Stripe Checkout URL rather than directly performing the upgrade, and it specifies what to do with the result. It could add more about auth or side effects, but the main behavior is clear.

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, each earning its place: the first states the action, target, and benefits; the second states the intended recipient of the URL. There is no filler or redundancy.

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 tool with one optional parameter and no output schema, the description is nearly complete: it conveys the action, the artifact type, and the follow-up action. It does not explicitly describe the response shape, but 'Hand the URL...' implies the URL is returned.

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% for the only parameter (key), so the schema already explains it. The description adds no additional meaning about the key or when to supply it, so a baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Create') and names a concrete resource ('Stripe Checkout URL') with a clear outcome ('upgrade the wallet to agentpay Pro'). It also lists the benefits, which distinguishes it from sibling tools like create_topup_link.

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 clearly states the target use case: generating a checkout URL to upgrade to agentpay Pro. It also instructs the agent to hand the URL to the wallet owner. It does not explicitly name alternatives or exclusions, but the intended context is evident.

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 full behavioral burden. It usefully discloses that the result is agentpay-signed, enumerates the summarized activity, notes it is 'Free', and that sub binding affects bond discount. It omits auth requirements (key/Bearer interplay), whether the signature is revocable, and what the signed output actually is.

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, front-loaded with the core action and scope, followed by the parameter caveat and cost. No 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?

With no output schema and no annotations, the description should explain the return shape, but it never says what a signed attestation looks like or how auth is handled. It covers what is summarized well but leaves the output and auth story incomplete for a signing 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 baseline is 3, but the description adds meaning beyond the schema by tying sub to a business consequence ('required for bond discount') and framing days as a 'window'. key and days remain schema-only, so it does not fully elaborate every parameter.

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 ('sign a summary') and resource (this wallet's settled activity), and enumerates the included dimensions (payments, services/payees, spend, refunds, bounty earnings), which no sibling like get_receipt or list_transactions does. An agent can tell this is a signed aggregate attestation, distinct from a raw receipt or transaction list.

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 conditional rule — pass sub to bind to a bounty claim, required for bond discount — which is useful usage context. However, it never states when to prefer this over get_receipt or list_transactions, nor any exclusions, so the guidance is only partial and 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?

There are no annotations, so the description carries the behavioral disclosure burden. It names the returned data, but it does not explicitly state that the operation is read-only, how authentication is handled, or what happens on error or when limits are exceeded.

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 compact sentence with no filler; the key scope and all three returned categories are front-loaded and relevant.

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 getter with one optional parameter and no output schema, the description adequately lists the returned categories and scope. It could be more precise about the format of the daily limit status and identity, but nothing essential is missing for selecting and invoking 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?

The single optional key parameter is fully described in the schema, including the agp_ prefix and the Authorization header alternative. The description adds only the 'current agent key' context, which is marginal 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?

The description specifies exactly what the tool returns—wallet balance, agent identity, and daily limit status—and scopes it to the current agent key. This makes its purpose immediately clear and distinguishes it from transaction, spending, and payment sibling tools.

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 intended use is implied: call it when you need the current agent's balance, identity, or daily limit status. However, it does not explicitly state when to prefer it over alternatives or mention 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?

With no annotations, the description carries the full burden. It discloses the returned content (requirements, amount, acceptance spec, status, escrow state), which is useful behavioral context, but says nothing about read-only nature, auth requirements, or behavior when the id does not exist.

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 names the resource first and then enumerates the payload. No filler or redundant 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?

For a one-parameter lookup with no output schema, the description usefully outlines the returned fields, which is exactly what an agent needs to judge relevance. It is close to complete, with only error/lookup-miss behavior 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?

Schema description coverage is 100% and the single bountyId parameter is already documented as coming from list_bounties. The description adds no syntax, format, or constraint details beyond what the schema provides, 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 ('one BSVBounties listing') with the scope of detail enumerated. It implicitly distinguishes itself from list_bounties by emphasizing 'one' and 'Full detail', though it does not name that sibling 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 explicit when-to-use statement or named alternative. The only routing hint is the parameter description 'Bounty id from list_bounties', which implies a list-then-detail workflow but leaves the agent to infer it.

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. 'Fetch' implies a read-only operation, but the description does not disclose behavior for missing receipts, error cases, response format, or authentication requirements.

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. Every word contributes to stating the operation and its core identifier.

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 id-based fetch with only two parameters, the description is minimally adequate when combined with the schema. However, with no annotations and no output schema, the lack of return/error/authorization context leaves meaningful gaps for an agent deciding whether the call succeeded or how to handle failures.

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 phrase 'by id' reinforces that receiptId is the lookup key, adding a small amount of meaning to that otherwise undocumented parameter. The optional key parameter is already described in the schema, so the description partially compensates for the 50% schema coverage but adds no new detail about formats or constraints.

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

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

The description uses a specific verb ('Fetch') and a distinct resource ('receipt') with an id-based lookup, which clearly separates it from broader sibling operations like list_transactions. It does not explicitly name an alternative, so it falls just short of full sibling 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?

No guidance is given about when to call this tool versus siblings such as list_transactions or service_quote. There is no mention of prerequisites, such as obtaining a receiptId from a prior transaction.

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 present, so the description carries the behavioral burden. It transparently indicates a read-only health check, but does not disclose what response is returned, what 'up' means, or how failures are signaled. This is acceptable for a minimal zero-parameter tool, but lacks depth.

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, directly front-loaded sentence with no filler. Every word contributes to conveying the tool's function.

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, no-output-schema health check, the description is mostly complete: it states what is checked and implies a boolean/status result. The only missing piece is the exact response format or status semantics, but the tool's simplicity makes this a minor 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?

The tool has no parameters and schema coverage is 100%, so there is no parameter-level information the description needs to add. The baseline of 4 is appropriate because the schema fully covers the input side.

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 ('Check') and a precise resource ('agentpay API and MCP'), making the tool's purpose immediately clear. It is easily distinguished from the sibling payment-focused tools.

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 intended use—verifying that the API and MCP are operational—is clear from the description. It does not explicitly mention alternatives or exclusions, but the sibling tools are clearly different operations, so the context is sufficient.

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 behavioral burden. It usefully discloses pricing/auth ('free', 'no key required') and implies a read-only browse, but says nothing about pagination behavior, result shape, or rate limits, leaving notable gaps for a list endpoint.

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 plus a short fragment, front-loaded with the core action, with zero filler. Efficient, though the trailing em-dash fragment is slightly informal rather than structural.

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 four-parameter listing tool with no annotations and no output schema, the description covers the what and the auth/cost angle but omits pagination guidance and any hint of the returned result shape, leaving it just barely adequate.

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 only 50%: status and category are documented in the schema while limit and offset are bare integers with no bounds explanation. The description adds no parameter meaning at all, so it fails to compensate for the undocumented pagination parameters.

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 verb ('browse/list') and resource ('bounties') and anchors it to the BSVBounties marketplace with domain context (sats, escrow, reputation). However, it never distinguishes itself from close siblings like get_bounty (single bounty) or my_bounties (user's own), so an agent gets a clear purpose but no routing signal.

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?

'Free — no key required' conveys a prerequisite but not when-to-use. It offers no guidance on choosing this over get_bounty or my_bounties, and no note that it returns a paginated listing versus a single record.

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 provided, the description carries the full burden of behavioral disclosure, and it does well by stating that the operation is public, requires no key, and returns specific fields (tools, network, payTo, per-tool price in sats). It implies a read-only listing operation, though it does not explicitly mention pagination 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?

Two tight sentences deliver the core purpose, auth requirement, and return fields with no filler. The most important distinguishing facts (public, no key, registry listing) are front-loaded, and every clause adds value.

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 optional-parameter listing tool with no output schema, the description is complete: it states the purpose, auth requirements, and the key return fields. The remaining details (q and limit semantics) are adequately covered by the input schema, and no critical invocation detail is missing.

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

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

Schema description coverage is only 50%, with 'limit' lacking any description and 'q' having only 'Search text'. The tool description adds no parameter-level meaning, so it does not compensate for the schema's gaps. The parameters are not mentioned at all, leaving the agent to infer their purpose from minimal schema hints.

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

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

The description uses a specific verb ('Browse') with a clear resource ('x402market registry of pay-per-call services'), which distinguishes it from sibling tools like pay_service, service_quote, and list_transactions. It also states the audience ('for agents') and the public nature of the operation.

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 clearly conveys that this is a public registry-browsing operation and that no key is needed, giving an agent a clear context for when to call it. It does not explicitly name alternatives or state when not to use it, but the discovery-focused framing is strong enough to imply the appropriate use case.

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 discloses the output fields (budget, spend, expiry, status) but does not mention that this is a read-only operation, any authentication requirements, or potential error states. The description gives some behavioral insight but not complete transparency.

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 states the core action and resource first, then lists the returned attributes. No filler or redundancy; every word contributes to the tool's purpose.

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

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

Given there is no output schema, the description adequately explains return values (budget, spend, expiry, status). It also clarifies the scope ('delegated by the current agent'). Missing pagination or error handling details are minor for a list tool of this complexity, and the parameter is covered by the schema.

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 optional 'key' parameter is already documented. The description does not add any meaning about the parameter beyond what the schema provides, and the tool's purpose (listing subagents) implies the key is rarely needed when auth is present. Baseline 3 is appropriate since schema handles the parameter semantics.

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 action ('List') on a clear resource ('child keys delegated by the current agent') and enumerates the returned data (budget, spend, expiry, status). This distinguishes it from siblings like mint_subagent or revoke_subagent, which manage subagents rather than list them.

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

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

The description implies usage for viewing subagents, but does not explicitly state when to use it over alternatives or mention exclusions. No guidance is given on when to prefer this tool vs. spend or revoke_subagent, though the sibling context makes the read-only nature obvious.

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 provided, the description carries the full burden of behavioral disclosure. It states the result is 'recent' and 'newest first', but does not disclose whether the list is paginated, whether the 'limit' parameter caps results, what event types are included/excluded, or whether this is a read-only operation. The description adds some ordering context but leaves significant behavioral gaps.

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 concise sentence that front-loads the core purpose and includes useful details (event types, ordering). It earns its place without redundancy, though it could add a brief note about pagination or limit behavior without becoming verbose.

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 list tool with no annotations and no output schema, the description is thin. An agent does not know the default limit, whether results are paginated, what fields each event contains, or whether the list is filtered by the agent key. Sibling tools like get_receipt and spend suggest a financial context where such details matter for correct invocation.

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

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

Schema description coverage is 50%: the 'key' parameter is documented in the schema, but 'limit' has no description. The tool description adds the 'newest first' ordering context but does not explain the 'limit' parameter's behavior or default. Baseline 3 is appropriate since the schema covers half the parameters and the description adds minimal semantic value beyond that.

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 ('list') and resource ('wallet ledger events') and clarifies the scope with examples ('top-ups, spends') and ordering ('newest first'). It is clear enough to distinguish from siblings like get_balance or get_receipt, though it does not explicitly name a sibling alternative.

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

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

The description implies a read-only listing use case and the 'newest first' ordering gives context, but it does not explicitly state when to use this tool versus alternatives like get_receipt or get_balance. There is no when-not-to-use guidance or mention of pagination for large result sets.

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, and it does disclose the auth profile ('Public — no key required') plus the breadth of returned data. It stops short of stating error behavior for a missing/invalid order id or explicitly confirming the operation is non-mutating.

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, front-loaded with the resource and purpose, with the auth note trailing where it belongs. 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?

With no output schema, enumerating the returned fields is genuinely useful, and the no-key note covers access. The only gap is failure behavior (unknown orderId) for a lookup tool that will commonly miss.

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% and the single orderId parameter is already documented as coming 'from market_list'. The description adds no syntax, 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?

Specific verb+resource ('Full detail for one marketplace order') that clearly distinguishes this single-order fetch from the sibling list tool market_list. The enumerated detail fields (price, escrow, fulfillment, delivery, dispute) make the scope concrete.

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 — fetch one order by id — but the description never states when to prefer this over market_list or the similarly named market_order sibling, nor any precondition such as the order needing to exist. No explicit when/when-not guidance.

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 the auth profile (public, no key), that these are escrow-held orders, and that only 'open' orders are returned. It does not disclose pagination behavior, ordering of results, or what happens at the 50-item cap.

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 zero filler; the resource scope is front-loaded and the auth note follows as a short qualifier. 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 public read-only list tool with one optional parameter and no output schema, the description covers what is returned (open escrow orders) and the access model. Only pagination/ordering details are absent, which is a minor gap given the schema already bounds the limit.

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% and the single 'limit' parameter is never mentioned in the description, so the description adds nothing about the 1-50 bound or whether it controls pagination. With one undocumented parameter, the description fails to compensate for the coverage 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?

Names a specific verb ('Browse') and a precisely scoped resource: open fixed-price P2P trade orders held in on-chain escrow, including the asset types involved. An agent can distinguish this from market_get (single order) and market_order (place an order) by the 'open orders' scope, though no sibling is named 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?

The 'Public — no key required' clause tells the agent it can call this without credentials, which is a genuine usage cue. However, there is no when-to-use/when-not guidance relative to market_get, my_escrows, or list_bounties, leaving the choice among market tools 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?

With no annotations, the description carries the full burden and delivers meaningful context: the escrow lifecycle (buyer funds directly, you deliver, buyer approves), that disputes route to Jev-advised arbitration, and a 2% platform fee on release. It does not state permission/auth requirements or rate limits, but the escrow and fee disclosure is substantial behavioral context beyond the 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 dense sentences with no filler. The core action and the escrow/fee consequences are front-loaded, and every clause (returns order + escrow address, fee) 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 mutation tool with no annotations and no output schema, the description covers the return value ('the order plus its on-chain escrow address'), the post-listing flow, and the fee. It stops short of auth/prerequisite detail, but an agent has enough to call it correctly.

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

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

Schema description coverage is 71%, so most parameters are documented in the schema itself. The description only loosely maps to parameters via 'fixed price' (priceSats) and 'digital or physical item' (fulfillment), adding no new syntax or format detail. Baseline 3 is appropriate when the schema does most of 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: 'List a digital good or physical item at a fixed price,' which tells the agent this creates a market listing/order. It is clear on its own but does not explicitly differentiate itself from siblings like market_list, market_get, or list_services, leaving the agent to infer the distinction from the name.

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 — the agent can infer this is the tool for putting an item up for sale — but there is no explicit when-to-use guidance and no mention of alternatives (e.g., market_list for browsing, market_get for retrieval). The agent must map the verb to intent unaided.

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 discloses the scoping behavior (budget, expiry, daily limit, allowlist) and that the child can spend only within these, plus revocability. However, it omits details like idempotency, failure modes, exact permission requirements beyond top-level, and what happens to existing keys. Given zero annotation coverage, a 3 is appropriate – it's not misleading but lacks depth.

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 three sentences, front-loading the core action and constraints. It has no wasted words, though it packs several ideas (scoping, permission, revocability) into a dense paragraph. Still very concise relative to the complexity.

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 tool with 7 parameters and no output schema, the description covers the main behavior and constraints but does not explain the return value. Since there is no output schema, agents may not know what to expect (e.g., the generated child key). It also doesn't mention error cases or how to use the returned key. This is a noticeable gap for a creation 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 every parameter is already documented. The description adds minimal value by grouping key parameters ('budget, expiry, daily limit, and tool allowlist'), but it doesn't introduce new meaning or clarify relationships beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.

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

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

The description uses a specific verb ('Delegate a scoped child key') and a clear resource ('a worker'), and it distinguishes itself from sibling tools like revoke_subagent and list_subagents by focusing on creation with scoping constraints. It is immediately evident what the tool does.

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

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

The description gives a clear usage condition: 'Only top-level agents can delegate.' It also implies the lifecycle (revocable any time) and scoping constraints. However, it does not explicitly name alternative tools or state when NOT to use it, but the condition is strong enough to guide the agent.

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 behavioral burden. It discloses part of the response shape ('with status and credited amount'), which is useful, but does not state that this is a safe read-only listing, whether results are paginated, or what authorization/permission scope is required. Adequate but incomplete for an unannotated 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?

A single front-loaded sentence: verb and resource first, scope and returned fields after. No filler, no restatement 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?

There is no output schema, so the description rightly names the returned fields (status, credited amount). With one fully documented optional parameter and a simple list contract, almost everything needed to call it is present; pagination/format details are 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?

Only one parameter, and the schema documents it at 100% coverage including the 'optional when Authorization: Bearer is sent' fallback. The description adds nothing about the key parameter, so the baseline of 3 for high schema coverage 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?

Specific verb (List), specific resource (bounties), and a clearly stated scope: those 'this wallet has claimed through agentpay'. That scope wording is what separates it from the sibling list_bounties, which lacks the wallet-claim filter. An agent can route between them without opening either 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?

The scope phrase 'this wallet has claimed' implies the use case (viewing your own claimed bounties), but there is no explicit when-to-use, no when-not-to-use, and no named alternative such as list_bounties or get_bounty. 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?

No annotations are provided, so the description carries the full burden. It discloses the fields exposed (amount, escrow address, funding/payout/refund txids, pending error), which is useful, but says nothing about auth requirements, pagination, refresh/caching, or whether the pending error indicates staleness.

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 with zero filler and the resource + returned fields front-loaded. 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 single-param read tool with no output schema and no annotations, the description covers what the tool returns and its scoping. It omits auth details and pagination, but the key parameter's schema description already covers auth, so the gap is small.

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% and the single 'key' parameter is well documented there, including the optional bearer-auth fallback. Baseline is 3 for high coverage; bumping to 4 because the description frames the whole call as wallet-scoped, reinforcing the auth semantics.

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 a specific resource (agentpay-funded bounties posted by this wallet). The 'funded/posted by this wallet' scoping clearly distinguishes it from list_bounties (all bounties) and my_bounties (a different entity type).

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 scoping to 'posted by this wallet' implies a usage context, but the description never explicitly contrasts with list_bounties, my_bounties, or get_bounty, nor states when-not to use it. Usage is inferred 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?

With no annotations, the description carries the behavioral load. It discloses the aggregate-read behavior (inspects four data sources), that the result is a single recommended action, and that it is 'Free' — a useful cost signal. It does not explicitly confirm the tool is non-mutating or that it works without a key, but the schema covers the key/Authorization case, so remaining gaps are 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?

A single sentence, front-loaded with the most important fact ('First call for a new agent'), followed by behavior and outcome. Every clause earns its place with no redundancy.

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?

Although there is no output schema, the description summarizes the return value (the single next action) and enumerates its possible values, which is exactly what an agent needs to act. Auth handling is covered by the schema. It could be marginally more complete by stating the tool performs no mutation, but as a low-complexity 1-param tool it is essentially 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?

There is only one parameter and schema coverage is 100%, so the schema fully documents the optional key. The description adds no parameter-level detail, 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?

The description states a specific verb ('inspects') over concrete resources (balance, claims, earnings, spend history) and its unique role as the onboarding entry point ('First call for a new agent'). This distinguishes it from single-purpose siblings like get_balance or health, which return data rather than a recommended next action.

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 explicit situational guidance: use this as the 'first call for a new agent.' The enumerated outcomes (earn first, dry-run spend, link identity, or scale) show the agent what downstream path this decision routes to. It stops short of naming when NOT to use it or which specific sibling to call after each outcome.

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 does meaningful work: it discloses money movement (BSV mainnet, site wallet pay, agent wallet debit), the refund-on-seller-rejection behavior, and the returned artifacts (seller result + txid). It omits auth expectations, approval-flow mechanics, and idempotency/rate behavior, so it falls 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?

Three tight sentences with the core purpose front-loaded, then refund behavior, then the optional fast-path parameter. Every sentence carries information, though the middle refund sentence could be folded in and no mention is made of the sandbox dryRun path.

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 10-parameter payment tool with no annotations and no output schema, the description covers the workflow, network, refund guarantee, and return payload. It is still silent on the approval_required path (beyond the bountyAccount hint), error modes, and how dryRun relates to a real settlement, which matters given the financial stakes.

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 80%, so the baseline is 3, but the description adds real meaning beyond the schema for bountyAccount by specifying the reputation fast-path and the approval x2 condition at score>=650 that the schema only labels "trust fast-path." Other parameters (ref, description, amountCents, approvalId) get no elaboration, keeping it below 5.

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 verb chain and resource: quotes the seller's x402 challenge, pays from the site wallet on BSV mainnet, debits the agent wallet, and returns the seller's result plus txid. An agent can distinguish this full pay-and-settle pipeline from the quote-only sibling (service_quote) 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?

"One call for paid registry tools" implies when to use it, and the bountyAccount note gives a conditional fast-path (approval x2 when score>=650). However, it never names alternatives such as service_quote or the dryRun safety path, nor states when not to pay directly, leaving the agent to infer the quote-first workflow.

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 full burden, and it does well: it discloses on-chain escrow (real sats, per-bounty key), listing on BSVBounties, and that the balance is debited at the posted rate plus platform fee on payout. It does not state reversibility, auth requirements beyond the implicit wallet, or failure modes, so it's strong but not complete.

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, front-loaded with the core action and funding source. No filler. Slightly less than perfect because the fee-on-payout detail is buried in the second sentence and could be its own clarifying clause.

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 7-param mutation tool with no annotations and no output schema, the description covers the key behavioral facts (escrow, listing, fee timing) that an agent needs to avoid surprises. It leaves out return value shape and balance-check preconditions, which keeps it short of 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 71%, so the schema documents most parameters (including key, category, deadline, amountSats, payoutAddress with defaults). The description adds meaning about amountSats being escrowed and fee-on-payout behavior but does not clarify the key/deadline/category/payoutAddress semantics 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 (create/post) and resource (bounty) funded from the wallet balance, and names the external listing (BSVBounties). Distinguishes from siblings like list_bounties and claim_bounty by making the funding/mutation semantic 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?

The description implies usage (you must have balance to fund it) but never states when to use post_bounty versus, say, submit_work or settle_bounty, nor any prerequisite about available balance. No explicit when-not guidance.

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. 'Revoke' implies a destructive or irreversible action, but the description doesn't disclose the immediacy, irreversibility, or any side effects (e.g., whether the key becomes unusable instantly, whether related resources are affected). The word 'immediately' adds some context but is insufficient for a revocation operation.

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, concise sentence that front-loads the action. It is appropriately sized, though it could add a brief usage note without becoming verbose.

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 revocation tool with no annotations and no output schema, the description is too sparse. It doesn't explain the effect of revocation, whether it's reversible, or what happens to the agent's access. The schema covers parameters, but the behavioral context is missing.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond the schema, but the schema itself is clear about the key and agentId. Baseline 3 is appropriate since the description doesn't compensate or add value 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?

The description states a specific verb ('Revoke') and resource ('a delegated child key'), which clearly identifies the action. It doesn't explicitly name sibling tools, but the title 'Revoke a sub-agent' and the description align well with the tool's function. It is distinguishable from siblings like mint_subagent and list_subagents.

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

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

The description implies the tool is for revoking a previously delegated key, but it doesn't explicitly state when to use it versus alternatives or mention prerequisites like the key being active. The schema references mint_subagent and list_subagents, which gives context, but the description itself lacks explicit usage guidance.

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 must carry the behavioral burden. It adds useful context: unsigned call, returns live 402 payment requirements, public/no key required, and bountyAccount is a hint that doesn't alter price. It doesn't disclose rate limits, error conditions, or what the response body looks like beyond price/payTo.

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 the core action and outputs, then optional parameter note. No filler, though the parenthetical (price/payTo) is a bit dense.

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 quote tool with no output schema, the description covers the essential mechanics: unsigned call, live 402 requirements, public access, and optional trust hint. It lacks some details like error handling or whether the response is JSON, but is largely 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 the schema already documents all three parameters with descriptions. The description adds only marginal meaning: that bountyAccount is optional and a trust hint affecting discount eligibility without changing the price. This clarifies behavior of a parameter but does not add syntax or format 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?

The description states a specific action (call a registry tool unsigned, return the 402 payment requirements) with concrete outputs (price/payTo). It somewhat distinguishes itself from pay_service by the word 'unsigned' and 'quote', but doesn't explicitly name the alternative or state that it doesn't execute payment.

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?

Implies usage by saying it's public and doesn't need a key, and that bountyAccount is optional for a discount hint. However, it doesn't state when to prefer this over pay_service or whether to call it before paying.

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 provided, so the description carries the burden and largely succeeds: it discloses the monetary side effects ('spends the on-chain escrow to the worker (net of fee)', 'returns it to treasury and credits your balance'). It omits auth requirements and irreversibility/whether both outcomes are final, but the escrow and credit mechanics are unusually well disclosed.

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, front-loaded with the actor and action, then the branch outcomes. No filler; each clause conveys distinct information about the two paths and their effects.

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 with no annotations and 33% schema coverage, the description supplies essential behavioral context (escrow movement, fee, balance credit) that the schema lacks. It is nearly complete, though state prerequisites and irreversibility are unaddressed.

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 33%, so the description should ideally compensate. It explains the semantic meaning of the 'outcome' enum values (paid = escrow to worker; refunded = return to treasury), which is genuinely valuable for the two enum branches. The 'key' auth param is left to the schema, leaving a gap, so a solid 3.

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 (settle/approve/refund) and resource (bounty), with the actor constraint ('As the poster'). Clearly distinguishes the terminal outcome action from siblings like post_bounty, claim_bounty, and submit_work.

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?

Describes the two branches (paid vs refunded) and implicitly when each applies: approve a submitted bounty vs refund it. However, it doesn't state prerequisites (e.g., that a bounty must be in submitted state) or explicitly exclude/route to alternative settlement paths.

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 behavioral disclosure burden. It discloses side effects (debit, receipt minting) and a failure mode (402 for insufficient balance or daily limit) with a recovery action. However, it omits the approval flow implied by approvalId, idempotency behavior, and the success response 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?

Two sentences with no filler: the core effect, the failure condition, and the recovery path are all included efficiently. Information is front-loaded and each 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?

The tool is moderately complex with 7 parameters, no output schema, no annotations, and an approvalId that hints at a stateful approval flow. The description does not explain what a successful response contains, how approval_required should be handled, or how the ref idempotency field behaves, leaving meaningful gaps.

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 86%, so the schema already documents most parameters. The description adds context about balance/daily-limit failure but does not elaborate on the required description parameter or the meaning of approvalId 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?

The description states a specific action ('Debit the wallet') and its result ('mint a receipt'), clearly identifying what the tool does. It does not explicitly distinguish itself from sibling pay_service, 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 description gives concrete routing guidance: on a 402 failure, call create_topup_link. This is a clear when-to-use alternative, though it does not address when to choose spend over pay_service or service_quote.

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 does not disclose whether this is a mutation, whether it finalizes or merely records work, what happens to a previously submitted work item, whether resubmission is allowed, or what the response looks like. The server-side hash computation note is the only behavioral detail.

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 compact sentences, front-loaded with the action and back-loaded with the payload and fallback behavior. 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 six-parameter write operation with no annotations and no output schema, the description covers the highest-risk parameters but leaves the mutation's side effects, finality, and return shape unexplained. Adequate but with clear gaps.

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 67%, with the bountyId required parameter having no description in either place. The description adds useful context for notes and workHash by explaining the omission fallback, but does not document bountyId or milestoneIndex semantics 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: submitting work for a bounty that was already claimed through agentpay. It distinguishes itself from claim_bounty and settle_bounty clearly enough by naming the claim prerequisite, though it doesn't explicitly name a sibling alternative.

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?

Implies usage through 'a bounty you claimed through agentpay', which tells the agent a prior claim is required, but there is no explicit when-to-use vs. when-not-to-use or comparison to settle_bounty or post_bounty. The prerequisite is a partial guideline, not a full routing rule.

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