AgentWallet MCP Server

create_paywall

Create an x402 paywall that charges agents for protected resource access; it returns a public URL issuing HTTP 402 until on-chain payment proof unlocks the content.

Instructions

Create an x402 paywall that charges agents/clients for accessing a resource. Returns a public access URL that returns HTTP 402 until paid. Agents pay on-chain, then retry with proof to get the content.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "wallet_id": "<wallet_id>",
      "name": "<name>",
      "amount": "<amount>",
      "resource_url": "<resource_url>"
    },
    "name": "create_paywall"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	Human-readable paywall name (e.g. "Premium API Access")
`amount`	Yes	Price in human-readable format (e.g. "0.01" for 0.01 USDC)
`chain_id`	No	Chain ID for payments (8453=Base, 1=Ethereum, etc.)
`wallet_id`	Yes	Wallet ID to receive payments
`token_name`	No	Token display name (e.g. "USDC", "ETH")	USDC
`token_type`	No	"erc20" for EVM stablecoins, "spl" for Solana SPL tokens, "native" for ETH/SOL/POL/etc.	erc20
`description`	No	Description shown in the 402 response
`resource_url`	Yes	URL of the protected resource to serve after payment verification
`resource_mime`	No	MIME type of the resource (e.g. "application/json", "text/plain")	application/json
`token_address`	No	Token contract address (ERC-20 for EVM, SPL mint Base58 for Solana). Required if token_type is "erc20" or "spl". Use get_chains to find stablecoin addresses.
`token_decimals`	No	Token decimals. Defaults to the chain native decimals for "native", else 6 (USDC); set it for any other token

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.14.8Oct 27, 2026
- addedInput schema / properties / chain_id / maximum
```
Added value: +9007199254740991
```
- addedInput schema / properties / chain_id / minimum
```
Added value: +-9007199254740991
```
- addedInput schema / properties / wallet_id / maximum
```
Added value: +9007199254740991
```
- addedInput schema / properties / wallet_id / minimum
```
Added value: +-9007199254740991
```
Changed4 schema fields changedv1.14.2Oct 14, 2026
- removedInput schema / properties / token_decimals / default
```
Removed value: -6
```
- changedInput schema / properties / token_decimals / description
```
Previous value: -"Token decimals (6 for USDC, 18 for ETH/most tokens)"New value: +"Token decimals. Defaults to the chain native decimals for \"native\", else 6 (USDC); set it for any other token"
```
- addedInput schema / properties / token_decimals / maximum
```
Added value: +36
```
- addedInput schema / properties / token_decimals / minimum
```
Added value: +0
```
First observedv1.7.3Mar 11, 2026

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose the core behavioral model well: it returns a public access URL, that URL answers HTTP 402 until paid, and agents pay on-chain then retry with proof. However, it does not state authorization requirements (e.g., that wallet_id must be owned/valid), whether the paywall is immediately active, or what happens on invalid resource_url, leaving meaningful mutation-side-effect gaps.

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?

Three sentences, front-loaded with the core action and followed by the most important behavioral detail (the 402 flow). Every sentence adds value with no repetition or filler.

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 an 11-parameter creation tool with no annotations and no output schema, the description supplies the essential conceptual model an agent needs: what gets created and how the resulting URL behaves. It is slightly incomplete on prerequisites (wallet ownership) and error behavior, but the rich schema covers the parameter surface.

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 all 11 parameters are already documented in the schema with examples and defaults. The description adds no parameter-level guidance beyond what the schema provides, which is the baseline 3 when 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?

States a specific verb and resource ('Create an x402 paywall') and immediately defines the object's purpose ('charges agents/clients for accessing a resource'). This clearly distinguishes it from siblings such as update_paywall, get_paywall, and pay_x402 without needing to name them.

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 gives clear context for when to use it: you want to monetize a resource by requiring on-chain payment. It implies the distinction from pay_x402 (this creates the paywall; that pays it), but it does not explicitly state exclusions or prerequisites such as needing an existing wallet_id from create_wallet.

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