Updated 21 August 2026 to reflect the 2026-07-28 MCP specification. MCP can let an AI application retrieve a document, query a system or call a workflow. It does not tell the application which facts the legal team has accepted, rejected or left unresolved. Legal technology discussions often use "connected" and "context-aware" as though they describe the same thing. MCP solves the connection problem; the surrounding system still has to supply the legal context.

What MCP provides

The Model Context Protocol is an open standard for connecting AI applications to external data and tools. An MCP server exposes capabilities. Those capabilities can include tools the model may call, resources the application may read, and prompts supplied by the server. The current TypeScript SDK describes the server as the component that exposes those items to any compatible MCP host. An MCP client sits inside the AI application or host. It connects to the server, discovers the available capabilities and sends requests. A host may manage several clients, each connected to a different server.

In practical terms:

a document system might expose a tool for searching or opening a document;
a factual-record system might expose a resource containing reviewed matter facts;
a billing system might expose a tool for retrieving matter information;
an AI application with an MCP client can use those capabilities subject to the permissions granted.

The 2026-07-28 specification moved MCP's core to a stateless request and response model. Each request carries the information needed for routing and authorization rather than depending on a long-lived protocol session. That change improves deployment and scaling. It does not change the legal architecture question: what information or action is being exposed, to whom, and with what consequence?

The difference between a server and a client

The server/client distinction determines where Mary or another product can appear. An MCP server makes a product's capabilities available. It does not create a user interface inside every legal system. An MCP client is the part that can call the server. If a general AI application has an MCP client, it may be able to use Mary's MCP server from that application. If a DMS or eDiscovery platform has its own MCP client, it may be able to call Mary directly from within that platform, subject to the integration and user experience the provider has built.

Where a platform has no MCP client, the existence of Mary's server does not place Mary inside that platform by itself. The connection can still be made through another compatible host or through a conventional API integration. This is why an announcement that a vendor has "an MCP integration" needs one more question: is it exposing a server, operating a client, or doing both?

Connection does not create matter understanding

MCP can standardise the route to information. The server still decides what it exposes, and the host still decides how the retrieved information is used. A document resource may provide the contents of a file. The protocol does not determine:

whether that file is material to the issue;
whether another document contradicts it;
whether the team previously rejected an inference drawn from it;
whether an expected attachment is missing;
whether the lawyer has approved the extracted fact.

Those are properties of the system and the matter state behind the connection. A legal AI application may have access to all the right systems and still rebuild its factual view each time. The connection is working. The reviewed context is missing.

Authorization is necessary and narrower than governance

The MCP authorization specification uses OAuth-based controls for protected remote servers. Access tokens should be issued for the intended resource, validated by the MCP server and kept separate from tokens used with upstream systems. That addresses who may call the server and which scope has been granted. Legal governance adds other questions:

Is the user permitted to access this matter and this document?
Does an ethical wall apply?
May the tool read only, or can it update another system?
Does the proposed change require lawyer approval?
Is the action recorded in an audit history?
Can the change be reversed?

The protocol can carry identity and authorization information. The connected systems have to enforce the firm's substantive permissions. MCP tool annotations can describe whether a tool is intended to be read-only, destructive or idempotent. The MCP project is explicit that these are hints rather than hard enforcement. An untrusted server can describe its tool inaccurately. A firm still needs controls at the host, network and application layers.

What should travel across the connection

A raw document is only one kind of legal context. For litigation work, a connected system may need access to:

the source documents the user may lawfully read;
the reviewed facts relevant to the task;
the issues, parties and entities used by the matter;
known conflicts and missing material;
the lawyer's prior corrections;
the approval state attached to proposed changes.

The correct set depends on the task. A research agent may need the legal question and jurisdiction without the full evidentiary record. A witness-preparation workflow may need the approved factual record, the witness's prior statements and the documents that contradict them. Supplying everything to every tool is not a context strategy. It increases exposure and can make the model's job less clear.

A workable legal architecture

A firm might keep source documents in its DMS or eDiscovery environment, maintain the reviewed factual record in a specialist system, and use one or more AI applications for research or drafting. MCP can reduce the number of bespoke connections between them. The DMS server can expose authorised documents. The factual-record server can expose reviewed facts and source links. The AI host can call those servers through its clients. A separate write tool can return approved work product to the DMS.

Each system retains its own responsibility. The DMS governs the documents. The factual system governs the reviewed factual state. The host decides which tools the model may call. The lawyer approves work where the consequence requires it. The system comparison explains those responsibilities in more detail. The correction article covers what should happen when a lawyer changes the factual state.

Questions to ask about a legal MCP integration

A useful technical review should answer:

Which product is the MCP client?
Which product is the MCP server?
What tools, resources or prompts are exposed?
Which permissions determine what each user can see?
Which actions can change a matter or another system?
Where is approval required?
What is logged?
What state persists after the request ends?

The latest MCP specification improves the mechanics of connecting systems. The quality of the legal workflow still depends on the information, permissions and review process behind those mechanics.

Verification in Legal AI Is a Design Problem

What MCP Means for Legal AI: Connection, Context and the Factual Record

A practical explanation of MCP clients and servers, what the protocol connects, and why legal context, permissions and reviewed factual state still need to be designed.