Architecture · why not MCP

MCP is the right adapter. Not the right foundation.

OpenKarta runs on plain HTTP — eight verbs, signed quotes, a registry of verified merchants. MCP is a brilliant way for AI assistants to call tools, but it is not a trust framework, not a shared directory of merchants, and not what most websites or apps speak. So we ship MCP as the bridge — not the floor.

See the architecture → Why a registry →

The bottom line

You don’t pick HTTP or MCP. OpenKarta gives you both.

HTTP for everyone — websites, mobile apps, server jobs, any agent. MCP as the adapter that lets Claude, Cursor, and ChatGPT shop the same registry. One protocol. Two doors. No rewrite.

01 · Why not the foundation

Five reasons MCP isn’t the layer to build commerce on.

Transport ≠ trust framework.

Building on MCP means rebuilding every safety guarantee OpenKarta cares about — on top of someone else’s tool-calling format.

Read the technical detail ▾

OpenKarta is not "another way to call a tool." It is eight behavioural commitments — signed quote tokens, idempotent checkout, closed-enum errors, conformance badges, a registry of verified merchants. MCP gives you none of those. Building on MCP means re-implementing every primitive on top of its tool-calling format — coupled to a still-moving protocol surface owned by someone else.

MCP is LLM-client-bound. Your audience isn’t.

MCP only works inside AI assistants. Most of the internet — websites, mobile apps, server jobs — speaks HTTP.

Read the technical detail ▾

OpenKarta v1 serves four consumer surfaces: web app, mobile, server-side automation, and LLM agents. MCP only reaches the last one. HTTP is the universal layer every other surface speaks natively. Forcing a website to talk MCP just to fetch a product list would be absurd; HTTP-first means every surface is a first-class citizen.

Server-per-merchant. Commerce needs a many-merchant registry.

MCP has no shared address book. Every shopper would have to manually configure every shop they want to buy from.

Read the technical detail ▾

MCP discovery is "the user already configured this server." There is no neutral registry, no fan-out search, no signed badge re-verified weekly. A pure-MCP world means every Claude Desktop user pasting a separate JSON config for each brand they want to shop from. That is not a protocol — that is a directory problem.

AI is a moving target. We refuse to bet on one vendor.

OpenKarta is deliberately model-agnostic — works with OpenAI, Anthropic, Mistral, local models. Building on MCP would lock us back into one ecosystem.

Read the technical detail ▾

OpenKarta keeps its core decoupled from any single AI vendor — bring your own model. Adopting MCP as the foundation would re-couple us to a roadmap and governance owned by one company. We would rather ship an adapter for that ecosystem than make it the load-bearing layer of agent commerce.

Merchant adoption math doesn’t favor MCP.

Merchants already run HTTP servers. Asking them to stand up an MCP server is asking them to do new ops work for a small audience.

Read the technical detail ▾

"Add a few HTTPS routes to your existing API" is something every hotel chain, airline, or D2C brand can already do — their ops team runs HTTP services for breakfast. "Stand up an MCP server" is a foreign deployment shape with a smaller payoff. MCP is easier for LLM tool authors. HTTP is easier for the people we actually need to ship: the merchants.

02 · The honest counterpoint

Where MCP genuinely wins.

Distribution into LLM clients

One config and your agent can shop across every OpenKarta-listed merchant.

A user with Claude Desktop, Cursor, Windsurf, or OpenAI’s MCP support installs a single MCP host configuration and gains commerce capability across the entire registry. That is a real adoption advantage, and we would be silly to leave it on the table. So we ship an adapter, not a re-platform.

03 · The right architecture

HTTP is the foundation. MCP is the bridge.

reception agents · 8 verbs · HTTP · text

                     ┌─ Web app                           (HTTP)
                     │
                     ├─ Mobile                            (HTTP)
                     │
Reception agents ────┼─ Server automation                 (HTTP)
   8 verbs · HTTP    │
                     └─ @openkarta/mcp-bridge ──MCP──▶  Claude · Cursor
                              │                          ChatGPT · any host
                              │
                              ▼
                  Hosted registry · signed quotes
                  conformance badges · audit trail

One bridge package

@openkarta/mcp-bridge exposes the 8 verbs as MCP tools, points at the hosted registry, forwards the user’s BYO LLM key, and surfaces signed quotes as tool results.

What stays HTTP

Conformance badges. Quote signing. Domain verification. The registry itself. Anything a non-LLM client needs to call.

What merchants do

Nothing different. They expose 8 HTTP routes once. Every MCP host on Earth benefits via the bridge.

04 · The verdict

HTTP first. MCP next. Convergence later, maybe.

“HTTP is the right foundation. MCP is the right first-class adapter — and probably the highest-leverage missing piece for developer adoption right now.”

Today

Ship @openkarta/mcp-bridge. A few hundred lines on top of the orchestrator already in production. Every Claude / Cursor / ChatGPT user can shop the registry without editing LLM config.

12–18 months

If MCP ships its own commerce profile — signed quotes, idempotency, conformance — we contribute the eight verbs upstream. OpenKarta becomes the commerce profile of MCP. That is a merge case, not a rebuild.

Build on the foundation that already won. Bridge into the AI tools your users already live in.

Read the specification Why a registry Developer quickstart