MCP explained for web developers: a safe front door for AI agents

For years, 'integrating with AI' meant writing a custom plugin for each assistant. Every vendor had its own format, and each one broke with the next release. The Model Context Protocol, MCP, replaced that with one open standard, and in less than two years it has become the default way AI agents connect to software.

If you build web apps, MCP is worth understanding now. Your clients will soon ask whether their product 'works with AI'. More and more, that means it has an MCP server.

What MCP is, in one paragraph

MCP is an open protocol for connecting AI applications to data and tools. Anthropic introduced it in November 2024. It uses JSON-RPC 2.0 messages between three roles. A host is the AI application, such as a chat app or coding editor. A client is the connector inside that host. A server is your code, which exposes what the AI can see and do. The specification compares it to the Language Server Protocol, which let every editor support every programming language through one interface. MCP does the same for AI tools.

What a server can offer

An MCP server can expose three kinds of things:

• Tools: functions the model can call, such as 'create_invoice' or 'search_orders'. Most of the value lives here.
• Resources: data the user or model can read, such as a document, a record or a file.
• Prompts: ready-made templates and workflows a user can pick, like 'summarise this week's support tickets'.

Clients can also offer features back. The main one is elicitation, which lets your server ask the user a follow-up question mid-task instead of guessing. Optional extensions add more. Tasks handle long-running jobs, and MCP Apps render interactive UI such as charts and forms inside the conversation.

Why it became the standard

What made MCP stick was neutrality. In December 2025, Anthropic donated MCP to the new Agentic AI Foundation under the Linux Foundation, alongside Block's goose and OpenAI's AGENTS.md. By then MCP had more than 97 million monthly SDK downloads and over 10,000 active servers. Competing AI companies now back the same protocol, so building one MCP server reaches many assistants instead of one.

The tooling you already use is adopting it too. Next.js 16 shipped a DevTools MCP server. It gives coding agents your app's routes, errors and logs directly, instead of relying on you to copy stack traces into a chat.

What changed in 2026

The current specification is dated 28 July 2026. The March 2026 roadmap explains the direction. It says outright that there will be no new official transports this cycle. Instead, the existing Streamable HTTP transport is evolving towards stateless sessions and discovery through .well-known endpoints, so MCP servers can scale horizontally like any other web service. The other priorities are agent-to-agent work built on the Tasks primitive, clearer governance through working groups, and the things companies need: audit trails, single sign-on and gateways.

For a web developer, the practical meaning is that a remote MCP server is becoming a normal backend service. You deploy it, scale it and secure it like an API.

How I would design an MCP server for a client app

Take a clinic system like the pet clinic app in my portfolio, which tracks vaccinations and reminds owners on WhatsApp. The mistake would be to mirror the REST API one endpoint at a time. Models do better with a few tools shaped around tasks than with dozens of low-level ones.

1. 1Start with questions people actually ask. For example, which pets are due for a vaccine this week, and when was this pet last seen. Each becomes one tool with a clear name and plain-language description.
2. 2Separate reading from writing. Read-only tools like 'list_due_vaccinations' are low risk. Anything that changes data or contacts a customer, like 'send_reminder', should need the user's confirmation.
3. 3Return compact, relevant data. Send the five fields the model needs, not the whole database row. Smaller responses are cheaper, faster and leak less.
4. 4Authorise every call as the user. MCP's authorisation spec for HTTP servers is built on OAuth. The server should act with the signed-in user's permissions, never with an admin key that can see everything.
5. 5Log every tool call. When an agent does something unexpected, you want the same audit trail you'd want for a human.

Security is the part to get right

The specification is blunt about this. Tools represent arbitrary code execution. Hosts must get explicit user consent before invoking any tool. Tool descriptions and annotations should be treated as untrusted unless they come from a trusted server.

That last point cuts both ways. If you connect an agent to third-party MCP servers, a malicious server can hide instructions in its tool descriptions. If you build a server, remember that any text your tools return, such as customer messages, reviews or emails, can contain instructions aimed at the model. Treat it as untrusted input. I cover this in more detail in my post on prompt injection.

Should your product have an MCP server?

If your app holds data people regularly look up, or runs workflows people repeat, probably yes. Start small. Build a read-only server with three or four tools your own team would use, and watch how an agent uses them. It takes a few days to build, and it is the quickest way to learn what your product looks like to an AI.