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. 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?

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?

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 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?

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 full burden and does a good job: it discloses that the tool quotes, pays, debits the agent wallet, returns result plus txid, and refunds if the seller rejects. It stops short of detailing auth prerequisites or the approval flow, but the core side effects are transparent.

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

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

Two tight sentences with the primary purpose front-loaded and the refund behavior appended as a meaningful caveat. Every clause adds information without 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 complex payment tool with no output schema and no annotations, the description covers the main flow, the refund behavior, and the return payload shape. It could mention approval_required handling or how it relates to service_quote, but the essentials an agent needs to invoke it are present.

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 75%, so most parameters are already documented. The description adds behavioral context (e.g., that the tool quotes the x402 challenge and refunds on rejection) but does not add new meaning for uncovered parameters like ref or description. This is acceptable but not exceptional.

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 ('pays') with a clear resource ('paid registry tools') and details the full operation: quote the x402 challenge, pay from the site wallet, debit the agent wallet, and return seller result plus txid. This makes the tool's role distinct from siblings like service_quote 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?

It clearly scopes the tool to 'paid registry tools' and describes a one-call flow that combines quoting and paying, which tells an agent when this tool fits. It does not explicitly name alternatives or exclusions, but the context is strong enough to guide selection.

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 defense disclosure. It explicitly discloses that the call is public, keyless, live, and returns 402 payment details. It does not mention side effects or error cases, but for a quote-style read operation these are minor 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?

Two sentences with no filler, front-loading the core behavior and access model. Every clause earns its place.

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

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

For a simple two-parameter public tool, the description plus fully documented schema gives enough to call it correctly: purpose, access requirements, target selection, and return content. It only lacks explicit sibling differentiation and detail on non-402 outcomes.

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 `tool` and `serviceId`. The description adds only that the call targets a registry tool and does not meaningfully clarify parameter interaction beyond what the schema states.

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

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

The description states a precise behavior: invoke the registry tool without authentication and return the live 402 payment requirements (price/payTo). This clearly differentiates it from siblings like pay_service (which pays) and list_services (which lists), even 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?

It gives useful context by saying the call is public and unsigned, implying it should be used to discover payment requirements before paying for a service. However, it does not name alternatives or state when not to use this tool, so the agent must infer the routing decision.

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.