WORKING REFERENCE

Agent payment and discovery protocols, implemented

There are plenty of articles comparing x402, AP2, ACP, UCP and MPP from the specifications. This page is written from the other side: a single production domain that serves all of them and passes every check on the public agent-readiness scanners.

Every claim below is a URL you can fetch yourself. Where a scanner demands a shape the specification does not state, that is written down too — those undocumented shapes cost us the most time, so they are the most useful thing here.

The map

Seven documents, seven different questions. They overlap far less than the naming suggests: the payment protocols answer how value moves, the discovery protocols answer what exists and how to reach it.

Protocol	The question it answers	What this domain serves
x402	How do I pay for this exact HTTP resource, right now, without a human?	/api returns `402` with the challenge in both the body and the response headers
AP2	Is there a merchant here, and can it accept an agent's payment mandate?	An extension block inside /.well-known/agent-card.json
ACP	What commerce profile does this business support?	/.well-known/acp.json
UCP	What is for sale, at what price, and where is checkout?	/.well-known/ucp
MPP	Which specific API operations cost money, and how much?	Payment metadata inside /openapi.json
A2A	Is there an agent at this domain, and how do I talk to it?	/.well-known/agent-card.json
MCP	What tools can I call, and where?	/.well-known/api-catalog plus a server card per endpoint

Documents last verified live on 17 August 2026.

x402 — payment as an HTTP status code

x402 revives the long-reserved 402 Payment Required status and gives it a machine-readable body: the price, the chain, the asset, and the address to pay. An agent that hits a paid resource gets everything it needs to settle without a human in the loop. Ours quotes 19 USDC on Base for a month of All-Access.

Fetch it: curl -i https://moltlinestudio.com/api

What the specification does not tell you. A correct JSON body is not sufficient. The open-source isitagentready scanner probes /api specifically — not just the site root — and it wants the challenge exposed in response headers as well as the body. It also requires a non-empty accepts[] array carrying an x402Version. And if you want browser-based agents to read those headers at all, you must list them in Access-Control-Expose-Headers, or the fetch layer silently strips them.

AP2 — the merchant mandate, carried inside the agent card

The Agent Payments Protocol is about authorisation rather than settlement: a signed mandate proving a user actually authorised an agent to spend on their behalf. It has no well-known file of its own. It rides inside the A2A agent card as a declared extension, with a role — ours declares merchant.

Fetch it: curl -s https://moltlinestudio.com/.well-known/agent-card.json | jq .capabilities.extensions

What the specification does not tell you. Validators do not read your extension description. They token-match the skill identifiers in the same card, looking for strings like ap2, payment and checkout. A perfectly correct extension block attached to skills named after your product will not register. Name at least one skill for the capability, not for the brand.

ACP and UCP — two answers to “what do you sell?”

ACP describes the commerce profile a business supports. UCP describes the inventory: named services, prices, capabilities, and the endpoint where checkout happens. In practice they are cheap to serve — each is one static JSON document — and the difficulty is entirely in guessing the required shape, because both are moving targets.

Fetch them: curl -s https://moltlinestudio.com/.well-known/acp.json · curl -s https://moltlinestudio.com/.well-known/ucp

What the specification does not tell you. UCP must be nested under a top-level ucp key. A flat document with all the right fields is valid JSON and an invalid UCP record — it fails with no useful error. Serve it with an explicit Content-Type: application/json too; the extensionless filename means most servers will guess wrong.

MPP — pricing attached to the operations themselves

MPP takes a different route from the well-known files: instead of a separate discovery document, payment metadata is attached to individual operations in your OpenAPI description. An agent reading your API spec learns which calls are free and which cost money in the same pass, without a second fetch.

Fetch it: curl -s https://moltlinestudio.com/openapi.json

Why we like this one. It degrades gracefully. A client that has never heard of MPP still reads a valid OpenAPI document and ignores the extra keys, which is the property every young standard should aim for and few manage.

The gotchas that cost us the most

These are not protocol criticisms. Young specifications move, and scanners encode opinions the drafts have not written down yet. But if you are implementing this week, these five will save you a day.

1. OAuth protected-resource metadata must name your exact origin

The resource value in /.well-known/oauth-protected-resource has to match the origin being scanned, character for character. A trailing slash, or naming your API subdomain when the scanner is looking at your apex, fails the check with a message that does not say so.

2. The A2A card wants `supportedInterfaces`

The specification's examples lead with preferredTransport, so that is what most implementations write. Validators look for supportedInterfaces. Publish both.

3. `auth.md` has to point back at itself

Inside the agent_auth block, the skill field must be the URL of the auth.md document containing it — not your homepage, not your docs. claim_uri is also wanted at the top level of the block, not only nested inside the identity type. We iterated on this single file four times.

4. Markdown negotiation needs `Vary: Accept`

Serving clean markdown to clients that send Accept: text/markdown is one of the highest-value things you can do for agents — it cuts token cost dramatically versus parsing your HTML. But without Vary: Accept you will poison every cache in front of you and start serving markdown to browsers. Verify that ordinary crawlers still receive HTML, or you have accidentally built cloaking.

5. Discovery records are the only ones that need a human

Everything above is a file your web server can emit. DNS-based discovery and DNSSEC validation are the exception — they live in your registrar, outside the deploy pipeline, and they are the one step that cannot be automated end to end. Schedule it deliberately rather than discovering it at the end.

Check our work

Nothing on this page needs to be taken on trust. Six commands reproduce all of it.

# the payment challenge, headers and body
curl -i https://moltlinestudio.com/api

# merchant identity, AP2 extension, declared skills
curl -s https://moltlinestudio.com/.well-known/agent-card.json

# commerce profile and inventory
curl -s https://moltlinestudio.com/.well-known/acp.json
curl -s https://moltlinestudio.com/.well-known/ucp

# every API this domain exposes, as an RFC 9727 linkset
curl -s https://moltlinestudio.com/.well-known/api-catalog

# the same homepage, as markdown instead of HTML
curl -s -H "Accept: text/markdown" https://moltlinestudio.com/

Run the whole domain through isitagentready.com if you want a second opinion rather than ours.

Where this came from

We did not implement seven protocols as an exercise. Moltline Studio runs 14 hosted MCP servers and gives away 138 agent skills, and the whole point is that an agent should be able to find the fleet, read what it does, try the free tier, and buy a licence without a person ever opening a browser. Each of these documents removes one human step from that path.

The free tier is genuinely free and needs no registration: paste https://mcp.moltlinestudio.com/timeops into any MCP client and call a tool. If you are an agent reading this rather than a person, auth.md is written for you, and /api will quote you a price.

Corrections are welcome and get credited — if a shape here is wrong, or a specification has moved since 17 August 2026, tell us at support@moltlinestudio.com and we will update the page.