Skip to main content
Glama
forgesworn

402-mcp

by forgesworn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

l402-fetch

Destructive

Fetch payment-gated URLs by automatically paying L402 challenges when within budget, or return the price and payment hash for manual payment decisions.

Instructions

Fetch a URL, paying its HTTP 402 challenge (L402, IETF Payment, Cashu or LNURLcash) when autoPay is true and the price is within MAX_AUTO_PAY_SATS, maxCostSats and the spend limits. Reuses stored credentials. Without autoPay, a 402 comes back with its price and paymentHash so the user can decide; l402-pay can then pay it. For x402 services, which this server supports only in an experimental custom format, returns the payment details for the user to pay in their own wallet. Response bodies are marked as untrusted content. With widget hosts, call l402-fetch-preview first to show the price.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe primary URL to request. When using search results, pass the first URL here and all URLs in the urls field.
bodyNoRequest body (for POST/PUT)
urlsNoAll transport URLs from l402-search results (clearnet, onion, HNS). When present, transports are tried in preference order with automatic fallback on connection failure.
methodNoHTTP methodGET
pubkeyNoService pubkey from l402-search results — used to share credentials across all transport URLs for the same service
txHashNoTransaction hash from a completed x402 on-chain payment. When provided, retries the request with X-Payment header for server verification.
autoPayNoAutomatically pay if within MAX_AUTO_PAY_SATS budget
headersNoAdditional request headers
maxCostSatsNoMost this call may pay, in sats. Pass the price the user saw in l402-fetch-preview so a server cannot charge more than it showed. Lowers MAX_AUTO_PAY_SATS for this call; never raises it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.3.0
    • addedInput schema / properties / maxCostSats
      Added value: +{
+  "description": "Most this call may pay, in sats. Pass the price the user saw in l402-fetch-preview so a server cannot charge more than it showed. Lowers MAX_AUTO_PAY_SATS for this call; never raises it.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}
  2. First observedv4.2.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare openWorldHint and destructiveHint, so the description adds value by explaining the payment side effects, credential reuse, untrusted response bodies, and the maxCostSats cap. It doesn't fully detail what happens to stored credentials or whether failures are reversible, but it covers the key behavioral traits beyond annotations.

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

Conciseness4/5

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

The description is dense but well-organized, front-loading the core fetch-and-pay behavior before edge cases. Every sentence adds information, though the x402 and widget-host sentences could be seen as slightly crammed. Overall it earns its length.

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?

For a complex tool with 9 parameters, no output schema, and payment side effects, the description covers the main flows, the autoPay decision, the preview routing, and the untrusted-content warning. It doesn't specify the exact return shape of a 402 response, but the description says the price and paymentHash come back, which is enough for an agent to proceed.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining the relationship between maxCostSats and MAX_AUTO_PAY_SATS, the purpose of pubkey for sharing credentials, and the txHash retry behavior. It doesn't describe every parameter in prose, but the schema already does that.

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 description clearly states the tool fetches a URL and handles HTTP 402 payment challenges, distinguishing it from siblings like l402-pay and l402-fetch-preview. It names the specific protocols (L402, IETF Payment, Cashu, LNURLcash) and the autoPay behavior, so an agent can tell exactly what this tool does.

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

Usage Guidelines5/5

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

The description explicitly explains when to use autoPay vs not, when to call l402-fetch-preview first for widget hosts, and when to use l402-pay for a returned 402. It also mentions x402 experimental format handling. This is strong routing guidance relative to siblings.

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