MCP: The Fifth Spec Release of Model Context Protocol

Transcript

The full word-for-word transcript of this episode. Plain text version

Marcus: When we discuss breakthroughs in artificial intelligence, there is this relentless expectation of spectacle. I mean, everyone is always searching the horizon for that flashy new model.

Devon: Right, the one that can write a symphony or pass a medical board exam in three seconds.

Marcus: Exactly. The narrative is almost entirely focused on the brain, you know, on the raw intellect of the system itself.

Devon: And that intellect is captivating, sure. But an isolated intelligence is functionally useless.

Marcus: It really is. An AI without connections, it is essentially just a brain in a jar. It might be brilliant, capable of these profound computational feats, but it cannot actually do anything for you in the real world.

Devon: Yeah, to be useful, it needs to read your local documents or query your corporate databases or manipulate your software applications.

Marcus: Which brings us to the actual reality of the situation. Exactly. The most important updates in AI are not those flashy models at all. They are the invisible pipes connecting those models to the rest of the world. And that is our mission for this deep dive.

Devon: We are examining the Model Context Protocol, commonly known as MCP. And specifically, we are looking at the specification released in July 2026. We are going to unpack the mechanics of what this actually means for you as you navigate this rapidly expanding ecosystem of AI tools.

Marcus: Because the connective tissue is getting hardened. We are moving away from this scattered landscape of custom-built, fragile integrations toward a unified infrastructure.

Devon: And the common story you hear is that every time a new MCP specification drops, it is this massive, headline-grabbing feature release that fundamentally alters what AI can imagine doing.

Marcus: That is always the pitch, isn't it?

Devon: Always. But the reality here is entirely different. This is fundamentally a plumbing release. The July 2026 update is all about statelessness, opt-in extensions and enterprise authentication doing the quiet, unglamorous work in the background.

Marcus: Which is vital work, to be fair.

Devon: Oh, absolutely. It standardises the connection beautifully, but, and this is the crucial part, it completely offloads the security and the trust onto whoever implements it.

Marcus: Well, before we venture into the rather terrifying security implications of offloading that trust, we should probably establish what this connective tissue actually looks like on a mechanical level. I mean, if this is just plumbing, what are the pipes made of?

Devon: Right, let's break that down. At its core, the Model Context Protocol is an open standard. It provides a universal way of wiring large language model applications to external data sources and tools.

Marcus: And it does this using something called JSON-RPC 2.0, right?

Devon: Yes, JSON-RPC 2.0. To demystify that slightly, JSON-RPC is essentially a highly structured, lightweight data exchange format. Imagine a postal service that only accepts very specific, text-based index cards.

Marcus: So it isn't transmitting complex, heavy software binaries?

Devon: No, not at all. It is just sending simple, readable text instructions back and forth. And MCP actually takes its inspiration from the Language Server Protocol.

Marcus: Which is a really telling inspiration.

Devon: It is, yeah.

Marcus: Because the Language Server Protocol was a massive operational triumph for software development. I mean, instead of writing a custom integration for every single code editor on the market, a developer writes one language server, and it instantly works everywhere.

Devon: It solved a huge headache, and MCP is attempting that exact same consolidation, but for AI context and capabilities.

Marcus: So how do we visualise this?

Devon: Think of it like standardising a universal power outlet for artificial intelligence. You have three main components interacting here. First, you have the hosts.

Marcus: These would be the LLM applications themselves, the ones initiating the connection.

Devon: Exactly. Picture them as the physical plug on your appliance. Then you have the clients. These are the connectors sitting inside that host application, acting sort of like the adapter.

Marcus: That makes sense.

Devon: And finally, you have the servers. These are the external services actually providing the context, the data or the capabilities. They represent the power grid itself.

Marcus: But what really stands out in the July 2026 specification is what the architects have deliberately chosen to exclude from that basic connection. If you read the text, it explicitly states that the core protocol is strictly stateless and self-contained.

Devon: Yes, the base protocol simply specifies the message format and handles the per-request capability negotiation. It manages the handshake, but nothing more.

Marcus: Which feels inherently limited at first glance. I mean, a completely stateless core. If the core protocol has absolute amnesia and retains absolutely no memory of what just happened a millisecond ago, it sounds like an omission. It sounds like they just shipped an empty pipe.

Devon: Well, it is an empty pipe, but that is a deliberate design choice aimed at ultimate resilience. By keeping the core stateless, you keep the pipes impeccably clean.

Marcus: Okay, give me an example of how that helps.

Devon: Consider a scenario where a stateful connection breaks. Say you were ordering a complex pizza over the phone. The line drops, you call back, and the restaurant just sends you baked dough because they lost the memory of your toppings.

Marcus: Right, because the state of the order was lost when the connection dropped.

Devon: Exactly. Statelessness means sending the entire complete order every single time. Every request is an independent island. You avoid connections failing in a cascade across the network simply because a server got confused about a sequence of events.

Marcus: So the host asks for a capability, the server provides it, and the transaction closes.

Devon: Spot on.

Marcus: The core protocol acts purely as a transient courier. It handles the introduction, but flat out refuses to carry any historical baggage.

Devon: Yeah, that is the structural reality of it.

Marcus: But that forces a really obvious mechanical question. If the core is just empty, stateless pipes, and it refuses to remember anything, how does an AI execute a task that takes longer than a few seconds? I mean, where does the actual functionality live?

Devon: That is the clever part. The functionality lives entirely in the extensions. This is where the July 2026 release reveals its underlying strategy.

Marcus: Right, they kept the core minimal.

Devon: Yes, the core remains minimal, but the complex, interesting capabilities have been pushed into opt-in extensions. Because they are opt-in, they require explicit support from both the client and the server, negotiated right at the start during that initial handshake.

Marcus: And the specification defines three massive new extensions to bridge that gap. First up, we have Tasks.

Devon: Which is designed for asynchronous, long-running operations.

Marcus: And that extension alone solves a critical bottleneck. Because if you ask an AI to analyse a proprietary corporate database containing, say, 10 million rows, you cannot have the protocol connection just hanging open for 20 minutes waiting for a reply.

Devon: It would just time out.

Marcus: Exactly. So the Tasks extension introduces the concept of polling, mid-flight inputs and durable handles.

Devon: Let's actually define a durable handle for a moment because it is important. Think of it like a coat check ticket at a very busy theatre. The AI hands a massive computational job to the external database server. Instead of standing at the counter waiting for the job to finish, the server hands the AI a durable handle, a ticket. The AI can then sever the connection, go perform other operations for the user, and then come back half an hour later, present the ticket, and retrieve the finished results.

Marcus: Brilliant. Then there is the second extension, Skills over MCP. This one facilitates structured instructions for agent workflows.

Devon: Yeah, it allows an AI to actively discover and consume complex, multi-step capabilities directly through the protocol, rather than relying on hardcoded prompts.

Marcus: And the third one is perhaps the most visually impactful, which is MCP Apps. This extension allows for interactive user interface elements to be rendered inline.

Devon: We are talking charts, forms, interactive maps or even video players directly within the conversation.

Marcus: So the AI isn't simply generating text summaries of data anymore. It is pulling a fully functional, interactive application component from the external server and embedding it directly into your chat window.

Devon: It makes the whole experience significantly more dynamic.

Marcus: But to understand the actual impact of these mechanical changes, we really have to look at how vendors are adopting them in the real world. At the time of this July 2026 release, Claude published a blog post announcing their integration of these very features.

Devon: And the numbers they present there are quite staggering. They list over 950 MCP servers available in their connectors directory.

Marcus: That represents 950 external tools, services and databases wired up and ready to be plugged into the AI's power outlet.

Devon: And they note these connectors are being used by millions of people. They rolled out full support for the new protocol extensions we just discussed. But we do need to place a massive, flashing asterisk next to how they are discussing this integration.

Marcus: We really do, because vendor characterisation is a completely different beast from technical evaluation.

Devon: Absolutely.

Marcus: The vendor's own framing in this blog post relies heavily on sweeping marketing claims. They assert this release brings smoother integration, more consistent behaviour and hardened authentication. I want to caution anyone navigating this space to treat words like smoother and consistent strictly as vendor characterisation. This is a company actively promoting its own ecosystem. It is not an independent, empirical evaluation of the protocol's performance or reliability.

Devon: The distinction is vital. We are parsing the technology here, not endorsing the marketing copy. That being said, the sheer volume of connectors, over 950 supported services deployed at the time of release, is an undeniable empirical signal.

Marcus: That is a massive footprint.

Devon: Regardless of the marketing spin layered on top, that raw number confirms MCP is rapidly consolidating into standard, everyday infrastructure across the industry.

Marcus: The pipes are being laid everywhere, creating a unified grid.

Devon: Yeah, and when infrastructure standardises that rapidly, and vendors rush to celebrate lower friction and easier connections, it inevitably forces us to look at what gets left behind in the pursuit of velocity.

Marcus: Which brings us to the absolute edge of this specification. Security.

Devon: Yes.

Marcus: When you strip away the polite phrasing of the technical documentation, the reality of how this protocol handles trust is genuinely horrifying.

Devon: I know you have strong feelings about this. The trust and safety section of the July 2026 spec lays out the boundaries very clearly.

Marcus: It does. The protocol establishes incredibly powerful connections, allowing autonomous AI models to reach deep into external corporate and personal systems. Yet, if you read the actual text of the standard, MCP outright states that it cannot enforce security principles at the protocol level.

Devon: It standardises the data transfer mechanics, but it deliberately steps back from providing the protection.

Marcus: And the specification explicitly stresses a terrifying reality. These tools represent arbitrary code execution.

Devon: Which is a hefty term.

Marcus: It is. For anyone not steeped in network security, arbitrary code execution is the ultimate nightmare scenario. It means the AI isn't merely having a pleasant text conversation with your database, it is actively running hidden commands, scripts and software directly on your systems.

Devon: Right.

Marcus: Furthermore, the spec declares that descriptions of tool behaviour must be considered completely untrusted by default, unless they originate from a trusted source.

Devon: To put a vivid scenario to that untrusted description risk, an AI might decide to use a tool labelled generate quarterly revenue report. But because that description is untrusted, a malicious or compromised server could have actually attached that label to a script designed to drop all tables and delete the entire database.

Marcus: Exactly. And the AI, reading only the helpful label, executes the destructive code blindly. So how does the protocol handle this massive, glaring risk of a machine blindly executing destructive code based on a lie? It uses a polite suggestion. The specification dictates that implementers SHOULD build consent flows and access controls. In the realm of network security, the word SHOULD is doing an enormous amount of load-bearing work.

Devon: Okay, I am going to push back on your characterisation of this as horrifying.

Marcus: Really? You don't find that concerning?

Devon: I mean, from a pure systems architecture perspective, this is the honest, layered way to design a protocol. You absolutely do not want a low-level data transport protocol attempting to enforce user interface consent constraints. That is a fundamental mixing of architectural layers. The protocol's only job is to move JSON-RPC messages reliably between point A and point B. It is the host application's job to put a prompt on the screen asking the human user, "Are you sure you want to let the AI run this script?"

Marcus: We are not merely moving simple text messages across a wire here. We are facilitating autonomous agents interacting with systems that hold critical, sensitive data. In the context of arbitrary code execution, leaving user consent as a mere SHOULD in the baseline specification is a massive abdication of responsibility.

Devon: But how could the protocol possibly force them? It operates entirely behind the scenes.

Marcus: You are handing developers a universal power outlet telling them it carries high voltage, and then noting in the manual, "You should probably put a plastic cover on this, but we won't force you to build it into the plug."

Devon: It has zero control over the graphical user interface of the host application, though. It is mathematically impossible for the transport layer of a protocol to verify that a biological human being actually looked at a screen and clicked an "I agree" button.

Marcus: Then the protocol architects need to design a mechanism to demand cryptographic proof of authorisation before executing a state-changing tool. Look, the stakes of AI security failures are incredibly familiar to anyone watching this space. When you standardise the plumbing so efficiently, you are simultaneously standardising the attack surface.

Devon: I disagree that it makes it worse.

Marcus: By explicitly documenting that they cannot enforce security, the architects are washing their hands of the inevitable breaches that will occur the very moment some startup decides that building a robust consent flow adds too much friction to their user onboarding experience.

Devon: But standardising the connection is a prerequisite for building any kind of robust security on top of it. If every vendor is using custom, undocumented, proprietary pipes to connect their AI to external tools, securing those connections is impossible because you can't even monitor them.

Marcus: I will grant you that visibility is certainly preferable to total darkness.

Devon: Exactly. By standardising everything to MCP, enterprise security teams finally know what the traffic looks like. They can actually build tools to monitor it.

Marcus: Standardisation allows for better monitoring, yes. But we must land on the practical reality for the people actually deploying these systems. The protocol absolutely will not save you.

Devon: No, it won't.

Marcus: It is a neutral courier. It will pass a malicious, database-destroying command just as efficiently and reliably as a helpful one.

Devon: That is true. The protocol is entirely agnostic to the danger of the payload. So, given this massive security caveat, and the fact that the protocol leaves the door wide open for implementation failures, we have to look at the human element. Who takes on the burden of this risk?

Marcus: This leads perfectly to my favourite diagnostic question for any new technology: who actually pays for this? Who absorbs the cost of the risk, and who reaps the operational rewards?

Devon: The enterprise-facing additions detailed in the Claude release illustrate exactly who this ecosystem is currently built to serve.

Marcus: The enterprise administrators and the connector developers are walking away with massive operational wins. On their telling, the traditional friction of deploying AI tools across a large company has been virtually eliminated.

Devon: The enterprise features are focused entirely on removing hurdles. For corporate administrators, the update introduces provisioning through existing identity providers.

Marcus: To translate that mechanism, an identity provider is the central directory a company uses to manage employee logins.

Devon: Right.

Marcus: Previously, giving an AI access to internal tools meant manually creating new accounts and managing separate passwords. Now, the AI simply talks to the existing directory.

Devon: It just inherits the permissions.

Marcus: Exactly. If an employee is listed in the finance group in the corporate directory, they automatically inherit access to all the corresponding MCP connectors for the finance databases. It is seamless, frictionless provisioning.

Devon: And for the developers publishing these connectors, the release provides sophisticated observability dashboards. They can track exactly how their tools are being utilised by the AI, monitor error rates in real time, and analyse performance metrics across the board.

Marcus: But the most significant addition, which was flagged as a research preview at the time of this release, is a feature called MCP tunnels.

Devon: Oh, MCP tunnels are fascinating. They solve one of the most persistent headaches in corporate IT. It allows the AI application, sitting out on the public internet, to reach servers located deep inside private, locked-down corporate networks.

Marcus: The mechanism of how it achieves this is really quite something. Normally, to allow external access to an internal server, a security administrator has to open an inbound port on the corporate firewall.

Devon: Which is essentially leaving a door unlocked on the perimeter.

Marcus: A massive security vulnerability, yes. But tunnels bypass this entirely by flipping the direction of the connection. The internal server initiates an outbound connection to an external relay point.

Devon: Because firewalls generally trust traffic moving from the inside out.

Marcus: Exactly, so it sails right through. The external AI then connects to that relay point to pass messages back inside. It punches a hole right through the perimeter without requiring public endpoints or inbound firewall rules.

Devon: So the enterprise administrators gain seamless identity provider provisioning, the developers gain beautiful observability dashboards, and they both benefit from magical tunnels that bypass inbound firewall rules to connect external AI directly to internal private data.

Marcus: It is a massive operational triumph.

Devon: It really is.

Marcus: But it represents a massive, silent transfer of risk. Returning to our debate on security, remember that building consent flows is still only a SHOULD in the specification. The friction has been masterfully removed for the deployment and the networking, but all of the actual tangible risk of arbitrary code execution and untrusted tool descriptions is carried entirely by the end users and the enterprise security teams.

Devon: The security teams are the ones who have to clean up the catastrophic mess if that magically tunnelled, seamlessly provisioned AI decides to execute a malicious command disguised as a helpful task.

Marcus: Precisely. The protocol makes it incredibly easy, almost effortless, to connect an autonomous agent to a sensitive corporate database.

Devon: Hmm.

Marcus: But it offers absolutely no guarantee that the AI won't accidentally drop all the tables because an untrusted tool description confused its logic.

Devon: Yeah.

Marcus: The winners in this scenario get smooth, frictionless deployment.

Devon: Yeah.

Marcus: The losers are left holding the bag of consequences when the arbitrary code executes.

Devon: The plumbing is getting incredibly sophisticated, but the water flowing through it remains completely unfiltered.

Marcus: And navigating this landscape requires a fundamental shift in how we view integration.

Devon: So, as you look at wiring your own AI tools together, or as your organisation begins adopting these massive directories of pre-built connectors, keep the mechanical reality in mind.

Marcus: Absolutely.

Devon: The Model Context Protocol will elegantly handle all of the complex plumbing. It will negotiate the capabilities, it will manage the asynchronous tasks with durable handles, and it will render the inline applications flawlessly in your chat window.

Marcus: But the trust, the security and the consent are entirely your responsibility to design, build and enforce.

Devon: In a world where AI can trigger arbitrary code execution deep inside your private network, a SHOULD in a specification document is not a DOES in reality. Never confuse a perfectly functioning pipe with a safe one.

Marcus: It leaves us with a rather unsettling technological question to consider. If we completely standardise the connective tissue between every application we use, making it so utterly frictionless and invisible that we never have to think about it, we might wake up to find we have built a fully automated digital ecosystem that is far too complex for any human being to actually audit. I mean, when the pipes work so perfectly that you never have to look at them, how do you know what is actually flowing through them, and more importantly, who is actually pulling the strings?