Agent surfaces: when AI stops reading your site and starts querying it

An agent surface is a Model Context Protocol (MCP) server that lets an AI assistant query your live data directly instead of scraping a rendered page. The proof is a JSON-RPC initialize call: send it, a real server answers with its protocol version, capabilities, and server info. No answer, no surface.

Most companies reading about “getting cited by AI” are still thinking about pages. Text an assistant can fetch, extract, and quote. That is the reading model, and it is the one every GEO checklist is built around. The querying model is different. Instead of an assistant guessing your prices from a stale cached page, it opens a connection to a server you run and asks for the number. The answer is current, structured, and yours.

What is an MCP agent surface?

MCP is an open protocol, originally from Anthropic, now with SDKs and a public specification on GitHub. It defines how an AI application (the host) connects to a server that exposes three things: tools it can call, resources it can read, and prompts it can reuse. A brand’s agent surface is an MCP server that publishes the data an agent would otherwise have to scrape: inventory, pricing, availability, specifications, booking slots.

The point is retrieval quality. A page tells an assistant what you said last time your CMS deployed. A server tells it what is true right now. For anything that changes (stock, price, seat availability, clinic wait times), that gap is the whole game.

How does the initialize handshake work?

Every remote MCP server speaks JSON-RPC 2.0 over what the spec calls Streamable HTTP: an HTTP POST for messages, optional Server-Sent Events for streaming. The conversation opens with one message. The client POSTs an initialize request carrying a protocolVersion, its capabilities, and a clientInfo block. A working server replies with its own protocolVersion, a capabilities object listing which primitives it supports, and a serverInfo name and version. The architecture docs walk through the exact JSON.

That exchange is the tell. You do not need a rendered page, a screenshot, or a guess. You POST one payload to a candidate endpoint (/mcp is the common path, /sse the legacy one) and read what comes back. A real server negotiates. A marketing site returns a 404 or an HTML page, which is not a negotiation.

There is a second valid signal: a 401 with a WWW-Authenticate header pointing at /.well-known/oauth-protected-resource. That means an MCP resource server exists but wants a token first. Under RFC 9728, that pattern also proves a surface is there. It just guards the door.

Can an agent find your server on its own?

Discovery is the unsolved part, and it is being worked on in the open. The IETF draft draft-serra-mcp-discovery-uri proposes an mcp URI scheme plus a well-known path, /.well-known/mcp-server (per RFC 8615), with a DNS TXT record as a fallback. There is also a community /.well-known/mcp.json convention floating around. None of these has won yet. The 2026-07-28 specification release candidate is still moving the ground under everyone’s feet, including retiring the standalone initialize handshake in favor of metadata on every request. So treat well-known discovery as an emerging signal, not a settled standard. The definitive test remains the handshake.

Does anyone actually have one?

We built a probe that POSTs the initialize handshake to candidate endpoints on real sites and reads whether a server negotiates back. Across the mid-market B2B sites we scanned, the answer was the same every time: nobody had an agent surface. Not one. That is not a knock on those companies. It is a timestamp. The infrastructure layer here is roughly where sitemaps were before anyone submitted them.

Which is the actual opportunity. Building the server is not the hard part. If the underlying API already exists, wrapping it in an MCP server is described consistently across GEO practitioners as about a week of work. The scarce thing is being early enough that when assistants start preferring live-queried data over scraped pages, yours is the data they can query.

There is a caveat worth stating plainly, because the honest version sells better than the hyped one: agents preferring MCP surfaces over scraping is still mostly a bet, not a measured shift. The handshake proves capability, not traffic. Before you commit budget, confirm the reading model is solid first. A page an assistant cannot fetch fast enough is invisible whether or not you have a server, which is why server speed became an existence problem before agent surfaces did.

The next step is small and free. Run the handshake against your own domain’s /mcp and /sse paths and see what comes back. If it is a 404, you have your answer, and you are in good company. Our free scan runs the same probe and tells you where you stand before you spend a week building anything.

Agent surfaces: when AI stops reading your site and starts querying it

What is an MCP agent surface?

How does the initialize handshake work?

Can an agent find your server on its own?

Does anyone actually have one?

Sources