Your AI Agent Needs a Door. I Built One.

I do not put WebMCP on a site to flex a Chrome API.

I build Agent-first. That means the important visitor is not only a human with a mouse. It is YOUR AI AGENT — Grok Bot, Cursor, Claude, whatever you run — knocking on my website with a key and getting only what I publish.

The product for that is my Agent Gateway. WebMCP is one door on it. Not the building.

Agent-first in plain English

Old web: humans click pages. Agents guess from screenshots.

Agent-first: I open doors so an agent can connect, read the feed I allow, call tools, and get a ping when I publish. No crawl of the whole homepage. No inventing my life from a blog footer.

If it is not in the gateway feed, YOUR AI AGENT does not have it. Capiche?

That is the architecture behind bernhardrieder.com — and the same mindset I use when I wire money surfaces like a 3D configurator. Humans still get UI. Agents get doors.

The doors (this is the Gateway)

Live discovery: /.well-known/agent-gateway.json · name bernhardrieder-gateway · version 1.3.0.

| Door | What it is | | --- | --- | | Human | bernhardrieder.com/gateway — paste the GATEWAY PROMPT into YOUR AI AGENT | | MCP | bernhardrieder.com/mcp — Streamable HTTP for Cursor / Claude Code | | REST | bernhardrieder.com/api/v1 — same catalog over HTTP | | WebMCP | window.bernhardGateway + document.modelContext on this origin — tools inside the open tab | | Notify | register_notify — leave an HTTPS webhook; I ping you (HMAC-signed) when I publish | | llms.txt | Static map for crawl agents — discovery, not execution |

How you connect in three steps: copy the Gateway Prompt → paste it into YOUR AI AGENT → that is it. Start with greetings. Then identity, catalog, tools, search. Want push instead of poll? Register a webhook.

Cursor one-liner shape:

json

1{
2  "mcpServers": {
3    "bernhardrieder-gateway": {
4      "url": "https://bernhardrieder.com/mcp"
5    }
6  }
7}

Why WebMCP is on my sites

Server MCP is great when the agent talks process-to-process — Cursor to my /mcp endpoint, Unreal plugins, CLIs.

Sometimes the agent is already in the browser tab. Then it should call a tool on the page that owns the state — not click pixels like a raccoon. That in-tab door is WebMCP (Google / W3C work in Chrome): document.modelContext, registerTool, prove it with getTools().

So I use WebMCP because:

My Gateway already exposes MCP + REST + notify. The in-page door completes the set.
On product SPAs (configurators), agents need get_config / set_option / list_options without screenshot theater.
Agent-first means every real door that matters — not MCP alone while the tab stays mute.

On this origin, discovery literally lists WebMCP as: window.bernhardGateway and document.modelContext on this origin. Same story, different socket.

Tiny wiring note (so you do not burn a sprint)

Register on document.modelContext. Chromium deprecated navigator.modelContext and left an alias that lies to you. Feature-detect, share one AbortController, prove with getTools(). Empty list = costume. Full directive is in the Toolbox.

Benefits — why this feature matters

Direct persona → agent → my site. Your agent connects as your agent. I decide what the feed returns.
No screenshot theater for catalog, tools, and notify.
One key (the Gateway Prompt) instead of a YAML pilgrimage for every reader.
Push when I publish via signed webhooks — agents do not have to poll forever.
Layers stay clean: Gateway for the site brain, WebMCP for in-tab tools, llms.txt for static discovery.
Career / product leverage: revenue UIs that agents can operate become Agent-first assets, not dead HTML.

Same gravity as the bigger shift: seats get absorbed, GUIs become optional wallpaper, corporations run agent warships. I open a Gateway so the good agents can talk to my systems cleanly.

Connect here: Agent Gateway

In-page playbook: WebMCP document.modelContext Directive

WebMCP is Google’s in-tab tool surface. I ship it because my Agent Gateway needs every real door. The Gateway is still the product.