agentpay — card-funded wallets for AI agents

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

With no annotations, the description carries the full burden and largely meets it: it discloses that a real payment settles from the wallet, that wallet limits/scoped keys/trial budgets apply, that dryRun avoids any debit, and that the response includes completion, receiptUrl and txid. It stops short of covering reversibility, approval gating, or failure/rate behavior.

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

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

Front-loads the core value proposition (pay-per-call, no API key) then flows through mechanism, prices, constraints, and the dryRun escape hatch in tight, information-dense sentences. Every clause earns its place, though it is on the denser end.

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 9-param paid tool with no annotations and no output schema, the description is close to complete: it explains cost, side effects, safe mode, and — critically — the return shape (completion plus receiptUrl and txid) that no output schema supplies. The missing piece is the approval/approvalId path and error behavior.

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 67%, so most parameters are documented in the schema already. The description reinforces model pricing and dryRun semantics but adds no syntax or meaning for undocumented params like ref, approvalId, max_tokens, and amountCents — notably it never explains the approval flow implied by approvalId. Baseline 3 fits.

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 ("sends messages to Fuse chat completions") and pins the tool's effect (agentpay settles the x402 v2 BSV 402 and returns completion). It reads clearly as a paid chat-completion call, distinguishing it from generic siblings. It stops short of explicitly contrasting with payment siblings like pay_service or spend, which also spend wallet funds.

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 dryRun tip implies a quote-before-spend workflow, and the pricing note implies cost tradeoffs. But nothing says when to prefer this over pay_service/spend, and no prerequisites (auth, approval flow) are laid out as a when-to-use rule. Adequate but with clear gaps.

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 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 the full burden and does well: it discloses the settlement path, tier pricing/limits, error codes (413 oversized, 400 bad schema), return values (answers, receipt, txid), and a dryRun quote mode. Gaps remain (whether payment approval is required, rate limits) and the "standard x402 v2 BSV 402" phrase is opaque jargon rather than useful context.

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?

Dense and front-loaded: purpose, then routing, then types, then pricing, then return/quote behavior. Most sentences earn their place, though the settlement-mechanics sentence is jargon-heavy and could be tighter.

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, no-annotation, no-output-schema tool, the description covers purpose, alternatives, pricing, limits, error codes, and returns. Minor omissions (approval flow via approvalId, reference_date for relative dates) are documented in the schema itself.

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 baseline is 3, but the description adds real meaning: the type enum semantics, that lists require items, the name→{type} shape, and that input size drives the tier/price (≤1,500 chars vs ≤16,000). It also flags that images force at least the M tier, which the schema only implies.

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 ("Extract typed values from messy text or receipts") and immediately positions itself against the sibling chat tool. An agent can distinguish it from every sibling without opening a 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?

"Prefer this over chat when you need structured fields with confidence scores and explicit nulls (p_null) instead of made-up answers" names the alternative and the selecting condition. It lacks an explicit when-not clause (e.g., use chat for open-ended answers), so it stops short of the top tier.

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?

With no annotations, the description carries the burden well: it discloses that the child is confined to its budget/expiry/allowlist, that child spend also draws down the parent's daily limit, and it names the exact failure code 'parent_daily_limit'. It omits what is returned (the child key/secret) and whether approvalAboveCents escalates asynchronously.

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

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

Front-loaded with the core action, then progressively adds constraints and the important parent-daily-limit caveat. Dense but nearly every clause carries real information; the sentence is long and could be split for readability.

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-parameter credential-minting tool with no annotations and no output schema, the description leaves the return value unexplained — an agent does not know it receives a child key secret that must be captured. The permission and budget semantics are otherwise adequately covered.

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

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

Schema coverage is 100%, so every parameter, including units and constraints (cents, max 30 days, allowlist entry syntax), is already documented in the schema. The description restates the same four fields without adding format or interaction detail beyond the parent/child budget coupling.

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 ('Delegate a scoped child key for a worker') and enumerates the key's dimensions (budget, expiry, daily limit, allowlist). It is clearly distinguishable from siblings like list_subagents and revoke_subagent, which operate on keys rather than creating 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?

Gives an explicit precondition ('Only top-level agents can delegate') and points to lifecycle management ('revoke it any time', i.e. use revoke_subagent). It stops short of naming sibling alternatives or stating when NOT to mint a child versus using a topup/upgrade link.

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 largely meets it: it discloses real side effects (pays from the site wallet on BSV mainnet, debits the agent wallet) and failure semantics ('If the seller rejects the payment, the debit is refunded'), plus the return shape. It omits idempotency/retry and double-charge behavior, which matters for a money-moving 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?

Front-loaded with the primary action and effect, then routing guidance. The parenthetical challenge-format aside ('legacy single-object or standard v2 accepts[] — BSV exact only') is dense technical detail but defensible for a payment tool. Overall tight with little waste.

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

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

For a complex, 10-parameter, nested-object payment tool with no annotations and no output schema, the description covers the action chain, failure/refund behavior, and return content (result + txid). The approval_required flow referenced by approvalId is only implied, which is the main remaining gap.

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

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

Schema description coverage is high (~80%), so the schema already documents most parameters and a 3 is the baseline. The description adds genuine meaning for bountyAccount ('reputation fast-path — approval x2 when score>=650') that the schema does not, but leaves the other nine parameters (key, ref, tool, dryRun, params, approvalId, amountCents) to 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+resource (pay a paid registry tool via x402 challenge) and enumerates the full action chain: quote, pay from site wallet on BSV mainnet, debit agent wallet, return result plus txid. It explicitly distinguishes itself from named siblings chat and extract, so an agent can route without opening another 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?

Explicitly names alternatives with their selecting conditions: 'For pay-per-call LLM with no API key, use chat; for typed values from messy text or receipts, use extract.' It also gives a usage rule for bountyAccount. It stops short of the natural adjacent alternative service_quote/dryRun for quote-only lookups, so it is clear but not exhaustive.

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

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?

With no annotations, the description carries the full behavioral burden and does so well: it discloses idempotency semantics (retry with the same key returns the original txid), that daily limits, allowlists (spend or agent_send), and approval thresholds apply, and what txid means in each mode (BSV txid vs ledger receipt id). This is exactly the context an agent needs before an irreversible money movement.

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 the core purpose and the destination-mode distinction front-loaded, followed by the safety/replay rules. Every clause earns its place and nothing is repeated from the schema verbatim.

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

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

For a payment tool with no annotations and no output schema, the description covers what an agent must know: the two destination modes, settlement meaning, idempotent retry behaviour, spend controls, approval gating, and the secret-vs-public id pitfall. What remains uncovered (exact limit values) is policy detail rather than invocation semantics.

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 baseline is 3, but the description adds meaning the schema does not: it ties the dest value to settlement behaviour and txid interpretation, and explains the replay guarantee of idempotency_key at the operation level rather than just restating its type.

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 (pay) and resource (sats to a BSV P2PKH address or an apw_ wallet id), and cleanly splits the two destination modes with their differing settlement semantics. It does not explicitly differentiate from siblings like spend or pay_service, which also move funds, so an agent must infer the boundary.

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 destination type determines the mode (on-chain vs internal ledger), and the description makes that routing rule explicit, plus warns to pass the public wallet id and never the secret apw_ token. It stops short of naming which sibling tool to use instead when the user means a service payment or a generic spend.

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.