If you have tried to make a website work with AI assistants recently, you have run into the fragmentation. Depending on the platform, you are looking at MCP, WebMCP, ACP, product feeds, OAuth flows, framework-specific tooling, and whatever ships next. Each solves a real slice of the problem. But a site ends up implementing and maintaining several of them separately, per assistant, and re-doing it every time a new protocol appears.
The web was built for humans. Agents should not have to scrape HTML and guess at your forms. So I built AI2Web to test a different approach: describe your site's capabilities once, and expose them through whichever protocol an AI platform speaks.
The shape of it
A site publishes a small, machine-readable manifest:
GET /.well-known/ai2w discovery anchor
GET /ai2w the capability manifest
POST /ai2w/negotiate agree a capability set + transport
From that one description, you generate MCP, GraphQL, ACP, OpenAPI and feeds. You do not rebuild for each assistant. When a new protocol wins, you add an adapter, not a rewrite.
It is explicitly not a replacement for MCP or ACP. It sits above them as an interoperability layer. The bet is that the capability model is the durable part, and the transports are adapters.
Try it in a minute
# score any live site's AI readiness
npx -p @ai2web/validator ai2web validate https://ai2web.dev
# or build a manifest in code
npm install @ai2web/core
import { ai2web, validateManifest } from "@ai2web/core";
const manifest = ai2web({ name: "Acme", url: "https://acme.example", type: "ecommerce" })
.capability("content")
.capability("commerce", { checkout: true })
.build();
console.log(validateManifest(manifest).score); // AI Readiness Score /100
What exists today (it is early, v0.1)
- An open spec, RFCs and a conformance suite
- SDKs you can install now:
@ai2web/core (and PHP, Python, Go and .NET)
- A framework-agnostic server (Node and Cloudflare Workers) and a WordPress/WooCommerce plugin
- Reference adapters that generate MCP, GraphQL, ACP and OpenAPI from one manifest, all routing through one guarded executor
- A live validator (CLI, web, and an MCP tool) and a live discovery service
- Safe by default: discovery is read-only, and anything that moves money or data is risk-tiered and returns a preview for user approval before it runs
What I want to know
I am not trying to win a standards race. I am trying to make the AI-ready web simple enough that developers actually want to build it. Whether that abstraction holds, or leaks so badly you would rather just implement MCP directly, is exactly the question I cannot answer alone.
If you build websites, AI agents, or the tools in between, I would value your criticism:
- If you already ship MCP, does a capability layer above it earn its keep, or is it just another abstraction to maintain?
- What would actually stop you from adopting it?
It is open source (code MIT, spec CC-BY).
Describe once. Works everywhere. That is the whole idea.