Laxmikant Sharma

[writing]

The Agentic Web Is Being Wired Right Now: A Field Guide to MCP, A2A, Skills, and Agent Payments

A field guide to the protocols wiring the agentic web: MCP for tools, A2A for agent-to-agent work, Skills for know-how, and the three-way fight over payments.

[agents][protocols][agentic-web]

Part 1 of the agentic-web series. Continue with Part 2, Part 3, and Part 4.

An AI agent that can only chat is a demo. An agent that can do things needs plumbing: a way to reach tools, talk to other agents, carry know-how, and pay. Two years ago that plumbing didn’t exist as a standard. Today it’s a stack of open protocols — moving weekly, and increasingly the layer your architecture decisions depend on.

The Agent Interoperability Stack — four problems, four protocol families, one shared discovery substrate

How we got here in 24 months

Anthropic open-sourced MCP (November 2024) for tools; Google answered with A2A (April 2025) for agent-to-agent work; payments arrived through 2025 (Coinbase’s x402, Google’s AP2, OpenAI + Stripe’s checkout standard); Anthropic shipped Agent Skills with Claude in October 2025 and published SKILL.md as an open, cross-platform standard that December. The discovery layer evolved in parallel and is still moving: MCP’s SEP-1649 ratified a card at /.well-known/mcp.json, its successor SEP-2127 is converging on /.well-known/mcp/server-card.json, and A2A’s card moved from agent.json to agent-card.json before gaining signatures in v1.0. Along the way, most of it — MCP, A2A (absorbing IBM’s ACP), AGNTCY, the x402 Foundation — moved under the Linux Foundation: the clearest signal this is shared infrastructure, not any vendor’s moat.

The Agent-Protocol Boom — a 24-month timeline from MCP to a converging agentic web

Problem 1 — Reaching tools and data: MCP

MCP is “the USB-C for AI”: write an integration once, and any MCP-aware client (Claude, Cursor, VS Code…) can use it. The architecturally interesting part is discovery — how a client vets a server before connecting, via a self-describing card:

// GET https://api.example.com/.well-known/mcp/server-card.json
{
  "protocolVersion": "2025-06-18",
  "serverInfo": { "name": "example-crm", "title": "Example CRM",
                  "version": "1.4.0" },
  "transport": { "type": "streamable-http", "endpoint": "/mcp" },
  "capabilities": { "tools": { "listChanged": true }, "resources": {} },
  "tools": [{
    "name": "search_contacts",
    "description": "Search CRM contacts by name, company, or email",
    "inputSchema": {
      "type": "object",
      "properties": { "query": { "type": "string" },
                      "limit": { "type": "integer", "default": 10 } },
      "required": ["query"]
    }
  }],
  "authentication": { "type": "oauth2" }
}

The card can embed the server’s actual tool definitions — names, descriptions, JSON-Schema inputs — which is what makes pre-connect vetting real: registries can index tools, and security scanners can statically classify tool descriptions (prompt-injection screening included) before any client connects. Note the churn: SEP-1649 ratified /.well-known/mcp.json; its successor SEP-2127 (an active draft) moved to /.well-known/mcp/server-card.json. An official MCP Registry (preview since September 2025) indexes servers at scale.

Problem 2 — Talking to other agents: A2A

When agents delegate to each other across vendors, A2A is the wire. Its core artifact is the Agent Card at /.well-known/agent-card.json — a JSON “business card” doing three jobs at once: identity, résumé, and API contract.

// GET https://acme.ai/.well-known/agent-card.json
{
  "protocolVersion": "1.0",
  "name": "Acme Travel Agent",
  "description": "Books flights and hotels",
  "url": "https://acme.ai/a2a",
  "preferredTransport": "JSONRPC",
  "capabilities": { "streaming": true },
  "securitySchemes": { "oauth2": { "type": "oauth2" } },
  "skills": [{
    "id": "book-flight",
    "name": "Book a flight",
    "description": "Finds and books flights within constraints",
    "tags": ["travel", "booking"],
    "examples": ["Book SFO→NYC next Friday under $500"],
    "inputModes": ["text"], "outputModes": ["text"]
  }],
  "supportsAuthenticatedExtendedCard": true,
  "signatures": [{ "protected": "eyJhbGciOi...", "signature": "MEUCIQ..." }]
}

The AgentSkill objects are what registries index and LLM routers rank; supportsAuthenticatedExtendedCard splits the public shingle from a richer private catalog revealed after auth; and signatures (JWS over a canonicalized card, new in v1.0) makes the card tamper-evident through caches and relays. A2A also absorbed IBM’s rival ACP under the Linux Foundation — consolidation, not fragmentation. (Part 2 dissects the card and its trust model in depth.)

Problem 3 — Carrying know-how: Agent Skills

Tools tell an agent what it can touch; Skills tell it how your organization works. A Skill is a folder with a SKILL.md — YAML frontmatter plus instructions and optional scripts. The elegant idea is progressive disclosure: agents preload only each Skill’s name and description, loading the body on demand — hundreds of Skills, no context bloat. An open standard since December 2025, running across 20+ platforms; a Skill written once is portable across agents, which makes your Skills reusable IP.

Problem 4 — Paying: AP2, ACP, and x402

The messiest frontier — three overlapping efforts, each with a different center of gravity.

AP2 (Agent Payments Protocol) — Google’s open standard, launched September 2025 with 60+ partners (Mastercard, PayPal, Amex, Coinbase). Its trust model is a chain of signed mandates, each a selectively disclosable SD-JWT credential (RFC 9901): an Intent Mandate (“concert tickets ≤ $150, before Friday”), a Cart Mandate (the exact approved order), and a Payment Mandate that tells the network an agent was involved and whether the human was present. The asymmetry is the design insight — human watching? The strong signature lands on the final cart. Human absent? A detailed intent is signed up front and the agent closes within its bounds:

// AP2 Intent Mandate (human-not-present) — the user's signed "contract"
{
  "intent_mandate": {
    "natural_language_description": "Concert tickets, max $150, before Friday",
    "merchants": null,                      // any merchant allowed
    "requires_refundability": true,
    "intent_expiry": "2026-07-24T00:00:00Z",
    "user_cart_confirmation_required": false  // agent may close the cart
  },
  "user_authorization": "eyJhbGciOi..."     // user-signed SD-JWT credential
}

It’s already reaching real rails: Mastercard Agent Pay ran its first authenticated agentic transaction in Q3 2025, and Visa’s Intelligent Commerce Connect targets GA in June 2026.

Agentic Commerce Protocol — OpenAI + Stripe’s merchant-centric standard powering ChatGPT’s Instant Checkout. OpenAPI-specified, date-versioned (in beta since 2025-09-29), built around a Delegate Payment spec: the buyer’s agent passes a scoped, single-use payment token (Stripe’s Shared Payment Token) authorized for a specific amount and merchant — so the merchant stays the merchant of record and the agent never holds raw card data.

// ACP delegate_payment — mint a scoped, single-use token
POST /agentic_commerce/delegate_payment
{
  "payment_method": { "type": "card", "number": "4242…", "exp_month": "11" },
  "allowance": {
    "reason": "one_time",
    "max_amount": 15000, "currency": "usd",    // ≤ $150.00, cents
    "merchant_id": "merchant_123",             // this merchant only
    "expires_at": "2026-07-22T12:00:00Z"
  },
  "risk_signals": [ { "type": "card_testing", "score": 5 } ]
}
// → { "id": "vt_abc123" }  — the only thing the agent ever carries

x402 — Coinbase’s revival of the dormant HTTP 402 Payment Required status code, now run by an independent x402 Foundation under the Linux Foundation (40 members including AWS, Visa, Cloudflare). The flow is HTTP-native: server responds 402 with payment requirements, client retries with a signed payment header, a facilitator verifies and settles in stablecoins — machine-speed micropayments with no accounts:

GET /api/market-report          → 402 Payment Required
{ "x402Version": 1, "accepts": [{
    "scheme": "exact", "network": "base",
    "maxAmountRequired": "10000",              // 0.01 USDC, atomic units
    "payTo": "0xAbC…", "asset": "0xA0b8…",     // USDC contract
    "resource": "/api/market-report", "maxTimeoutSeconds": 60 }] }

GET /api/market-report
X-PAYMENT: eyJzaWduYXR1cmU…                    // signed payment payload
→ 200 OK  + X-PAYMENT-RESPONSE (settlement receipt)

A Google-backed A2A x402 extension already wires it in as a settlement rail beneath A2A/AP2.

They compose rather than compete head-on: AP2 supplies the authorization evidence, ACP the merchant checkout rail, x402 the HTTP-native settlement. One sticky-note warning: “ACP” means three unrelated things — Agent Communication (IBM, merged into A2A), Agentic Commerce (OpenAI/Stripe), Agent Connect (Cisco AGNTCY). Always disambiguate.

The pattern underneath: .well-known is quietly becoming the spec

Every protocol above converges on the same move: fetch a self-describing card from a well-known URL, verify who published it, then speak its native protocol.

The .well-known handshake — fetch a self-describing card, verify identity, then connect

This isn’t a convention the agent world invented — /.well-known/ is a formal IANA registry (RFC 8615), and the agent specs are just registering new tenants in the table that already holds the web’s auth plumbing. That’s why agents don’t reinvent login: an MCP server is a standard OAuth resource server, and an agent bootstraps everything from the base URL alone — server card for capabilities, 401 → /.well-known/oauth-protected-resource (RFC 9728) → /.well-known/oauth-authorization-server (RFC 8414) for the token, then connect.

Discovery-first — how an AI agent bootstraps an MCP server through a chain of .well-known documents

The next fight is already visible here: a cross-protocol draft of ai-catalog.json would let one domain advertise all its agents, servers, and skills; Google’s ARD spec (June 2026) layers registries and trust on top. Discovery and identity — not the protocols — are the unsettled frontier. Also circling: ANP and MIT’s NANDA (decentralized identity), Cisco’s AGNTCY, and MCP Apps (tools returning interactive UI).

What this means if you’re building

  • Adopt MCP now — the mature, safe bet; the cheapest way to make your systems agent-usable.
  • Design for A2A, deploy later — model capabilities as skills today so exposing an Agent Card is trivial tomorrow.
  • Treat Skills as reusable IP — likely more durable than any model choice.
  • Watch payments, don’t commit — pilot behind an abstraction; AP2 vs. ACP vs. x402 is unsettled.
  • Reuse the web’s auth plumbing — ship MCP servers as OAuth 2.1 resource servers (RFC 9728), never bespoke agent auth.
  • Build to the pattern, not the filename — mcp.json → mcp/server-card.json; agent.json → agent-card.json. Wrap discovery behind your own interface so spec churn is a config change.

We’re watching the early web’s standardization arc replay — messy, vendor-driven, then consolidated under neutral governance. The teams treating these protocols as strategic infrastructure now are the ones whose agents will actually participate when the wiring is done.

Part 2 goes beneath the protocols: identity, delegation, and why an OAuth token is nowhere near enough for an autonomous agent. What are you betting on — MCP-first, A2A-ready, or waiting for the dust to settle?

Correction (2026-08-09): AP2’s mandates are selectively disclosable SD-JWT credentials (RFC 9901) presented over OpenID4VP, not W3C Verifiable Credentials as this piece originally said, and the Intent / Cart / Payment Mandate vocabulary shown here is AP2 v0.1; v0.2 reworked it. AP2 stewardship moved to the FIDO Alliance in April 2026. The LinkedIn original preserves the earlier text.

References