Skip to main content
Glama
Sign In
forgesworn

402-mcp

by forgesworn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

l402-fetch

Destructive

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.

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

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.
paymentFlowNoPass the storage paymentFlow from search results; this unsupported flow is refused before network or wallet access.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.4.0
    • addedInput schema / properties / paymentFlow
      Added value: +{
+  "const": "wildbloom-checkout-v1",
+  "description": "Pass the storage paymentFlow from search results; this unsupported flow is refused before network or wallet access.",
+  "type": "string"
+}
  2. 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"
+}
  3. First observedv4.2.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say openWorldHint/destructiveHint; the description adds the financial behavior (spend limits, MAX_AUTO_PAY_SATS capping), credential reuse, untrusted-content marking of responses, refusal of unsupported paymentFlow before network/wallet access, and the experimental x402 handling. These are material traits beyond the 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?

Front-loads the core action and payment condition, then layers edge cases. Parenthetical protocol lists and conditionals make it dense, but nearly every clause carries decision-relevant information.

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

Completeness5/5

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

For a 10-param, no-output-schema tool, it covers return behavior in both branches (402 with price/paymentHash, x402 payment details), the preview prerequisite, and spend safeguards. Nothing an agent needs to call it safely is missing.

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, but the description adds cross-parameter semantics: maxCostSats 'lowers MAX_AUTO_PAY_SATS for this call; never raises it', and implies the autoPay/price interaction. It stops short of explaining pubkey/txHash mechanics that the schema itself covers.

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?

States a specific verb+resource ('Fetch a URL, paying its HTTP 402 challenge') with the exact protocols supported. It also distinguishes itself from siblings by naming l402-pay and l402-fetch-preview with the conditions that select each, so an agent can route 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.

Usage Guidelines5/5

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

Explicit when-to-use branches: autoPay true pays within budget, autoPay false returns the 402 for user decision, l402-pay pays afterwards, and widget hosts must call l402-fetch-preview first. Exclusions are stated, not implied.

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