HTTP Is the New MCP – Chris Menz's Blog

There’s a growing push to invent new protocols so AI agents can interact with services and execute tasks on a user’s behalf. While the motivation is right, the direction often feels familiar in an uncomfortable way.

It looks a bit like we’re trying to rebuild the web.

Every time the industry introduces a new “universal protocol,” the same issues appear:

High implementation cost for service providers
All-or-nothing adoption
Tight coupling to specific domains
Fragmentation instead of convergence

Meanwhile, the web already solved the hardest problems.

HTTP already is the substrate

HTTP gives us:

Global and local addressing
A mature security model
Well-known discovery patterns
A deployment model that works everywhere

If something can run locally, it can run over HTTP.
If it can run over HTTP, it can run anywhere.

No new transport required.

The real gap: discoverability for agents

Humans have HTML.
Browsers know how to render it.

Agents don’t.

Agents need a simple, reliable answer to one question:

“What can I do with this service?”

Not a complex runtime protocol, only a capability description that can be discovered predictably.

A small, boring idea

Expose a single file at a well-known location:

/.well-known/uap

This file describes:

What the service offers
How an agent can interact with it
Which actions are safe and which require confirmation

That’s it.

No new execution model.
No agent-to-agent handshake.
No replacement for existing APIs.

Just a thin discovery layer on top of HTTP.

Why it matters

Without this, we’ll end up with dozens of domain-specific agent protocols, each with different assumptions and adoption curves.

With it, we keep:

One web
One transport
One security model
One way for agents to discover capabilities

The claim

So, what about this: HTTP is the new MCP.

We don’t need a new foundation for agents.
We need a small, opinionated way for agents to understand the one we already have.

That’s how the web scaled before, and it might be how agents will scale next.

Example

Let’s look at a very simple example for a hotel service:

{
  "name": "Example Hotel",
  "modules": [
    {
      "id": "booking",
      "description": "Room availability and booking",
      "href": "https://example-hotel.com/.well-known/booking.json"
    }
  ]
}

The modular design allows the agent to only dive into what it really needs:

{
  "name": "Booking",
  "openapi": "https://example-hotel.com/.well-known/openapi.yaml",
  "actions": [
    {
      "id": "rooms.search",
      "description": "Search available rooms"
    },
    {
      "id": "booking.create",
      "description": "Create a booking",
      "confirm": "user"
    },
    {
      "id": "booking.cancel",
      "description": "Cancel a booking",
      "confirm": "user"
    }
  ]
}

Does it work?

I built a simple hello world implementation to test the approach, you can find all the code on my GitHub repository, if you want to try for yourself: https://github.com/christianmenz/uap

Given this hard coded list of rooms:

ROOMS = [
    {
        "id": "room-101",
        "room_type": "queen",
        "price": 129,
        "features": ["wifi", "breakfast"],
    },
    {
        "id": "room-202",
        "room_type": "king",
        "price": 159,
        "features": ["wifi", "ocean_view"],
    },
    {
        "id": "room-303",
        "room_type": "suite",
        "price": 219,
        "features": ["wifi", "breakfast", "balcony"],
    },
]

I can now run something like

python agent/agent.py "Do you find a room below 160?"

Yes—available rooms under **160**:

- **room-101** (queen) — **129** — wifi, breakfast  
- **room-202** (king) — **159** — wifi, ocean_view  

Want me to book one? If so, tell me **check-in/check-out dates** and **guest name**.