What Is MCP? How AI Agents Connect to Your Data (2026 Spec Update)
MCP, the Model Context Protocol, is an open standard that lets an AI agent reach tools and data sources through one common interface. Instead of a custom integration per app, a client speaks one protocol and any compliant server can answer. The spec was rewritten on July 28, 2026, and the change is significant.
This guide covers what the protocol does and what the 2026-07-28 release changed. It also covers what is now deprecated, how this differs from a plain API integration, and when you do not need it. Facts here are as of August 5, 2026.
What is MCP?
Think of it as a shared plug shape. Before a standard existed, connecting an assistant to your database, your ticket system, and your files meant three bespoke integrations. Each had its own auth, its own error handling, and its own maintenance burden.
MCP defines that connection once. A client is the agent side. A server wraps a data source or tool and exposes what it can do. The client asks the server what is available, then calls it.
Servers typically expose three kinds of things. Tools are actions the agent can invoke. Resources are readable content. Prompts are reusable templates. The client discovers all three at runtime rather than having them hardcoded.
The name gets used loosely, so one clarification helps. The protocol is not a model, not an agent, and not a product. It is the wire format between them.
Two words explain most of the confusion around it. Discovery means the client learns what a server offers at runtime. Reuse means the same server answers any compliant client.
Adoption is no longer theoretical. The protocol maintainers report close to half a billion downloads a month across the Tier 1 SDKs. The TypeScript and Python SDKs are each past a billion total.
What changed in the 2026-07-28 spec
This release is the largest revision the protocol has had. The headline is that the core is now stateless.
| Change | What it means |
|---|---|
| Stateless core | Sessions and handshakes are gone. Each request carries its own protocol version and client identity |
| Multi Round-Trip Requests | Replaces server-initiated requests that needed an open stream. A tool can ask the user for input mid-call |
| Header-based routing | Method and tool names travel in Mcp-Method and Mcp-Name headers, so gateways route and authorize on headers |
| Cacheable list results | Tool, prompt, and resource lists now carry ttlMs and cacheScope |
| Authorization hardening | RFC 9207 issuer validation, a shift from Dynamic Client Registration to Client ID Metadata Documents, and issuer-bound credentials |
| Extensions framework | Tasks move out of the experimental core into a formal extension, alongside Apps and Enterprise Managed Authorization |
Read the list as one decision repeated six times. Each change removes an assumption that made remote servers awkward to operate. None of it changes what a tool can do.
The official 2026-07-28 specification post has the full change list. TypeScript, Python, Go, and C# SDKs already support it, with Rust in beta.
Why stateless matters if you run a server
The old design assumed a persistent, bidirectional connection. That single assumption drove most of the operational pain.
A remote server used to need sticky sessions so a client kept landing on the same instance. It needed shared session storage so state survived a restart. Gateways often had to inspect payloads to work out what a request was doing.
None of that is required now. A server can sit behind a plain round-robin load balancer. Routing happens on a header. Clients cache the tool list for as long as the server's stated window allows. The protocol went from something you deploy carefully to something you deploy normally.
There is a migration cost attached. Servers built against the old core need work, and the client libraries have to move with them.
The change also lowers the cost of trying one. Standing up a server used to be an infrastructure decision. Now it is closer to deploying any small web service.
For anyone evaluating a vendor's MCP server, this is the practical question to ask: which spec version does it target, and when will it move.
What is deprecated, and how long you have
Three capabilities are on the way out: Roots, Sampling, and Logging. The legacy HTTP+SSE transport is deprecated as well.
The maintainers committed to a twelve-month minimum window before removal. That is generous, and it is also a deadline. If you built on any of the four, put the migration on a roadmap rather than in a backlog.
Check your client too, not only your server. A client pinned to the old transport will keep working during the window and then stop.
Dynamic Client Registration is formally deprecated in favor of Client ID Metadata Documents. Issuer-bound credentials now prevent a token issued for one server from being replayed against another.
MCP compared with a plain API integration
| Custom API integration | MCP server | |
|---|---|---|
| Per-source work | New auth, schema, and error handling each time | One protocol, reused |
| Discovery | You hardcode what exists | The client asks at runtime |
| Who can use it | The app you built it into | Any compliant client |
| Maintenance | Breaks when the vendor's API shifts | Server absorbs the change |
| Best for | One deep, high-volume path | Many sources reached by an agent |
One more consideration is who maintains the connector. A vendor-published server moves with the vendor's product, which is work you no longer own.
The honest framing is that MCP is not faster or cheaper for a single integration. It wins when the number of sources grows, or when you want more than one agent to reach the same source without rebuilding.
What you can produce once a data source is connected
Connection is the plumbing. The reason anyone bothers is the deliverable at the end.
With a data source wired in, an agent can pull the current numbers and run the analysis. What comes back is finished: a chart, a written summary, a set of slides. The value comes from removing the export step, not from the protocol itself. The deliverable is also what makes the setup worth defending internally. A connection nobody turns into a report gets switched off quietly.
Powerdrill Bloom ships a server on this pattern. Per its own documentation, it authenticates with your User ID and Project API Key. A client can then browse the datasets in your account, pull details about any one, and run jobs by asking questions in natural language. It works with Claude Desktop and other compliant clients. The MCP server announcement covers the setup, and the data connectors page lists the other source types.
When you do not need MCP at all
This part gets skipped in most explainers, so it is worth stating plainly.
If your data arrives as a file, you do not need a protocol. You need an upload. A quarterly export, a CSV someone emailed you, a PDF statement — none of those justify standing up a server. Drag the file in and ask your question.
Ask one question before you build. Will this same export be needed again next month, by someone other than you?
MCP earns its keep when the source is live and recurring. A database that changes hourly, a ticket queue, a warehouse table that feeds a weekly report. The test is whether you would otherwise export the same thing again next week.
There is also a security dimension. A connected source is a standing grant, not a one-time share. The 2026-07-28 authorization changes exist because that distinction matters.
The short version
MCP is a standard plug between agents and data sources. The 2026-07-28 release made the core stateless, moved routing into headers, made list results cacheable, and tightened authorization. Roots, Sampling, Logging, and the old HTTP+SSE transport are deprecated with a twelve-month window.
For a one-off file, skip all of it. Try Powerdrill Bloom free — upload the file, ask your question in natural language, and export the chart or deck. If you are comparing server options, see the best MCP platforms.
Frequently asked questions
What does MCP stand for?
Model Context Protocol. It is an open standard for connecting AI clients to tools and data sources through one interface. Each new source then avoids a bespoke integration.
What changed in the MCP 2026-07-28 spec?
The core became stateless, dropping sessions and handshakes. Multi Round-Trip Requests replaced server-initiated requests over open streams, and routing moved into the Mcp-Method and Mcp-Name headers. List results became cacheable, and authorization was hardened with issuer validation and issuer-bound credentials.
Is MCP the same as an API?
No. An API is one vendor's interface to one system. The protocol is a common wrapper that many systems can implement, so any compliant client can discover and call them without custom code per source.
What is deprecated in the new MCP spec?
Roots, Sampling, and Logging are deprecated, as is the legacy HTTP+SSE transport. Dynamic Client Registration gives way to Client ID Metadata Documents. The maintainers stated a twelve-month minimum window before removal.
Do I need MCP to analyze a spreadsheet with AI?
No. For a file you already have, uploading it is simpler and faster. The protocol is worth setting up when the source is live and you would otherwise re-export the same data on a schedule.