# The AI-Ready Web: Why Every Website Needs Both a UI and an API

Every website will soon serve two interfaces — one for humans, one for AI agents. Exploring WebMCP, MCP servers, generative UI, and the architectural shift making websites AI-accessible.

**Published:** March 11, 2026
**Category:** Software Development
**Tags:** AI Development, Web Development, Future of Tech

![The AI-Ready Web: Why Every Website Needs Both a UI and an API](/blog/ai-ready-web/mirror.png)

---

Something strange is happening to the web. We're building a second version of it — not a redesign, not a rewrite, but an entirely parallel layer. One for humans, one for machines. And the interesting part? Most people haven't noticed yet.

Right now, you're reading this article in a browser. You navigated here, scrolled through a page, and your eyes are parsing styled text against a background. That's the human web — the one we've known for thirty years.

But there's another way to read this exact article. Add `.md` to the URL. You'll get the same content, stripped down to plain markdown — no HTML, no styling, no JavaScript. Just structured text, ready to be consumed by an AI agent, a CLI tool, or whatever comes next.

That's not a gimmick. That's a glimpse of where things are heading: every web service eventually serving two interfaces. The visual one you're used to, and a machine-readable one that most users will never see directly — but will interact with constantly through their AI assistants.

## Services Without Interfaces

Rhys Sullivan, an engineer at OpenCode (previously at Vercel), [posted something](https://x.com/RhysSullivan/status/2022466168125267970) that stuck with me:

> By the end of the year, you are going to be interacting with most services through their APIs and your assistant rather than their websites. I think there will also be some services that are purely API only intended to be interacted with just by your assistant.

When I read this, my first reaction was practical — I'd need to rewrite my Server Actions into API endpoints. Rhys's answer was telling: use [oRPC](https://orpc.unnoq.com/), define your business logic once, and it works as both a Server Action (for your UI) and an OpenAPI endpoint (for agents). One source of truth, two consumers.

Since then, Rhys has been building [executor](https://github.com/RhysSullivan/executor) — a local-first execution environment that puts this idea into practice. Instead of pasting large MCP manifests into every chat or giving an agent broad shell access, executor provides a unified tool catalog across MCP servers, OpenAPI APIs, and GraphQL endpoints. The agent discovers capabilities by intent, inspects schemas, and calls typed functions in a sandboxed TypeScript runtime. It's the local control plane for the agent-mediated web — connect your sources once, and every agent interaction goes through a structured, credentialed runtime rather than raw HTTP calls.

But the bigger point isn't about tooling. It's about the direction. We're moving from a world where the primary consumer of a web service is a human with a browser to one where it's an AI agent with an API client.

This isn't hypothetical. Stripe already shipped an [Agentic Commerce Suite](https://stripe.com/blog/agentic-commerce-suite) — a set of APIs designed specifically for AI agents to complete purchases autonomously. They co-developed an [Agentic Commerce Protocol](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol) with OpenAI. You can literally say "buy that" inside ChatGPT and Stripe handles the transaction end-to-end, no website involved.

Cloudflare went even further. They shipped a [Code Mode MCP server](https://blog.cloudflare.com/code-mode-mcp/) that exposes their entire platform — over 2,500 API endpoints — to AI agents. Not through a dashboard plugin or a browser extension. Through a server-side interface where the agent writes JavaScript against a typed API spec, executing in a sandboxed V8 isolate. Infrastructure management, fully agent-driven.

The API-only business isn't a prediction. It's already shipping.

## WebMCP: The Right Idea, Wrong Layer?

Google and Microsoft clearly see the same future. They've co-authored a [W3C proposal called WebMCP](https://webmachinelearning.github.io/webmcp/) — a browser API that lets websites declare structured, callable tools for AI agents.

The concept is elegant: instead of an AI agent screen-scraping your website or parsing DOM elements to figure out what buttons to click, your site explicitly tells the agent: "Here are the things you can do, here are the parameters, here's the schema." The agent calls a typed function. No pixel-parsing, no guesswork.

I built a [demo project](https://github.com/Mark-Life/webMCP-example) to test this — a task manager app using Next.js and oRPC, with WebMCP tool registration bridging the two. It works. Chrome 146 Canary already ships an early implementation behind a flag. You can install the [MCP-B Chrome extension](https://chromewebstore.google.com/detail/user-agent-mcp-bridge-mcb/jjjhcbnkhgagjckfpmmjmjddgoijkplm) and interact with any WebMCP-enabled site through an AI agent.

But here's my problem with it: **WebMCP requires a browser.**

The agent must visit a rendered page to discover available tools. It runs within the browser's JavaScript context. This makes sense for one specific use case — agentic browsing, where an AI controls a browser tab on your behalf. But that's not how most agent interactions actually work or will work.

Think about it. If you're asking Claude Code to interact with a service, there's no browser. If a background agent is processing your emails and booking meetings, there's no browser. If an API-only service exists purely for agent consumption — the kind Rhys predicts — there's no browser to render anything in.

WebMCP solves a real problem (structured agent-website interaction) but anchors the solution to the wrong layer (the browser rendering engine). What agents actually need is simpler: a server-side endpoint that describes available capabilities and accepts typed calls. That's... just OpenAPI. Or an MCP server. We arguably already have the tools; we just need the adoption.

It's telling that Cloudflare — a company that literally runs browser infrastructure — chose to go fully server-side with their agent interface. No browser rendering, no DOM, just typed API access in a sandbox. If anyone had reason to bet on the browser layer, it was them. They didn't.

## The Agentic Browser That Nobody Switched To

There's a related observation that reinforces this. In 2025, we saw a wave of "agentic browsers" — Perplexity's Comet, OpenAI's Atlas, Microsoft Copilot in Edge. The pitch: your browser has a built-in AI that can navigate, fill forms, click buttons, and complete tasks for you.

And yet... I haven't switched. You probably haven't either. I use Chrome on desktop, Safari on mobile — like most people. When I need an agent to interact with the web, I use tools designed for it — direct API calls, MCP servers, or simple HTTP requests to structured endpoints.

The reason is subtle but important. Agentic browsing treats the existing visual web as the source of truth and puts an AI layer on top of it to interpret and navigate that visual layer. It's a workaround. It says: "The web was built for humans, so let's teach an AI to pretend to be a human using it."

That's the wrong abstraction. Instead of teaching agents to navigate human interfaces, we should give agents their own interfaces to the same services. The data and capabilities are the same — the access layer is different.

## What Actually Works Today

Here's what I've found actually works for making a web service agent-accessible, without waiting for standards bodies or new browsers:

**For content-heavy sites:** serve a markdown version of every page. On my website, adding `.md` or `.txt` to any URL returns clean markdown. Sending an `Accept: text/markdown` header does the same. This is trivially simple to implement, requires zero special infrastructure, and works with every AI tool that can make HTTP requests.

It also enables concrete features for human users: "Copy as Markdown" and "Open in ChatGPT" buttons on every page. The agent layer and the human layer share the same content, accessed differently.

**For application-heavy sites:** expose your business logic as an OpenAPI spec. Tools like oRPC let you define a procedure once and use it as both a Server Action (for your React UI) and as a documented API endpoint (for agents). The agent doesn't need to "visit" your site — it reads your API spec, understands your capabilities, and calls them directly.

A good example of this in the wild: [Flashcards](https://flashcards-open-source-app.com/), an open-source spaced repetition app built by [Kirill Markin](https://github.com/kirill-markin). It exposes a [discovery endpoint](https://api.flashcards-open-source-app.com/v1/) that gives an AI agent everything it needs — authentication flow, available capabilities, OpenAPI spec — to sign up, create an account, and manage flashcard workspaces autonomously. You give your agent the discovery URL, confirm an email code, and it handles the rest. This is what an agent-first API looks like in practice: the web UI exists, but the API is the primary interface.

**For discoverability:** this is where it gets interesting, because the right approach depends on scale.

## The Discovery Problem: Scale Changes Everything

Making your API agent-accessible sounds simple — just expose a spec. But in practice, there's a spectrum, and the right pattern depends on how many capabilities you're exposing.

**Small surface (5–15 tools):** Most web apps fall here. A task manager, a recipe site, a SaaS dashboard. For these, the agent can consume the entire API spec in one shot and generate typed tools from it. This is the pattern I'm exploring with [OpenTools](https://github.com/Mark-Life/OpenTools) — a specification that extends OpenAPI with `x-llm` metadata (approval requirements, rate limits, natural-language hints for when to use each action) and makes the whole thing auto-discoverable via a `/.well-known/llm.json` endpoint. The agent fetches the manifest, reads the spec, generates tools dynamically, and starts calling them — no MCP server setup, no plugin installation, just a URL. Think of it as `robots.txt` for AI agents, but instead of telling crawlers what to index, it tells agents what they can *do*.

**Large surface (hundreds or thousands of endpoints):** Here, the "just read the spec" approach breaks down. Cloudflare learned this firsthand — their API has over 2,500 endpoints, which would consume 1.17 million tokens as a raw OpenAPI spec. No model can hold that in context. Their solution was [Code Mode](https://blog.cloudflare.com/code-mode-mcp/): instead of exposing thousands of individual tools, they give the agent just two meta-tools — `search()` to query the spec and find relevant endpoints, and `execute()` to call them. The agent discovers capabilities progressively, writing JavaScript against a typed API rather than consuming the whole schema upfront. Fixed token cost regardless of API size.

These aren't competing patterns — they're complementary. For most web applications, direct spec consumption works fine and keeps things simple. For platforms with massive API surfaces, progressive discovery is the way. Either way, the solution is server-side, typed, and doesn't require a browser.

These also aren't futuristic proposals. They're patterns you can implement today with existing tools. And they work with every type of agent — browser-based, CLI-based, embedded in chat interfaces, or running autonomously in the background.

## The Output Side: Generative UI

So far I've been talking about the input side — how agents access services. But there's an equally interesting shift happening on the output side: how agents present results to users.

Vercel Labs recently released [json-render](https://github.com/vercel-labs/json-render), a framework by Chris Tate where AI generates constrained JSON specs that map to pre-defined UI components. The developer defines a catalog of allowed components (cards, tables, charts, metrics) with typed props. The LLM composes from that vocabulary. A renderer turns the JSON into actual React (or React Native) components.

This is significant because it reframes who designs the UI. Traditionally, every user sees the same dashboard, the same layout, the same arrangement of information. With generative UI, the interface adapts to the user's specific question or context. Ask for revenue data, and you get a dashboard with charts. Ask for a customer list, and you get a filterable table. The same backend, rendered differently each time.

But there's a practical constraint worth thinking about: token cost. If you want to render a table with 500 rows, you don't want the LLM generating that data token by token. The smart pattern is for the model to generate *structure* — "render a table component with this data source" — and let the client-side renderer handle the actual data population. Pass a reference to the data, not the data itself.

This is where json-render's approach shines. The LLM produces a lightweight JSON spec — maybe 2,000 tokens — that describes *what* to render. The heavy lifting (fetching data, rendering components, handling interactions) happens locally, outside the generation loop.

Google is working on something similar with [A2UI](https://github.com/google/A2UI) — a protocol for agents to describe UI across trust boundaries. The difference: json-render is a tool (AI as a feature inside your app), while A2UI is a protocol (AI as a remote entity generating UI for a host application). Both point to the same future.

## The Duality

Here's where I'm genuinely uncertain, and I think that uncertainty is worth admitting.

On one hand, the trajectory seems clear: agents will increasingly mediate our interactions with online services. The protocols are emerging (MCP, WebMCP, A2A, ACP). The infrastructure is being built (oRPC, json-render, agentic commerce APIs). Major companies are betting on it.

On the other hand... people still use regular websites. I still use regular websites. Muscle memory is powerful. When I want to check my bank balance, I open the bank's app — I don't ask an AI to query their API. When I want to buy something on Amazon, I browse. The behavioral shift required for the "agent-first" web is enormous, and humans change habits slowly.

I think what we'll see isn't a replacement but a stratification. Some interactions will move to agents quickly — repetitive tasks, multi-service workflows, data retrieval. Others will stay visual for a long time — browsing for inspiration, social media, content consumption where the UI *is* the experience.

The implication for builders is that you need to serve both. Your website still needs to be a great visual experience for humans. But it also needs a machine-readable layer — API endpoints, structured data, markdown export, capability declarations — so that when someone's AI assistant comes knocking, it can interact with your service without pretending to be a human clicking buttons.

## What This Means for Developers

If you're building web applications today, the practical takeaway is straightforward:

**Think in two layers.** Your visual UI layer serves humans. Your API/data layer serves both humans and agents. Design the API layer first, then build the UI on top of it. This is good architecture regardless of the agent trend — but the agent trend makes it mandatory.

**Expose your capabilities.** If your app has functionality, make it callable. For most apps, an OpenAPI spec with agent metadata at a well-known URL is enough — agents can consume it directly and generate tools. For large platforms, consider progressive discovery patterns like Cloudflare's Code Mode. Either way, the businesses that are machine-discoverable and machine-callable will have a massive advantage — the same way SEO-optimized sites had an advantage when Google became the primary way people found things online.

**Don't over-invest in agentic browser compatibility.** WebMCP is interesting to watch but the spec is unstable and the browser-centric approach has fundamental limitations. Your time is better spent making your server-side APIs clean and well-documented.

**Consider your content.** If your site has valuable content (articles, documentation, product information), serve it in plain text or markdown alongside the HTML version. It's simple, it costs nothing, and it makes your content immediately accessible to every AI tool on the market.

## Where I Think This Goes

I don't think we end up with one AI assistant that rules everything. We'll end up with something closer to the social media landscape — people use different platforms for different purposes. TikTok for entertainment, LinkedIn for professional networking, Twitter for real-time discourse. AI assistants will stratify the same way. You might use Claude for coding, ChatGPT for general tasks, Gemini for things deeply integrated with Google's ecosystem. People will have preferences, loyalties, workflows built around specific providers. The "one agent to rule them all" scenario is as unlikely as "one social network for everything" — we've seen how that plays out.

In the near term, the shift is clearest for transactional interactions. Anything you do today that involves opening an app, clicking through a workflow, and closing it — checking a balance, booking a flight, filing an expense, managing a subscription — will move to agents. Nobody enjoys those UIs. They exist because there was no alternative. Now there is.

The experience-first web survives. Browsing for inspiration, consuming content, social media — these stay visual because the interface *is* the product. You don't ask an agent to scroll Instagram for you. The utilitarian middle is what gets eaten.

But if I'm being honest about the longer arc, there's a more radical disruption waiting. We're currently bolting agent capabilities onto existing systems — adding API layers to websites, connecting assistants to services through protocols. The infrastructure of the web, the browser, the operating system — all of it was designed around the assumption that a human is directly manipulating a visual interface.

What happens when someone builds an operating system that doesn't make that assumption? An OS where the primary interface is an LLM-driven agent, where UI is generative — composed on the fly from the user's intent rather than pre-designed by a product team, where every application is just a set of callable capabilities that the system orchestrates and renders as needed. Not an AI layer on top of a traditional OS, but an OS built from the ground up around the agent paradigm.

That's the real disruption. Everything I've described in this article — the dual interfaces, the discovery protocols, the progressive API access — is a transition pattern. It's how we get from the human-first web to something fundamentally different. The question isn't whether it happens, but whether the transition is gradual enough for people to adapt, or whether someone ships the paradigm shift all at once and forces the industry to catch up.

Either way, the web isn't dying. It's growing a second nervous system — one designed for machines. The sites that develop both will thrive. The ones that remain human-only will gradually become invisible to an increasingly agent-mediated world.

That's not a threat. It's just the next layer.

---

## Links

- Blog post: https://andrey-markin.com/blog/ai-ready-web
- All blog posts: https://andrey-markin.com/blog
- Contact: https://andrey-markin.com/#contact