AI2Web Review: Open Interoperability Layer for AI-Ready Websites (2026)

Opening

AI assistants are starting to shop, book, and answer questions on your behalf. Most websites still meet those agents the worst way possible: scrape the HTML, guess at forms, invent a brittle connector, then rebuild the same work when the next assistant or protocol shows up.

AI2Web is an open answer to that mess. You describe your site once in a capability manifest at /ai2w. AI2Web positions itself as the interoperability layer above the transports—projecting that single description to MCP, ACP, REST, GraphQL, OpenAPI, feeds, and related surfaces, with discovery, validation, and action governance built in. It is not “another chatbot for your homepage.” It is infrastructure for making a website understandable and actionable to agents without treating the DOM as an API.

This AI2Web review is based on the public site and docs at ai2web.dev, the ai2web-spec repository, Foundation positioning docs and whitepaper in ai2web-foundation/docs, Roland Farkas’s DEV Community write-up, the privacy policy, related open repos (SDKs, validator, WordPress plugin, Chrome extension, cloud workers, discovery network), and the Launchpadly listing (/startup/ai2web). We did not operate a multi-vendor agent fleet in production or certify the security claims beyond what the project publishes.

Disclosure: Independent Launchpadly editorial—not a sponsored endorsement. The protocol is early (draft); manifests, scores, and SDK APIs can change before v1.0. Confirm current docs and the live validator before you ship.

Key takeaways

• AI2Web is an open interoperability layer for AI-enabled websites: one capability model, many protocols—not “MCP-only for sites.”
• You publish a manifest at /ai2w, add a required /.well-known/ai2w discovery anchor, then validate readiness (score out of 100) and optionally expose MCP/other transports.
• Licensing is public and free: spec/RFCs CC-BY 4.0, reference SDKs MIT. No paid plan page—cost is engineering time, not a seat fee.
• Tooling includes multi-language SDKs, @ai2web/server, MCP bridge packages, a WordPress plugin, a Chrome readiness checker, a web/CLI validator, and a network connector at https://connector.ai2web.dev/mcp.
• AI2Web’s brand line is consistent everywhere: “Describe your website once. AI2Web makes it understandable to every AI.” Externally it insists it is not “the MCP for websites.”
• Stewardship split is public: open AI2Web Foundation (spec, SDKs, validator) and a commercial platform layer from Polarize Ltd (hosted cloud, analytics, enterprise).
• Best fit: teams who want agents to negotiate capabilities against a contract. Weaker fit: marketers who only want an AI chat widget, or teams unwilling to maintain endpoints and auth for real actions.

What is AI2Web?

AI2Web is both a protocol (ai2w) and a framework of reference implementations under the AI2Web Foundation (founder: Roland Farkas, also listed on Launchpadly). The spec README states the boundary clearly: AI2Web deliberately does not invent a transport. It rides MCP, REST, feeds, and friends, then negotiates which path to use. When a new transport wins, you add an adapter instead of rewriting the site’s “AI API” from scratch.

The one primitive everything hangs off, per the Foundation:

Capability Model → Framework (@ai2web/*) → Discovery Network → Analytics

The capability model is the product. Frameworks, discovery, and analytics are downstream.

Practically, a site declares modules such as content, commerce, search, events, and actions; declares transports (MCP, REST, …); declares auth (including OAuth2 + PKCE) and consent (for example, user approval required for purchase); then serves that contract at /ai2w. Assistants can find AI-ready sites, describe capabilities, and call actions—ideally without scraping.

If you searched for an AI2Web review, an AI-ready website protocol, an MCP layer for websites, or a way to avoid per-assistant rebuilds, that contract-first story is what you are evaluating.

Brand, naming, and voice

AI2Web is unusually deliberate about what it is called—and what it refuses to be called. The Foundation’s public positioning doc is the source of truth; site copy, GitHub org README, and the DEV post all rhyme with it.

The tagline (repeated across site, org README, whitepaper):
“Describe your website once. AI2Web makes it understandable to every AI.”
Short form in Farkas’s DEV post: “Describe once. Works everywhere.”

The anti-tagline (also repeated):
Not “the MCP for websites.” That phrase is banned on purpose. MCP is treated as plumbing—tool invocation once you already know a server—not as a whole-business description layer. AI2Web wants to sit above transports the way a browser sits above HTTP/1.1, HTTP/2, HTTP/3, WebSockets, and WebRTC: one experience, many wires. Another metaphor they use: protocol specs solve connection; AI2Web aims to be closer to “what Search Console should have been for search”—validation, monitoring, and operations in one place—without competing with the protocols themselves.

Naming stack (do not collapse these):

Name	What it is
AI2Web	Product / project brand: protocol + spec + framework + reference implementations
ai2w	Protocol identifier (manifest field protocol: "ai2w")
AI2Web Foundation	Steward of the open standard, RFCs, SDKs, validator
Polarize Ltd	Commercial platform layer (AI2Web Cloud, capability-level analytics, enterprise gateway, Discovery-Network-Pro, certification/consulting)—named on the Foundation README
Discovery Network	Indexed AI-ready sites (public metadata only); renamed from a passive “Directory” framing
AI Readiness Score	Validator output /100—positioned as a primary product surface, not a toy badge
Polarize (analytics lane)	Downstream “measurement against the model” in the Capability → Framework → Discovery → Analytics spine

What the brand says it is not: an AI commerce plugin (commerce is one module among equals; checkout-in-ChatGPT-style programs are treated as already commoditised), a new wire protocol that replaces MCP, or an opening pitch of “the new standard for the AI web” before a working demo earns it.

Voice: engineer-to-engineer, anti-hype, slightly austere. The DEV post is revealing: Farkas writes that he is not trying to win a standards race; he wants the AI-ready web simple enough that developers actually build it—and explicitly asks whether the abstraction earns its keep or leaks so badly you’d rather hand-roll MCP. That humility is part of the brand, not a side note.

Values the brand leans on:

1. Complement, don’t compete with MCP/ACP—any transport’s success is a “tailwind.”
2. Greener / less wasteful AI—structured kilobytes of meaning instead of megabytes of markup every agent would otherwise render (Foundation README + whitepaper).
3. Safe by design—discovery open; payments, refunds, data exports require user approval / preview.
4. Privacy-preserving tooling—privacy policy: no ad cookies, validator/extension process public manifests only, Discovery Network stores public metadata the site owner submits, no behavioural profiles.
5. Open and neutral—MIT code, CC-BY spec; if a neutral discovery standard emerges, AI2Web says it wants to be carried by it, not fight it.

Who is speaking: Created by Roland Farkas (rolandfarkas.com—Digital Performance Consultant / senior engineer background) at Polarize Ltd, launched on Launchpadly as a Premium / Product of the Week Developer Tools listing. The public face is “Foundation + open tools first,” with Polarize as the commercial sustainment layer—not a stealth closed SaaS with an open-source decoy.

First impressions

The homepage is unusually precise for an early protocol launch. It leads with a sample /ai2w JSON fragment, an AI Readiness score out of 100, and an explicit rejection of the “MCP for websites” label. Docs open with a three-step quick start: publish /ai2w, add /.well-known/ai2w, validate and connect.

On Launchpadly, AI2Web landed as a featured Developer Tools listing and was marked Product of the Week in the week we reviewed—with strong community upvote volume relative to typical new listings. Treat that as Launchpadly signal, not as proof of internet-wide agent adoption.

GitHub organization activity shows a full kit of public repos (spec, JS/TS, Python, PHP, Go, .NET, Ruby, WordPress, Chrome, validator, cloud workers, directory). Star counts were still very low when we checked—consistent with a new foundation push, not a mature standard. Early does not mean unserious; it does mean you should expect breaking changes until v1.0.

Evaluation methodology

We reviewed:

• ai2web.dev homepage FAQ, product framing, and privacy policy
• Docs quick start and install matrix
• ai2web-spec and the Foundation org README
• Positioning / “why it exists” / whitepaper docs in ai2web-foundation/docs
• DEV Community post by Roland Farkas
• Launchpadly listing and founder profile

We did not reverse-engineer every RFC, run the Chrome extension across a large corpus of sites, or verify that every assistant listed (Claude, ChatGPT developer mode, generic MCP clients) behaves identically in the wild. Security language below is as published—not an independent audit. Commercial Polarize offerings are named in Foundation materials; there was still no public seat-pricing page for them at review time.

Product overview

Published path to “AI-ready”:

1. Describe the site once (hand-written JSON, SDK builder, or WordPress plugin auto-generation).
2. Serve the canonical manifest at /ai2w.
3. Discover via /.well-known/ai2w (required anchor that carries or points to the manifest). SDKs also mention projections such as /llms.txt and /.well-known/agent.json for agents that speak those formats.
4. Validate with the browser validator or npx -p @ai2web/validator ai2web validate https://your-site.com.
5. Expose transports as needed (for example /ai2w/mcp) and optionally join the wider network via the shared MCP connector.
6. Govern actions: consent lists, auth scopes, approval/preview for high-risk calls.

That loop is the product. If you only need a marketing chatbot, you will be buying the wrong category.

Key features

One capability model

Capabilities are a map of module → boolean | object. A boolean declares presence; an object adds detail such as an endpoint. Docs stress that commerce is one module among equals—the model is not commerce-only. Example modules on the marketing site and docs include content, commerce (with checkout), search, events, and actions.

Site metadata in the sample includes name, type (for example ecommerce), identity, contact, rate limits, agent service flags, auth, and consent. The point of the model: every agent reads the same contract, so you do not rebuild per assistant.

Protocol projection (not protocol monopoly)

Homepage transports called out: MCP (tools/actions for assistants), ACP (agentic commerce/checkout), REST + feeds (cache-friendly content/catalog), GraphQL, OpenAPI, webhooks/events. Discovery is described as transport-neutral; if a cross-vendor discovery standard emerges, AI2Web says it is designed to be carried by it rather than compete. WebMCP is mentioned as an optional in-page adapter.

This is the strongest conceptual pitch in the category: treat MCP success as a tailwind, not a rewrite. It is also the hardest part to prove—value scales with how many agents and sites actually speak ai2w.

Discovery and the network connector

Per the spec README, discovery in one glance:

• GET /ai2w — canonical manifest
• GET /.well-known/ai2w — required discovery anchor
• GET /ai2w/negotiate — capability negotiation handshake
• GET /ai2w/{module} — live module routes

For assistants, the site advertises a single MCP endpoint—https://connector.ai2web.dev/mcp—with tools such as find_sites, describe_site, and call_site_action (approval-gated for high-risk). The claim: point an assistant at one connector and reach AI-ready sites as they register, so a small excellent site can be reachable on merit. That is a classic two-sided network bet. Early registries are thin; the protocol’s long-term value depends on fill rate.

Validation and AI Readiness scoring

The validator is branded as a primary product, not a side tool: score AI readiness out of 100 with per-capability checks and tiers (marketing examples show “Enterprise” at 100). No signup. Surfaces include the web UI, CLI (npx -p @ai2web/validator ai2web validate …), SDK validateManifest, React useValidate / <Ai2wBadge />, and—per Foundation materials—an MCP tool path via validator.ai2web.dev. For operators, the score is a forcing function: publish something measurable before arguing about “AI strategy” decks.

Governance and safety (vendor claims)

FAQ and homepage claim safety “by construction”:

• High-risk actions preview before they run, even if a manifest tries to declare otherwise
• Consent and OAuth2 + PKCE are first-class
• Credentials are never sent cross-origin
• Outbound requests pass an SSRF guard

Treat these as design goals implemented in reference code—verify in your threat model before you enable purchase or account-changing actions for agents.

SDKs, WordPress, Chrome, and cloud

Install paths published on the site:

• npm: @ai2web/core, @ai2web/server (Node + Cloudflare route handlers), @ai2web/mcp-bridge, @ai2web/react, plus a build-free <ai2w-badge> web component
• PyPI / Packagist / NuGet / Go / RubyGems packages under the AI2Web name
• WordPress plugin: auto-generate a manifest from posts, products, and pages (WooCommerce mentioned)
• Chrome extension: AI Readiness Checker from the toolbar
• ai2web-cloud: deployable Cloudflare Workers for end-to-end assistant wiring
• Shopify repo exists in the Foundation org (early; confirm readiness before betting a storefront on it)

Docs versioning on the site references ai2w v0.2 while the spec README still labels Draft v0.1—another sign you should pin versions and read changelogs. Breaking changes are expected until v1.0.

Getting started

Practical path from the docs:

1. Install an SDK (or the WordPress plugin).
2. Build a manifest with site name, URL, type, capabilities, transports, auth, consent, contact.
3. Serve it at /ai2w (hand route or @ai2web/server).
4. Add /.well-known/ai2w pointing to the manifest.
5. Run the validator CLI or web UI; iterate until the score matches the capabilities you claim.
6. Enable MCP (or other transports) and test with an MCP client; optionally register for network discovery.

CLI snippet published in docs:

npx -p @ai2web/validator ai2web validate https://your-site.com

For a content site, start with content + REST. For commerce, add commerce endpoints and consent for purchase before you celebrate agent checkout demos.

Who should use it

• Platform / web engineering teams preparing for agent traffic who refuse to maintain N bespoke connectors.
• Ecommerce and booking sites that want a capability contract plus consent gates—not silent scraping of checkout forms.
• WordPress / WooCommerce operators who want a no-code first manifest via the plugin, then harden transports later.
• Assistant builders who want one MCP connector to discover many AI-ready sites instead of onboarding domains one by one.
• Open-protocol advocates comfortable with draft specs, RFCs, and MIT/CC-BY licensing.

Who should avoid it

• Teams that only need an on-site AI chat widget or FAQ bot—wrong product category.
• Organizations that cannot ship public discovery endpoints or negotiate agent auth for real actions.
• Buyers waiting for a finished IETF-style ratified standard with decade-long stability guarantees—this is explicitly draft.
• Marketers who will not involve engineering; a score of 40 from a half-published manifest helps nobody.
• Security teams that require third-party audits before any agent can invoke actions—start read-only (content/search) or wait for your review cycle.

Pricing and value

Public FAQ: free and open. Protocol and specification CC-BY 4.0; reference SDKs MIT. “No vendor needs to adopt ai2w first” is the Foundation’s day-one wedge: you can generate a useful MCP endpoint and feeds from one install even before the wider web speaks ai2w.

There is no public seat-pricing page for the open tools. Cost today is engineering time, hosting for /ai2w and transports, and draft-protocol maintenance.

Foundation positioning also names a Polarize commercial layer (hosted AI2Web Cloud, capability-level analytics, enterprise gateway, Discovery-Network-Pro, certification/consulting). Treat that as the intended sustainment model—not as a published price list. The open/closed split is part of the brand: keep the capability model neutral; sell ops and measurement that only exist because of the model.

Value read: if agent channels matter, $0 for a coherent contract is the right shape—if you accept early churn. If you need a turnkey “AI sales agent” SaaS with SLAs, look elsewhere (and note AI2Web explicitly does not want to be pitched as that commerce plugin).

Pros and cons

Pros

• Clear brand discipline: interoperability layer, not MCP clone, not commerce-plugin bait
• Concrete developer path: /ai2w, well-known anchor, validator score, multi-language SDKs
• Honest licensing (CC-BY + MIT) and public RFCs/examples (ecommerce, SaaS, booking, publisher)
• Governance + privacy language first-class (consent, OAuth2+PKCE, preview, SSRF guard; no ad tracking on the marketing site)
• WordPress plugin + Chrome checker lower the floor for non-Node teams
• Shared assistant connector + Discovery Network match the “two-sided” story—if density follows
• Founder voice (DEV post) invites hard criticism instead of proclaiming victory

Cons

• Draft protocol; breaking changes expected before v1.0
• Two-sided adoption risk: agents and sites must both show up
• Public GitHub traction was still tiny when reviewed—community proof is ahead of you
• Docs/site vs spec version labels (v0.2 vs draft v0.1) need careful pinning
• “Safe by construction” is a vendor design claim—not a certificate for your threat model
• Implementing real commerce/actions is still real backend work; the manifest does not magically create checkout

Comparison: AI2Web vs common alternatives

Approach	What you get	Pain
HTML scraping / computer use	Works on any site without cooperation	Brittle, slow, unsafe for purchases, hostile to site owners
Per-assistant custom MCP server	Deep integration for one client	Rebuild when the next assistant/protocol wins
OpenAPI-only	Strong for typed HTTP APIs	Weak shared discovery/consent model for “what a website is”
llms.txt / agent.json alone	Lightweight hints for LLMs	Not a full action + auth + multi-transport contract
AI2Web (ai2w)	One capability contract projected across transports + validation + governance hooks	Early draft; network effects still forming

AI2Web’s bet is that websites need a shared way to say what the whole business is—not only a tool URL—while still riding whichever wire protocol assistants prefer this year. Their own stack metaphor places AI2Web after robots.txt / schema.org / OpenAPI / MCP: those answer “a site exists,” “entities,” “an API,” “callable tools”; AI2Web aims at model + discovery + negotiation + events for the whole site. That is ambitious. It is also why the brand keeps saying it is not “the MCP for websites.”

A secondary brand argument is efficiency: agents requesting structured capabilities instead of rendering full pages. Whether that “greener AI” story moves buyers is debatable; it is nonetheless a consistent part of how AI2Web talks about itself.

Real use cases

• Publisher / docs site: Declare content + search; serve REST/feeds; let assistants cite structured capabilities instead of guessing nav HTML.
• SaaS marketing site: Expose content and support/contact actions with auth scopes; keep destructive actions off the public agent surface.
• Ecommerce: Commerce module with checkout flag, OAuth2 scopes, and requires_user_approval_for: ["purchase"]; validate score before demo day.
• WordPress store: Install the plugin to auto-build a first manifest from pages/products; then add MCP and harden consent.
• Assistant product: Wire connector.ai2web.dev/mcp once; call find_sites / describe_site / call_site_action as the registry grows.
• Internal readiness program: Use the Chrome extension + CI validator to stop “we’re AI-ready” slides that score 20/100.

Suggested pilot plan (two weeks)

1. Day 1–2: Run the public validator against your production URL; note missing well-known/manifest gaps.
2. Day 3–5: Ship a minimal /ai2w with content only (SDK or WordPress). Add /.well-known/ai2w. Re-score.
3. Day 6–8: Add one safe action (for example search or a non-mutating support intent) with explicit consent/auth.
4. Day 9–11: Enable MCP locally; test with one MCP client. Do not enable purchase yet.
5. Day 12–14: Write an internal threat review of preview/SSRF/OAuth claims against your stack; decide go/no-go for agent checkout experiments.

Success looks like a stable score, one real assistant path that does not scrape, and a clear list of actions you will never expose.

Limitations and honesty checks

1. Standards take time. A beautiful manifest with zero agents reading it is a blog post with JSON.
2. Draft means churn. Pin package versions; budget remediations when v1.0 lands.
3. Capability honesty matters. Declaring checkout: true without a working endpoint is worse than a lower score.
4. Network density is unknown. The connector model is right; fill rate will decide whether find_sites is useful next quarter.
5. Security is shared responsibility. Reference guards help; your authz, PCI, and fraud controls still own purchases.
6. Not a CMS, CDN, or LLM. You still build the site and the backends the modules point at.

Editorial ratings

Scores reflect public protocol/tooling maturity for agent-ready websites—not a production multi-assistant bakeoff. Openness/cost scores high because the stack is free and permissively licensed; ease is capped by draft-protocol reality.

Category	Score
Ease of adoption	7/10
Openness & cost	9/10
Agent interoperability	8/10
Actions & governance	7/10
Spec & SDK depth	8/10
Overall	7.8/10

Verdict

AI2Web is one of the clearest branded ideas in the “make the web work for agents” wave: describe a site once, sit above the transports, validate readiness, govern actions—and refuse the lazy “MCP for websites” shortcut. The Foundation shipped the shape of a real program—spec, RFCs, SDKs, validator-as-product, WordPress path, assistant connector, privacy posture—not just a landing-page manifesto. The Polarize commercial layer is acknowledged without pretending the open tools are a fake front.

Adopt (start read-only) if you are a web/platform team that expects agent traffic and refuses N one-off connectors, and you can tolerate draft churn.

Use the WordPress plugin / validator first if you need a low-code on-ramp before committing backend work—or if you want an honest score before the next “AI readiness” slide deck.

Skip for now if you only wanted a chat widget or a checkout-in-assistant plugin, need a finished ratified standard tomorrow, or cannot expose discovery/action endpoints safely.

Bottom line: AI2Web is early, ambitious, and unusually coherent in both product and brand—worth a validator scan and a minimal /ai2w this month if agents are on your roadmap, and worth watching for the Discovery Network / analytics story even if you implement later.

FAQ

What is AI2Web best for?

Publishing a single website capability contract that agents can discover and use across multiple protocols—without rebuilding per assistant or relying on HTML scraping.

Is AI2Web free?

Yes, per the public FAQ. Spec/RFCs are CC-BY 4.0; reference SDKs are MIT. There is no public seat pricing page.

Is AI2Web just MCP for websites?

No. The project explicitly rejects that label. AI2Web is the layer above transports: one capability model projected to MCP, ACP, REST, GraphQL, OpenAPI, feeds, and related adapters, plus discovery/validation/governance those specs leave out.

How do agents find my site?

Via a required /.well-known/ai2w anchor that points to (or carries) your /ai2w manifest. SDKs also mention /llms.txt and /.well-known/agent.json projections. Assistants can also use the shared connector at https://connector.ai2web.dev/mcp.

How do I validate readiness?

Use the web validator on ai2web.dev or the CLI: npx -p @ai2web/validator ai2web validate https://your-site.com. SDKs expose the same scoring locally.

What languages are supported?

Published SDKs/packages span TypeScript/JavaScript/React, Python, PHP, Go, .NET, and Ruby, plus WordPress and a Chrome extension. They are described as producing the same manifest and score.

Is it production-ready?

The Foundation labels the protocol draft (breaking changes expected until v1.0). Suitable for pilots and read-only capability exposure; treat high-risk agent actions as experimental until your security review passes.

Who is behind AI2Web?

The AI2Web Foundation stewards the open protocol and tools. Roland Farkas created it (public site, GitHub, DEV post, Launchpadly). A commercial platform layer is attributed to Polarize Ltd. Open tools remain MIT/CC-BY; Polarize is positioned for hosted ops, analytics, and enterprise offerings.

What does “Describe once. Works everywhere.” mean?

Publish one capability model at /ai2w; generate adapters for the protocols assistants already speak instead of rebuilding per assistant. It is the brand promise—and the adoption bet.