Skip to main content
Glama
dinggi5

Kura

by dinggi5
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

x402_fetch

Fetch a paywalled URL; on 402, request user approval, build an EIP-3009 signature, and re-fetch with an X-PAYMENT header to return the body. Returns the body directly if no payment is required.

Instructions

Fetches an x402 paid resource (a URL). It GETs the URL first; if the server answers 402 Payment Required, it asks the user to approve the required payment (exact scheme, the active Base network, USDC) in the wallet app, builds an EIP-3009 signature, and re-requests the same URL with an X-PAYMENT header to return the content. If no payment is required (no 402), it just returns the body. Approval works exactly as in request_payment (password by default; automatic only when the user has turned autopay on), and the app enforces per-payment and daily limits and the emergency lock. Never send a password as an argument. Arguments: url (required), memo (what the payment is for — the user reads it to decide). Returns: paid, status, http_status, body, and amount/pay_to/settlement when paid.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesURL of the paid resource to fetch (http/https).
memoNoWhat the payment is for — the user reads this in the approval window, so fill it in.
agent_idNoOptional: the seller's ERC-8004 agent number, if you know it from the service's own documentation or agent card. The wallet then reads that agent's on-chain record and shows the user whether the payment address and the resource domain match what is registered. Leave it out if you don't know it — a wrong number just produces a "no such agent" note.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • addedInput schema / properties / agent_id
      Added value: +{
+  "default": null,
+  "description": "Optional: the seller's ERC-8004 agent number, if you know it from the service's own\ndocumentation or agent card. The wallet then reads that agent's on-chain record and shows\nthe user whether the payment address and the resource domain match what is registered.\nLeave it out if you don't know it — a wrong number just produces a \"no such agent\" note.",
+  "format": "uint64",
+  "minimum": 0,
+  "nullable": true,
+  "type": "integer"
+}
  2. First observedv0.2.0

TDQS

A4.4/5.0
Behavior5/5

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 thoroughly walks through the GET request, handling of a 402 response, user approval, EIP-3009 signature construction, and re-request with the X-PAYMENT header. It also discloses approval defaults, autopay behavior, per-payment and daily limits, the emergency lock, and explicitly warns never to send a password as an argument. This is exemplary transparency for a complex payment-flow tool.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: purpose, flow, fallback, approval behavior, safety warning, argument summary, and return values. It is front-loaded with the core action and reads naturally despite covering a multi-step process. The length is justified by the complexity of the tool.

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

Completeness4/5

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

The description explains the full behavior, safety constraints, and return fields, which is important given the absence of an output schema. It lists the returned keys (paid, status, http_status, body, amount/pay_to/settlement). However, it does not detail error cases such as user rejection, network failures, or the distinction between status and http_status, leaving minor gaps for a tool with this complexity.

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

Parameters3/5

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 all three parameters in detail. The description adds a small amount of context for memo ('the user reads it to decide'), but it does not add meaningful semantics for url or agent_id beyond what the schema provides. The baseline of 3 is appropriate because the schema does the heavy lifting.

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

Purpose5/5

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

The opening sentence states a specific verb and resource: 'Fetches an x402 paid resource (a URL).' It then describes the full fetch-and-pay flow, making the tool's purpose unmistakable. It is clearly distinct from sibling tools like get_balances or get_history, and it references request_payment only to clarify the approval mechanism, not the core purpose.

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

Usage Guidelines4/5

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

The description makes it clear that this tool is for fetching a URL that may trigger a payment, and it explains what happens when no payment is required. It references request_payment for approval behavior, which implicitly signals the sibling relationship, but it does not explicitly state when to choose x402_fetch over request_payment or other alternatives. No exclusions or when-not-to-use guidance is given, but the context is clear.

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

Deploy Server

Other Tools