What the Model Context Protocol Changed for AI Coding Agents

Four of the servers Anthropic shipped as launch examples for the Model Context Protocol read like a coding day, not a demo reel: GitHub, Git, Postgres, and Puppeteer. Version history, the repository, the data layer, and a headless browser to check what you built. What MCP changed for coding work is right there in that list. An assistant stopped reasoning about code you paste and started operating against your real repository and tools through one protocol, which expands what it can see and, in the same motion, what it can do to your system. The standard was announced and open-sourced on November 25, 2024, and by early 2025 it reads less like a preview and more like plumbing.

If you have leaned on a chat assistant for code, you know the ceiling. It reasons well about a snippet you paste, then loses the thread the moment the answer lives in a file you did not include. You become the integration layer: copying context in, copying diffs out, re-explaining the same repository every session. MCP is the architecture that lifts that ceiling. It is worth understanding exactly how, because the wiring that makes an agent useful is the same wiring that gives it consequences.

The ceiling was fragmentation

Before a shared protocol, every connection between an assistant and a data source was its own project. Anthropic framed the problem directly: teams were writing one custom implementation per source, and those fragmented integrations did not compose. For a coding agent, that fragmentation was the ceiling. Reading your repo was one bespoke bridge, querying your database was another, driving a browser was a third. Each had to be built, maintained, and trusted on its own terms. A single protocol turns that pile of one-off bridges into a common interface, which is why the release landed as an inflection rather than a feature.

What actually shipped, and why it mattered day one

The launch was not a spec on paper. Anthropic shipped three pieces at once: the specification and SDKs, local MCP-server support in Claude Desktop, and an open-source repository of servers. That combination is what made it usable immediately. You could read the standard, run a server on your own machine, and connect a real client without waiting for a vendor rollout. A protocol you can exercise the day it ships is a protocol you can evaluate before you trust it, which is the right order to do those two things in.

Hosts, clients, servers, and the negotiation that matters

The specification dated 2024-11-05 names three roles. Hosts initiate connections. Clients live inside a host and manage a connection to a server. Servers provide context and capabilities to the model. In a coding setup your assistant is the host, and the servers are what it reaches for: one reads your repo, one talks to Postgres, one runs a headless browser.

Underneath, MCP uses JSON-RPC 2.0 over stateful connections, and a host and server negotiate capabilities when they connect. That negotiation matters more than it sounds. A client learns what a server can actually do before it tries to do it, instead of guessing and failing. For anyone who has watched an assistant invoke an API that was never there, capability negotiation is the quiet fix.

Resources read, tools act, and the gap between them

The same specification names three kinds of server capability. Resources are readable context, the contents of a file or a record. Prompts are reusable templates a server can offer. Tools are actions the model can invoke.

That last category is the one that changes your day. A resource lets the assistant read your schema; a tool lets it run the query. The distance between those two is the distance between an assistant that describes your system and one that operates it. Read the schema is a report. Run the migration is an event. When you wire a server in, you are deciding which of those two you are signing up for.

Make that concrete. Your repository is exposed as resources, so the assistant reads src/db/schema.sql and the pending migration migrations/0007_add_orders.sql as content, not a pasted fragment. Then it invokes tools to act on what it read: the Postgres server runs a read-only check like SELECT count(*) FROM orders against a replica, and Puppeteer drives a browser to open /orders and confirm the page renders. Reading the two SQL files is the report; running the query and loading the route are the events. Same session, two different levels of consequence.

Connection cuts both ways

The reason to slow down is the same reason MCP is powerful. A tool is not a read. It can run code and change state. MCP’s own initial security guidance is blunt about it: data-access and code-execution paths call for explicit user consent, clear authorization interfaces, privacy controls over what data is shared, and caution around tools, because a tool can represent arbitrary code execution.

Treat that as design guidance, not boilerplate. The naive reaction to a new standard is to connect everything at once, because you finally can. The disciplined reaction is to grant one server at a time and know what each is allowed to touch. A Postgres server pointed at a read replica is a different risk from one holding write credentials to production. A browser tool that can only navigate is a different animal from one that can submit forms. The protocol will not make that call for you.

Both ways to get this wrong

Picture the two failure branches, because you can land on either. Stay with copy-paste chat past its usefulness and you keep paying the tax: the context you re-explain every morning, the diff the model produced against a file it never actually saw, the bug it confidently fixed in code that does not exist in your tree. Swing the other way, connect every server you can find with full credentials, and the first time an agent runs a destructive tool against real data you will learn what “arbitrary code execution” meant in practice. The win sits between them, and it is specific: connect the servers whose actions you would let a new teammate run on their first day, and no more than that.

MCP settled the shape of the answer. Assistants get better when they work against real context and real tools through one protocol instead of a dozen brittle bridges. What it did not settle, and cannot, is which of those tools earns a connection to your repo and your shell. That decision moved to you, and in early 2025 it is the one worth taking seriously. The protocol is the easy part. Deciding what to trust with your system is the work.

FAQ

What is the Model Context Protocol in plain terms? It is an open standard for connecting an AI assistant to outside context and tools, such as a repository, a database, or a browser, through one protocol instead of a custom integration per source. Anthropic announced and open-sourced it on November 25, 2024.

How is a connected coding agent different from a chat assistant? A chat assistant reasons about the code you paste into it. A connected agent reads resources and invokes tools directly through MCP, so it works against your actual repository and environment rather than a copied fragment. You stop being the integration layer.

What can an MCP server expose? The 2024-11-05 specification names three capabilities: resources for readable context, prompts for reusable templates, and tools for actions the model can invoke. Servers advertise these when a client connects, so the assistant knows what is available before it acts.

Is it safe to let an agent use tools? A tool can run code and change state, so MCP’s guidance calls for explicit consent, clear authorization, and privacy controls. Grant access one server at a time, scope each to the least it needs, and understand what a tool can do before you approve it.