On 28 July 2026, the Model Context Protocol reached a milestone that will not have made most legal newsletters. Its 2026-07-28 specification shipped, formalising a set of changes designed to move the protocol from a single-user integration tool into something enterprise infrastructure teams can run at scale. What is interesting, to be plain, is that the protocol shipped at all, on schedule, backed by AWS, Cloudflare, Anthropic and the rest of the infrastructure industry, and that the legal technology market has spent the past six months doing groundwork to reorganise around it.
The shift MCP represents does not fit the shape a lot of legal AI commentary has been trained to describe. It’s not a product launch, a founder pitch, or a valuation. It is a piece of plumbing, and the plumbing is changing what the products above it can do, what they can defensibly promise, and, quite possibly, which of them will still be in business in three years.
What MCP is, in the plainest terms available
The Model Context Protocol is an open standard, introduced by Anthropic in November 2024, that gives AI systems a common way to connect to the tools, data sources and workflows an organisation already runs. Anthropic donated the protocol to the Linux Foundation’s Agentic AI Foundation in December 2025, and it’s now backed by every major foundation-model provider: Anthropic, OpenAI, Google DeepMind and Microsoft. As of April 2026, 28% of Fortune 500 companies had deployed MCP servers in production, and the Python and TypeScript SDKs are together running at close to half a billion downloads per month.
The plainest analogy in circulation is that MCP is USB-C for AI. Before the protocol, if a firm wanted its AI assistant to query the document management system, it needed a custom-made integration. Matter management, a second. Contract lifecycle management, a third. Legal research, a fourth. Every AI tool needed a custom connector for every system it touched, and the result, at any firm running more than one AI tool, was a maintenance problem that most information technology teams would consider insensible to staff for.
MCP replaces that pattern with something closer to a standard port. A system exposes its data and actions once, through an MCP server. Any MCP-compatible AI, whether Claude, ChatGPT, Copilot, or a firm’s own agent, can then connect through a common protocol. Build once, connect anywhere. The underlying system stays where it is, with its existing permissions, security controls and audit trails intact.
For most of 2025, this was largely a developer conversation, but by mid-2026, it has become a market-structuring one.
How fast the legal stack has moved
The most consequential announcement in legal tech this year was, perhaps surprisingly, not a product launch or a fundraise. It was iManage’s release of its MCP Server on 14 May 2026, which made it possible for any MCP-compatible AI system to access governed iManage content without a custom integration, without a bulk data export, and without touching the firm’s existing ethical walls or access permissions. NetDocuments announced its own MCP collaboration with Anthropic two days earlier, on 12 May. Casepoint launched its MCP server on 30 July. Ironclad, Docusign, Relativity and Everlaw are all in the ecosystem.
In it’s analytical spirit, Legal IT Insider’s assessment of the iManage launch is quoted: “iManage’s MCP server is, by design, the substrate beneath them: it makes their products easier to deploy, easier to govern, and easier to switch out, but it also makes them more interchangeable from the firm’s perspective.” NetDocuments’ announcement follows a similar logic but retains a more developed first-party AI surface of its own. “The vendors gain reach,” as the piece put it, “they lose a small amount of stickiness. On balance, most of them will take the trade.”
Writing in Artificial Lawyer, Liam Reid of Legatics argued that MCP is “the standard that decides legal AI’s future.” The article identifies a workflow reality that most firms will recognise. Most law firms now have at least one generative AI tool in production, often several. But the AI sits in one tool. The documents sit in the DMS. The matter sits in the matter management platform. The transaction sits in the transaction management system. And the lawyer sits in the middle, manually moving context from one place to another so the AI can do anything useful. MCP is the piece of infrastructure that could dissolve the middle step.
iManage’s own market research helps explain the pace. Thirty-two percent of organisations in its Knowledge Work Benchmark Report 2026 cited integration complexity as a top barrier to AI adoption. That is exactly the friction MCP is designed to eliminate. When the substrate simplifies, adoption accelerates. Firms that have been sitting on AI pilots because they could not justify another round of custom integration work are now looking at a landscape in which the integration work has, in effect, been done once, centrally, by the systems they rely on already.
What this changes about which legal AI products survive
A protocol that dissolves integration friction sounds like unambiguous good news, and for firms it substantially is. For a certain category of legal AI vendor, it is a strategic problem. The most exposed category is the wrapper. If your product is structurally a chat interface layered over a foundation model with some purpose-built connectors, MCP removes the moat those connectors used to constitute. The firm can now bring any MCP-compatible AI to its own DMS, contract repository or matter management platform, without needing a legal-AI-branded intermediary.
Where that value can sit is worth being specific about, because it is not nowhere. Vendors that own proprietary data (Thomson Reuters’ Westlaw content, LexisNexis’ case law and treatises, or a specialist company’s structured jurisdictional information) sit above the protocol layer, not on it. Vendors that have built verified, defensible workflows for a specific practice area do the same. Vendors whose product is a reasoning layer with genuine domain-specific training, rather than a prompt around a general model, do the same. And vendors whose products encode a client’s own historical decisions, playbooks or risk tolerance in a way a general model cannot replicate, retain a defensible position.
The vendors that do not fit any of those descriptions have a harder next twelve months. This is not a prediction of failure, but an observation that a competitive moat built on integration complexity is a moat that is now being drained.
There is a second, less obvious consequence. If the substrate becomes standardised, competition on the layer above it becomes competition on trust, quality and defensibility rather than on connectivity. The 2026 sanctions data, the growth in judicial standing orders, the EU AI Act’s transparency obligations, and the reported wave of professional-indemnity policy conversations all point the same way: what a legal AI product can defend, not just what it can produce, is now the pertinent question. MCP does not answer that question, but it removes a distraction from it.
The part of the story being overlooked in legal AI commentary
The security story is where most legal-industry writing on MCP has been thin, and where the strongest independent voices are saying something interesting. In May 2026, the United States National Security Agency published a public advisory on MCP security, warning about unverified task propagation, session hijacking and prompt injection risks specific to the protocol. Wiz’s analysis identifies five distinct attack vectors: confused deputy, token pass-through, tool poisoning, server-side request forgery via tool connectors, and rogue server registration. SecurityWeek, in its coverage of the 2026-07-28 specification, notes that the new version shifts critical security responsibilities from the protocol itself to developers and platform operators.
The 2025-2026 incident list, catalogued by researchers including Agentmelt, is long enough to justify being taken seriously: the Anthropic MCP inspector remote code execution vulnerability (CVE-2025-49596, CVSS 9.4), a GitHub MCP server data exfiltration incident documented by Invariant Labs, the Nx build-system npm compromise that used AI CLIs to steal roughly 2,180 GitHub tokens and 20,000 files, and the “NeighborJack” localhost-binding vulnerability that affected hundreds of public MCP servers. OWASP now tracks MCP-specific risks under LLM06 (Excessive Agency) and its emerging Agentic AI Top 10.
The relevance? Law firms and in-house legal teams are custodians of sensitive client information, subject to ethical walls, professional secrecy obligations and tightly-regulated confidentiality standards. A firm connecting AI systems to its DMS through MCP is expanding the surface area over which those obligations have to be defended. iManage’s MCP server was designed to preserve existing ethical walls, permission models and audit trails. Not every MCP server on the wider ecosystem meets that bar, and the distinction between vendor-supplied connectors that inherit source-system permissions and third-party servers that do not is one procurement teams should be actively pressure-testing.
The practical upshot is that MCP does not, on its own, deliver secure integration. It delivers standardised integration, which is not the same thing. The security has to be built around it, at the identity, runtime, audit and deployment configuration layers. The 2026-07-28 specification tightens authorisation controls and hardens the protocol against protocol-confusion attacks, but as SecurityWeek notes, it also formalises that most of the responsibility now sits with the operators. Firms deploying MCP need to procure accordingly.
What operators should be doing about it now
For a firm’s chief information officer, an in-house legal operations lead, or a compliance director evaluating the near-term implications, three practical observations should carry into the next planning conversation.
First, the integration complexity that has held back AI pilots is being resolved, but the security complexity underneath it has not. A firm connecting its DMS to an AI assistant through MCP is not implementing a single feature; it is exposing a governed content repository to whichever MCP-compatible AI its lawyers choose to point at it. The permission-inheritance question should be answered before the connection is made, not after.
Second, MCP-native procurement questions are becoming a legitimate part of any legal AI evaluation. Does the vendor’s product work with the firm’s existing MCP-enabled systems, or does it insist on custom connectors the firm will have to maintain? Does it expose its own MCP server, so the firm’s other tools can query it? Does its value survive substitution to a different MCP-compatible model? These are the kind of questions serious buyers now need to be asking.
Third, the near-term winners are likely to be the firms and in-house teams that treat MCP as an infrastructure decision rather than a feature. Building a well-governed MCP environment, with a curated internal registry of approved servers, proper OAuth 2.1 authorisation, permission inheritance from source systems, and a clear audit trail across every AI-initiated action, is genuine engineering work. It cannot be delegated to the AI vendor, because the AI vendor is now one of several possible clients on the firm’s own protocol infrastructure.
Why this is worth noticing
Standards are the least glamorous part of any technology story. They are also, historically, the part that decides who wins. HTTP decided which internet companies mattered. USB decided which peripheral makers survived. The protocol layer disappears into the substrate, and the products above it get sorted by whether they added value the substrate could not commodify.
MCP is doing that work now, in real time, in a corner of legal technology that most of the profession has been too busy watching valuations to notice. iManage’s launch, NetDocuments’ follow-through, Casepoint’s server, the CoCounsel Legal rebuild on Claude’s SDK, and the retreats away from vendor-specific integration architectures are all part of the same movement. The wrappers that survive will be the ones that own something the protocol cannot flatten. The wrappers that do not will be replaced by any competent AI pointed at the same underlying systems, and the buyer will barely register the transition.
For a legal industry that has spent the last two years arguing about which model is best, that is a notable change in argument. The model matters less than it did. What sits above it, and how it connects to what sits below it, has become the interesting question.
