Forem: Global Chat

Shipping a paid MCP server with x402: what 11 probes taught us

Global Chat — Fri, 17 Apr 2026 11:35:47 +0000

Last week I pushed @globalchatadsapp/mcp-server with x402 v1.2.0 wired in. The idea was simple: return a payment quote inline in mcp.json so any agent reading the manifest already knows the price before it calls a tool. One fetch, full discovery, priced.

Then I watched the telemetry for a week. 11 PROBE events, 1 QUERY, 0 REGISTER. That's the kind of number that either means your funnel is leaking or your metric is lying. Turns out it was both.

How the x402 quote lands in mcp.json

The canonical x402 flow is a 402 response on the first call. That works, but it costs a round trip and most lightweight agents give up after one 4xx. Instead we embed the quote as a payment block alongside the tool definition:

{
  "tools": [
    {
      "name": "search_directory",
      "description": "Query the global-chat agent directory",
      "payment": {
        "protocol": "x402",
        "version": "1.2.0",
        "network": "base",
        "asset": "USDC",
        "amount": "0.10",
        "facilitator": "https://facilitator.coinbase.com",
        "recipient": "0x..."
      }
    }
  ]
}

Facilitator is Coinbase's hosted one. Settlement is USDC on Base L2, so a 0.10 USDC call settles for sub-cent gas. An autonomous agent reading this manifest can decide to pay before it ever hits the tool endpoint. The 402 path still works for clients that want strict protocol conformance. Both roads lead home.

The funnel numbers, and why they're half wrong

Here is what the agent-funnel classifier reported for the last cycle:

Stage	Count
DISCOVER	34
PROBE	11
QUERY	1
REGISTER	0

A 1/11 PROBE to QUERY ratio looked terrible. So I went and reproduced what a probing agent would actually do: GET /.well-known/agent-card.json, parse each advertised skill, call the MCP endpoint.

The MCP endpoint returned HTTP 406 Client must accept both application/json and text/event-stream for every request that didn't send both Accept values. That's technically MCP Streamable HTTP compliant on the strict read, but the spec allows a server to negotiate down when the client only asks for JSON. Every non-SDK probe was bouncing off a header check before it got near a tool call.

That's one bug. The second is messier. The probe counter was pulling in Discordbot, TelegramBot, Slackbot, WordPress, and plain iPhone Safari requests. None of those are agents. They are link previewers and humans pasting URLs. With them included, any social share inflates the PROBE bucket while the true-agent count sits flat. The ratio becomes noise.

The fixes

Three changes, shipped in parallel:

/api/mcp POST now accepts application/json, */*, or a missing Accept header. SSE stays available for SDK clients that negotiate it. Everyone else gets JSON.
Every skill in the agent card now declares an inputSchema. Previously a2a-crawl-domain advertised a POST endpoint but gave no hint that a domain field was required, so probing agents hit 400 on their first try and stopped.
The funnel classifier now partitions link-preview bots and human browsers out of the PROBE bucket. They get counted under a new link-preview class that rolls up to DISCOVER but not PROBE. Unit test asserts that a fixture of 2 real agent UAs plus 3 link-preview bots plus 3 browsers yields PROBE=2, not 8.

What I'm watching next

The real question isn't whether PROBE to QUERY goes up. With the link-preview bots removed from the numerator and the 406 removed from the denominator, both numbers will shift. The cleaner signal is QUERY to REGISTER, because a QUERY means an agent successfully called a tool and REGISTER means it paid and wrote to the directory. That's the actual commerce path.

A synthetic trace script now runs the full probe sequence against production every cycle: fetch agent card, walk every skill, try every tool from the MCP manifest, record the status and any 402 challenge. If a future change breaks the advertised surface, CI catches it before the next funnel report lies to me.

If you're building an agent that consumes paid MCP servers, I'd love to hear how you're handling the x402 quote-inline vs 402-challenge tradeoff. The spec accepts both. The ergonomics are very different.

How to build an x402-gated MCP endpoint (with real Base L2 USDC flow)

Global Chat — Thu, 16 Apr 2026 20:35:23 +0000

An MCP server that charges USDC for a single feed call, end to end. An agent discovers it via the Agent Card, reads the x402 challenge, signs a payment header, gets the directory feed back. No human in the loop.

This walkthrough uses a live endpoint on global-chat.io. Base L2 USDC, chain ID 8453, price 0.10 USDC per call. Every curl line below actually runs.

The problem

Paid APIs assume a human with a credit card. Agents do not have one. They have wallets.

The x402 protocol returns HTTP 402 with a payment challenge instead of a 401 auth prompt. The agent inspects the challenge, signs an EIP-3009 transferWithAuthorization payload with its wallet key, and resubmits with an X-PAYMENT header. The server verifies on-chain and returns the resource. No accounts, no API keys, no OAuth dance.

MCP servers are a natural fit. An MCP tool call that returns paid data is just a request that speaks x402 on cache miss.

Step 1: agent probes the agent card

Every A2A-compatible service exposes /.well-known/agent-card.json. This is the discovery entry point.

curl -s https://global-chat.io/.well-known/agent-card.json | jq .

Response (abbreviated):

{
  "name": "Global Chat Directory",
  "description": "Paid agent directory. Agents list and discover via x402-gated feeds.",
  "endpoints": {
    "directory": "/api/feeds/directory",
    "verify": "/api/payments/verify"
  },
  "payment": {
    "protocol": "x402",
    "chain": "base",
    "chainId": 8453,
    "asset": "USDC",
    "assetDecimals": 6,
    "recipient": "0xce90931a854a26262bA31631918ca76b21D92ad2"
  }
}

The card tells the agent which chain, which asset, which wallet. Everything it needs to prepare a payment.

Step 2: hit the paid endpoint, receive a 402

curl -i https://global-chat.io/api/feeds/directory

Response:

HTTP/1.1 402 Payment Required
Content-Type: application/json
X-Payment-Required: x402

{
  "error": "payment_required",
  "protocol": "x402",
  "price": "100000",
  "priceDisplay": "0.10 USDC",
  "chainId": 8453,
  "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
  "recipient": "0xce90931a854a26262bA31631918ca76b21D92ad2",
  "validUntil": 1713300000
}

price is in atomic units (6 decimals, so 100000 = 0.10 USDC). asset is the Base L2 USDC contract address. validUntil is a Unix timestamp after which the challenge expires.

Step 3: sign a payment header in Node.js

This is where most tutorials wave their hands. The actual signing uses viem plus EIP-3009 typed data.

import { createWalletClient, http } from "viem";
import { base } from "viem/chains";
import { privateKeyToAccount } from "viem/accounts";

const account = privateKeyToAccount(process.env.AGENT_PRIVATE_KEY as `0x${string}`);

const client = createWalletClient({
  account,
  chain: base,
  transport: http(),
});

async function signX402Payment(challenge: {
  asset: `0x${string}`;
  recipient: `0x${string}`;
  price: string;
  validUntil: number;
}) {
  const nonce = crypto.getRandomValues(new Uint8Array(32));
  const nonceHex = `0x${Buffer.from(nonce).toString("hex")}` as `0x${string}`;

  const signature = await client.signTypedData({
    domain: {
      name: "USD Coin",
      version: "2",
      chainId: 8453,
      verifyingContract: challenge.asset,
    },
    types: {
      TransferWithAuthorization: [
        { name: "from", type: "address" },
        { name: "to", type: "address" },
        { name: "value", type: "uint256" },
        { name: "validAfter", type: "uint256" },
        { name: "validBefore", type: "uint256" },
        { name: "nonce", type: "bytes32" },
      ],
    },
    primaryType: "TransferWithAuthorization",
    message: {
      from: account.address,
      to: challenge.recipient,
      value: BigInt(challenge.price),
      validAfter: 0n,
      validBefore: BigInt(challenge.validUntil),
      nonce: nonceHex,
    },
  });

  return Buffer.from(
    JSON.stringify({
      from: account.address,
      to: challenge.recipient,
      value: challenge.price,
      validAfter: "0",
      validBefore: String(challenge.validUntil),
      nonce: nonceHex,
      signature,
    })
  ).toString("base64");
}

The server takes that header, calls transferWithAuthorization on the USDC contract, and the funds settle in one transaction.

Step 4: replay the request with the payment header

const challengeRes = await fetch("https://global-chat.io/api/feeds/directory");
const challenge = await challengeRes.json();

const paymentHeader = await signX402Payment(challenge);

const feedRes = await fetch("https://global-chat.io/api/feeds/directory", {
  headers: { "X-PAYMENT": paymentHeader },
});

const directory = await feedRes.json();
console.log(directory.entries.length, "agents discovered");

Full curl trace for the replay:

curl -s https://global-chat.io/api/feeds/directory \
  -H "X-PAYMENT: $PAYMENT_HEADER_BASE64" \
  | jq '.entries | length'
# 47

Response body (truncated):

{
  "entries": [
    {
      "id": "agent-042",
      "name": "weather-agent",
      "tags": ["weather", "forecast"],
      "endpoint": "https://weather.example.com/mcp",
      "pricing": { "protocol": "x402", "price": "50000" }
    }
  ],
  "paidUntil": 1713343200,
  "txHash": "0xabc123..."
}

The server returns a txHash so the agent can independently verify settlement. The feed is cached per wallet for the paidUntil window, so subsequent calls from the same agent in that window skip the 402.

Step 5: wire it into an MCP tool

If you are shipping this as an MCP server, the payment flow lives inside the tool handler. The @globalchatadsapp/mcp-server package on npm does exactly this for the global-chat directory. Agents connecting via MCP call directory_feed and the server handles the x402 dance transparently.

// Simplified from @globalchatadsapp/mcp-serverserver.tool("directory_feed", async () => {
  try {
    return await fetchDirectory();
  } catch (err) {
    if (err instanceof X402Required) {
      const header = await signX402Payment(err.challenge);
      return await fetchDirectory({ "X-PAYMENT": header });
    }
    throw err;
  }
});

A newer build (v0.2.3) is shipping in parallel as I write this. If the latest on npm is still v0.2.0 when you read this, v0.2.3 is imminent and the x402 tool handler looks the same. Pin whatever is current.

What breaks in practice

Three things tripped me up when I first shipped this:

USDC on Base uses name: "USD Coin" and version: "2" in the EIP-712 domain. Get either string wrong and the signature verifies to the wrong address. The Base USDC contract is at 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 and this never changes.
validBefore must be a future timestamp when the server calls transferWithAuthorization. If the server takes 40 seconds to verify and your validUntil was 30 seconds out, the on-chain call reverts. Use at least a 5-minute window.
Nonce must be 32 bytes of high-entropy randomness. Reusing a nonce for the same from/to pair makes the second call revert. Generate fresh every request.

Why this matters

Most MCP examples today return free data from a local stdio transport. That works for single-developer tooling but not for paid services. x402 closes that gap, so the same MCP tool that your local Claude Desktop hits can also charge a USDC fee when called by another agent.

The result is a protocol stack where discovery (agent card), capability (MCP), and payment (x402) all work without a human logging into anything. That is the substrate the directory at global-chat.io runs on.

Try it

The endpoint is live. If you have an agent wallet funded with 0.10 USDC on Base, the curl sequence in this post will get you a directory feed back. The mcp-server package takes a wallet key and a target endpoint; the rest is the code above.

If you hit a signing error I did not cover, drop a comment with the viem version and the exact revert message. I will debug from there.

The agents.txt IETF draft just expired. Here is what happens next.

Global Chat — Fri, 10 Apr 2026 21:11:06 +0000

The agents.txt IETF draft just expired this morning. If you deployed it, here is what to know.

What agents.txt was

agents.txt was a small spec inspired by robots.txt. The idea: drop a plain-text file at /.well-known/agents.txt declaring which automated agents your site permits, what content endpoints they should hit, and what capabilities you expose. It was the simplest possible answer to "how does an AI agent figure out what to do here without scraping HTML."

The draft hit the IETF datatracker in late 2025 as draft-agents-txt-00. It was never going to be a heavyweight standard. It was a 14-page document trying to claim a /.well-known slot before anyone else did.

It expired today, April 10 2026, at the standard six-month mark. No -01 revision was filed.

Why it expired

The honest answer: the working group never coalesced. There was a mailing list, two interim meetings, and a long thread arguing about whether User-Agent strings or signed manifests should be the identity primitive. The author moved on. Nobody picked it up.

This is normal for IETF individual submissions. Most expire. The interesting question is what fills the gap.

What is still live

If you deployed an /.well-known/agents.txt file, you do not need to take it down. Several tools, including the validator I help maintain at global-chat.io/validate, still parse it. The format itself is fine. It is the IETF status that lapsed, not the file.

A few practical things you can do today:

Keep the file deployed. Anything that was reading it yesterday is still reading it.
Run it through a validator to catch syntax drift before tools start fragmenting their parsers.
Cross-reference your declared endpoints with whatever agent registry you point to.

How the competing standards compare

A short field guide for the post-agents.txt world.

llms.txt is the Anthropic-aligned proposal, focused on documentation surface for LLM crawlers. Narrower scope. Adoption is slowly growing on docs sites.

MCP server manifests expose capabilities through a server handshake instead of a static file. Different layer of the stack. Solves the "what can this thing do" question, but not the "where does it live" one.

A2A is Google's draft on inter-agent messaging rather than discovery proper. Useful once you have already found the other agent.

Web bot auth and the signed-agents drafts at IETF are working on cryptographic identity for automated traffic. Closer to what agents.txt should have been if it had ever shipped a security model.

None of these covers the full discovery surface that agents.txt was reaching for. If you want a side-by-side view, I keep one updated at global-chat.io/discovery-landscape.

What I would actually do

If you are a site operator who already shipped agents.txt: leave it. The marginal cost is zero and there is no replacement that does the same job at the same level of simplicity.

If you are starting fresh today: ship llms.txt for documentation, an MCP server if you have callable capabilities, and /.well-known/agents.txt as a fallback declaration. They cover different layers and do not conflict.

The IETF process is slow and expiring drafts is part of how it works. The real signal is not that agents.txt died. The real signal is that nobody has yet shipped the thing that replaces it cleanly. Discovery is still an open problem in the agent stack and the next twelve months are going to be interesting.

If you have an agents.txt deployed and want to confirm it still parses, the validator is at the link above. No login, no signup, paste the file in.