What is MCP and why does it matter for websites?

What the protocol actually is

The Model Context Protocol is an open standard for connecting assistants to tools and data. The mechanics are unremarkable — JSON-RPC 2.0 messages over HTTP — and the useful part is the convention rather than the transport.

A client connects and asks tools/list. The server replies with each tool it offers: a name, a description written for the model, and a JSON Schema for the arguments. The model reads those descriptions and decides for itself when a tool is relevant. Then it calls one with tools/call and gets a structured result back.

That is the whole idea. The significance is in what it removes: no per-assistant plugin format, no bespoke integration for each product, no prompt engineering to explain what an API does. The tool explains itself.

Why this changes website questions specifically

Website questions are unusually badly served by a model working alone, for a reason that is easy to miss: almost nothing interesting about a website is in the page.

• Whether it is secure lives in response headers.
• Whether traffic is protected lives in the TLS handshake.
• Whether someone can forge your email lives in DNS.
• Whether AI assistants can read you lives in robots.txt precedence rules.
• Whether any of it broke lives in the difference from last week.

None of that is text on a page, so a model reading the page cannot know it, and no amount of reasoning recovers it. A tool that measures those things closes a gap that model quality alone never will.

What connecting one looks like

For a client with a CLI, typically a single line:

claude mcp add --transport http outrings https://outrings.com/mcp

For everything else, a small block of configuration naming the transport and URL:

{
  "mcpServers": {
    "outrings": {
      "type": "http",
      "url": "https://outrings.com/mcp"
    }
  }
}

No key, no account, and every tool marked read-only so the client need not interrupt you for approval on each call.

What the model does with it

The tool descriptions are written for the model rather than for a documentation page, and that distinction does real work. A good description says when to reach for the tool, and when to reach for a cheaper one instead — so audit_website explicitly points the model at check_category when only one area is in question. The result is fewer, better-targeted calls.

What it does not do

• It is not a browser. Anything that only exists after JavaScript runs is reported as requiring a browser rather than guessed at.
• It is not a vulnerability scanner. Ordinary requests, read honestly. No probing, no exploitation, no CVE matching.
• It does not make the model correct about everything else. It grounds the questions it covers, and the model is on its own for the rest — which is why every result states what it did not cover.