Source: wiki synthesis: Ramp’s Marketing-to-AI-Agents Experiment, WebMCP Directory (nekuda.ai), EmDash CMS
Three 2026 sources, filed under three different topics, are facets of one shift: the web is being rebuilt to be discoverable, readable, and actionable by AI agents rather than humans. Ramp’s controlled experiment is the demand side — optimizing content so agents cite and choose you. The WebMCP directory is the interface side — sites exposing typed, callable tools to agents instead of read-only HTML. EmDash is the supply/authoring side — a CMS that stores content structurally and emits it to agents through a built-in MCP server. Read together, they sketch a stack: author content an agent can parse, expose actions an agent can invoke, and measure which formats and pages agents actually cite.
Key Takeaways
- One shift, three layers. Each source attacks “the web is built for humans” from a different angle: Ramp measures what gets cited, WebMCP exposes what gets invoked, EmDash governs what gets authored and stored. ^[inferred]
- The web stops being read-only documents and starts being callable surface. WebMCP states this inversion directly via
navigator.modelContext; EmDash ships the same inversion through a per-site MCP server; Ramp’s data shows even read-only content needs reformatting (markdown beat schema) before agents reliably surface it. ^[inferred] - Content vs. action is the load-bearing distinction. Ramp and the markdown-for-agents lineage optimize content agents read. WebMCP and EmDash’s MCP server expose actions agents take. Both layers are required — the WebMCP article itself frames the two as “content-side” vs. “action-side” of the same agent-readable-web thesis.
- Structured authoring upstream makes agent-readable output downstream cheaper. EmDash’s Portable Text (structured JSON, decoupled from presentation) renders the same content as web page, mobile, email, or API response; Ramp found markdown — not HTML-with-chrome — is what LLMs parse natively. A supply layer that stores structure can emit the format the demand-side experiment showed wins. ^[inferred]
- Measurement is non-optional and the dials are unfamiliar. Ramp’s per-model variance (Claude cited heavily, ChatGPT stayed silent 32 days), misleading Cloudflare bot labels, and “agent trust ≠ SEO domain authority” all mean you cannot assume an agent-readable page is being read or surfaced — you have to instrument it.
- First-party reinforcement beyond the web (2026-06-09). [X signal — @AnthropicAI 2026-06-09] Anthropic’s research post “Agents in Biology” frames biology’s slow agent progress as an infrastructure problem, not a model-capability one — biological databases and tools were “built before cars” and aren’t agent-friendly, so the work is rebuilding the environment for agents. It’s this thesis applied to a non-web domain: the supply side has to be re-plumbed for agents before agent capability pays off. (Source:
raw/x-account-anthropicai-2064054837294354677.md, https://www.anthropic.com/research/agents-in-biology.)
How the three are facets of one shift
Demand side — Ramp: optimize so agents cite and choose you
Ramp’s 5-week controlled experiment tested three content formats (markdown / stripped HTML / schema) against three LLMs on ~50 pages, with Cloudflare Workers serving alternate content to detected bots. The headline finding: markdown beat schema and stripped HTML by a wide margin — LLMs are trained on markdown-heavy data and parse it natively. Per-model behavior diverged sharply (Claude named the program and linked the tracked URL by Day 12; ChatGPT produced zero matches for 32 straight days), and pages with higher existing AI-citation volume were far likelier to surface embedded content — an “agent trust” signal distinct from SEO domain authority. This is the demand side: given that agents now mediate discovery, what makes one site’s content the thing an agent repeats?
Interface side — WebMCP: expose callable tools, not just text
The WebMCP directory catalogs sites that expose typed tools via navigator.modelContext (built on the W3C webmachinelearning/webmcp draft) so browser-running agents can discover, inspect schemas, and invoke them — sites become callable, not just readable. The directory’s own framing makes the connection to Ramp explicit: most agent-readable-web work targets content (markdown for agents, schema markup, Ramp’s format A/B), whereas WebMCP targets actions — typed tools the agent invokes rather than text it reads. This is the interface side: once an agent has chosen you (the demand side), how does it act on your site without screen-scraping HTML?
Supply/authoring side — EmDash: a CMS that emits agent-consumable content
EmDash is an Astro + Cloudflare CMS pitched as a WordPress successor, and the WebMCP article already names it a sibling pattern (“CMS with built-in MCP server per site”). Two of its design choices map straight onto the other two layers. Portable Text stores content as structured JSON decoupled from presentation — the supply-side precondition for emitting the markdown-style, chrome-free payload Ramp found wins on the demand side. ^[inferred] And its built-in MCP server plus agent skills plus CLI mean Claude or ChatGPT can manage content and, by exposing the site’s operations to agents, it occupies the same interface layer WebMCP standardizes — EmDash rides a server-side CMS plugin, WebMCP rides browser APIs, but both hand agents typed operations rather than HTML. This is the supply side: where does agent-readable content and agent-callable action get authored, stored, and served from in the first place?
What combining them enables
Stacked, the three close a loop that no single layer closes alone: ^[inferred]
- Author once, emit agent-native. A structured-storage CMS (EmDash’s Portable Text) can render the markdown-style payload Ramp’s experiment showed agents cite — the authoring layer feeds the demand layer the format it rewards. ^[inferred]
- Read and act on the same site. Ramp optimizes what an agent reads and repeats; WebMCP (and EmDash’s MCP server) expose what an agent does next — booking, checkout, content ops — so discovery and action live on one surface instead of breaking at the HTML boundary. ^[inferred]
- Measure the whole funnel. Ramp’s instrumentation discipline (per-variant tracked URLs, daily multi-model query monitoring, CDN bot-log review) is the missing measurement layer for the interface and supply sides — without it you cannot tell whether an agent-callable, agent-readable site is actually being read, invoked, or surfaced. ^[inferred]
A useful caveat from the sources themselves: this is a young, partly inferred stack. WebMCP listed only 18 sites at fetch and its W3C draft trajectory is unsettled; EmDash’s MCP tool surface is undocumented in its README; and Ramp’s findings are from one B2B finance site over five weeks. The shared direction is well-evidenced; the integrated stack is a projection, not a shipped product. ^[inferred]
Try It
For a marketer or site-owner preparing for agent traffic:
- Pull your last 30 days of bot-classified CDN traffic first. Ramp’s strongest pre-experiment warning is that most marketers don’t know what’s already crawling them. Verify Cloudflare bot labels — “AI Search” rules silently miss Claude, ChatGPT, and Perplexity (they’re under “AI Assistant”).
- Serve markdown as your first agent-content variant, not schema. Ramp’s data is unambiguous: markdown wins. Pick one high-intent page for a minimum viable test before touching 50.
- Stand up per-model citation monitoring. A weekly diff of Claude + ChatGPT + Perplexity + Gemini answers to your top 10 prospect questions is the minimum signal. Plan for 3+ weeks of zero before declaring failure — Claude’s first relay came Day 12, ChatGPT stayed silent 32 days.
- Check whether your stack can emit structured, presentation-decoupled content. If you’re choosing a CMS, an agent-callable one (EmDash’s Portable Text + MCP server is the tracked example) lets you author once and emit the markdown-style payload agents parse — rather than retrofitting markdown onto HTML-with-chrome.
- Inspect the WebMCP directory to see who’s exposing callable tools.
curl https://webmcp.cool/api/v1/sites?type=liveand read the W3Cwebmachinelearning/webmcpdraft before committing — this is the action-side standard to watch. If you build agents,npx skills add nekuda-ai/webmcpinstalls the discovery + invocation skill. - Instrument actions, not just link clicks. Ramp found agents may not click; design conversion paths around trackable actions. The same applies if you expose callable tools — log invocations.
Related
- Ramp’s Marketing-to-AI-Agents Experiment — demand side (which formats/pages agents cite)
- WebMCP Directory — interface side (sites exposing callable tools)
- EmDash CMS — supply/authoring side (agent-callable CMS)
- FLUQs framework — the Format/Lexicon/Update-cadence/Quality levers Ramp’s data informs
- AI SEO research hub — methodology-organized AI-citation cluster Ramp anchors
- Agents & Agentic Systems topic — home of the browser-agent infrastructure WebMCP sits in
- Microsoft Webwright — Playwright-fork peer on the browser-agent interface layer
Open Questions
- Does the markdown-wins finding survive on top of an agent-callable CMS? Ramp tested markdown served by a Cloudflare Worker on a human-authored site; whether a structured-storage CMS like EmDash emits a payload agents cite equally well is untested. ^[inferred]
- Do per-site MCP servers (EmDash) and browser-API tools (WebMCP) converge or compete? Both expose typed operations; the WebMCP article flags the performance/auth/observability tradeoffs between them as unknown.
- Is there a measurement story for the action side? Ramp instruments content citation; no source in this set measures whether agents that can invoke a site’s tools actually do, or which tool schemas get invoked most. ^[inferred]
- How small is the action-side surface today? WebMCP listed 18 sites at fetch; until directory-level adoption grows, the interface layer of this stack is more proposal than infrastructure.