I Gave My Website an MCP Server. No AI Can Find It Yet.

What I Actually Built

This site has a section called Thinking, articles and product playbooks. A few months ago I did something that, on paper, sounds like a gimmick: I gave the site its own MCP server.

Model Context Protocol is the open standard Anthropic published in late 2024 and then handed to a foundation backed by basically everyone, AWS, Google, Microsoft, OpenAI, Anthropic, Cloudflare, Bloomberg, Block[20]. The one-line version everyone repeats is "USB-C for AI"[22]: a single, standard way to plug an AI model into external tools and data, so you stop building a custom integration for every model-times-every-tool combination.

Here's the distinction that matters. Without MCP, an AI that wants to use my site reads it the way Google does, it scrapes the rendered HTML and pattern-matches text. With MCP, the site stops being a page to read and becomes a set of tools to operate. My server exposes three: list_content (here's everything I've published), get_content (give me this specific piece in full), and search_content (find the pieces about X). An agent can call those directly and get clean, structured answers instead of guessing from a scraped DOM.

The part I want to be honest about: building it was almost anticlimactic. One library file wires the MCP endpoint to the three content sources the site already maintains, the article catalog, the playbook concepts, and the hand-written canonical text I keep for LLMs. No new database. No duplicate content to keep in sync. The MCP surface reads from the same single sources of truth the site renders from, so it can't drift. An afternoon, not a project.

So I had a live, public, open MCP server sitting at a stable URL. Then I went looking for the magic.

The Thing I Expected to Work, and Didn't

My mental model was the obvious one. I assumed that by 2026, the major assistants, ChatGPT, Gemini, Claude, the open Llama-based stacks, would do something like this: you mention a site, the AI checks whether it exposes an MCP server, and if it finds an open, read-only one, it just... uses it. The way a browser finds a site's favicon or a crawler finds robots.txt. Discovery should be automatic, and an open server should be self-service.

That is not how it works. Not on any mainstream client, today.

The current MCP specification (the stable revision is dated November 2025) is blunt about it. The transport section instructs the client to "accept an MCP server URL from the user"[1]. The endpoint is an input, not something the agent finds. There is no robots.txt for MCP, no ratified, well-known location an agent can check to learn "this domain has tools, here's where, here's what they do." The only /.well-known/ paths the spec defines are for OAuth, and they only kick in after you already know the endpoint[2].

So across every client, the pattern is identical and unavoidable: a human obtains the URL out of band → pastes or adds it → authenticates if needed → approves the tools. The endpoint is given, not discovered.

The State of Play, by Client (June 2026)

I checked each one, because "we're not there yet" is easy to assert and worth grounding:

• ChatGPT supports remote MCP servers, but behind Developer Mode, which OpenAI labels "elevated risk" and tells you is "intended for developers." You enable it, create an app, paste the server URL. Their own warning is striking: "do not connect to a custom MCP server unless you know and trust the underlying application", and even "trusting an MCP's developer does not make this safe"[9].
• Claude supports custom connectors (in beta): add connector, paste URL, authenticate[10]. There's also a reviewed directory, but that's a human-vetted allowlist, not domain discovery.
• Gemini's consumer app has no path for custom or remote MCP servers at all, only a fixed set of first-party connected apps (Gmail, Drive, and so on)[11]. The developer SDK and CLI can do MCP; the app most people actually use cannot.
• Open / self-hosted stacks (LibreChat, and Llama models wired through it) support remote MCP, via a config file or a setup panel[12]. Powerful, and still manual.

Nothing in that list crawls a website to find and connect to its MCP server. The invariant holds everywhere: obtain URL → add it → auth → approve.

Why We're Not There Yet, and Why Part of That Is on Purpose

The easy read is "the standard is just immature, give it a year." That's half true. The more interesting half is that the missing piece is being deliberately withheld, because blind auto-connect is unsafe in a way that isn't a bug you can patch.

On the standards side: discovery proposals have circulated since December 2024, a /.well-known/mcp.json file, "Server Cards," a "Universal MCP Manifest," DNS-based schemes. The live, official effort is the Server Card working group[5]. As of mid-June 2026 it's still a draft, and it's being moved off the core standards track into optional extensions[6]. The official registry that launched in preview in 2025 is, by its own documentation, "not intended to be directly consumed by host applications"[7], it's a catalog for aggregators to poll, and it verifies who owns a namespace, not that a live tool endpoint sits on an arbitrary marketing domain[8]. The plumbing is arriving; the doorbell isn't.

On the safety side, this is the part the hype skips. When an agent connects to an MCP server, the descriptions of the tools are visible to the model but not to you. That means a malicious server can hand instructions straight to your AI at the moment of connection, before you've approved a single action, security researchers named this "tool poisoning"[14] and "line-jumping"[13]. Trust isn't even durable: a server you approved can quietly change what its tools do afterward (a "rug pull"). Stack that on the "lethal trifecta"[16], give an agent access to your private data, expose it to untrusted content, and give it a way to send data out, and you have a data-exfiltration machine. There's a real CVE (9.6 severity) for remote code execution triggered just by connecting to an untrusted MCP server[17]. There's a documented attack where a poisoned GitHub MCP flow leaked a user's private repositories[15].

The root cause is unsolved as of mid-2026: an LLM can't reliably tell trusted instructions from untrusted content it's reading. Until that's better handled, "your AI auto-discovers and self-connects to any website's tools" isn't a convenience the industry is racing toward, it's a threat model the industry is consciously routing around[18]. The caution in OpenAI's and Anthropic's product gating isn't timidity. It's the correct response to the current security reality.

What Does Work Today

Here's the nuance that keeps this honest, and it's the good news for small sites. Strip the requirement down from "auto-discovered" to "self-service once you have the URL," and a public, read-only server clears the bar cleanly. Because MCP authorization is optional[2], my server has no login, no token, no OAuth dance. You paste the URL once into a client that supports remote MCP, and the agent can immediately list, fetch, and search my writing, structured, clean, no scraping. That genuinely works end to end, right now. The only missing step is the one the whole industry is missing: the agent can't find the door on its own. You still have to point at it.

What This Means If You Run a Site

Two things, one tactical and one strategic.

Tactical: if you publish anything you'd want an AI to represent accurately, and increasingly that's how people will first encounter your work, exposing a small, public, read-only MCP server is cheap insurance. It's an afternoon. It costs nothing to run if your content already lives in a structured source. And it future-proofs you for the discovery layer that is coming[4]: when Server Cards or a registry-driven flow finally ship, the sites that already speak MCP will be the ones agents can actually use.

Strategic: this is the same shift I keep coming back to. For twenty years the question was "is my site indexable by Google," can a crawler read me. The next question is "is my site operable by an agent," can an AI use me[21]. Those are different muscles. Indexability is about text and links. Operability is about exposing capability, tools with clean inputs and outputs, a reliable contract, a stable endpoint. The sites that win the agent era won't be the ones with the best-scraped prose. They'll be the ones that handed agents a set of tools and said: here, operate this.

I built that door for my own site. I'm convinced it's the right move. I just had to accept that, in June 2026, I'm the one who has to walk each agent over and point at the handle. The door is open. The bell isn't wired yet.