Neil Cameron, lead analyst
Author’s Update, 14 May 2026: NetDocuments on 12 May announced its own MCP collaboration with Anthropic, making Claude and other MCP-compatible agents able to search, retrieve and draft against NetDocuments content under the firm’s existing permissions and audit trail, and has indicated that the Legal Context Graph and semantic search will progressively be exposed through that same MCP surface. The graph-versus-protocol contrast that frames this article therefore needs reading as a description of what each vendor led with at launch rather than a permanent architectural divergence: both vendors now offer an MCP surface, and the substantive distinction is moving to what each surfaces through it and how. The analysis that follows holds in the form it took at publication; the compounding-context and per-prompt audit concerns identified below apply to both architectures and are not resolved by the addition of an MCP layer. A separate follow-up will examine the implications of both vendors’ MCP positions in more detail.
Within twenty-four hours of NetDocuments lifting the embargo on its Legal Context Graph, iManage today (14 May) unveils the iManage MCP Server – a standardised, open-protocol connection that allows any AI system to draw on iManage content without bespoke integrations, bulk data exports, or modifications to existing security, ethical wall, and compliance controls. The product will be showcased at ConnectLive Chicago on 19–20 May and ConnectLive London on 9–10 June, with a dedicated launch webinar in between on 28 May. This is the second shoe dropping in the legal DMS market’s AI repositioning – the one Caroline Hill’s 14 April exclusive trailed when iManage CEO Neil Araujo described his forthcoming announcement as a layer sitting on top of the data to provide context for AI, and as significant as the launch of iManage Cloud. We can now see what he meant, and the shape of it is instructive.
Where NetDocuments built a typed, traversable graph – a proprietary semantic substrate keyed in part to SALI’s Legal Matter Specification Standard – iManage has gone in a notably different direction. The Model Context Protocol, originated and open-sourced by Anthropic in November 2024 and since adopted by OpenAI, Google, Microsoft and a long tail of others, has become the de facto standard for connecting AI systems to external data sources. By implementing an MCP server over its content, iManage positions itself not as a context engine in its own right, but as a governed source that any MCP-compatible client – Harvey, Legora, ChatGPT, Claude, Microsoft Copilot, and the press release pointedly adds “or a firm’s own AI agents” – can connect to once and consume from continuously. The architectural philosophy on display here is connectivity rather than construction; standardisation rather than semantic enrichment.
Two answers to the same question
It is worth pausing on the contrast, because two of the leading legal DMS vendors have now arrived, within a day of one another, at materially different responses to the same underlying problem. Both accept the premise that AI in legal work is only as useful as the context it can reach, and that the DMS sits in a privileged position to be the trust-and-governance substrate. Where they diverge is on what the DMS should do with that privilege. NetDocuments builds a richer model of the content – entities, relationships, matter-level structure – and surfaces that model through first-party AI experiences as well as making it available to third parties. iManage exposes its content through a vendor-neutral protocol and lets the AI systems do the interpreting at the other end. The contrast as set out here reflects what each vendor put on the table at launch. NetDocuments has since added an MCP server of its own, and indicates that the graph will be progressively exposed through that surface; whether the result is genuinely the same architectural answer in different wrappings, or two materially different bets that happen to share an access protocol, depends on what the graph actually exposes through MCP and how. Neither approach is obviously right or obviously wrong; they reflect different bets about where value will accrue as the legal AI stack matures.
The bet iManage is making is that firms are not, and will not be, single-AI-tool environments. The release is candid on this: customers “are not choosing one AI tool and stopping there”, and 32% of respondents in iManage’s Knowledge Work Benchmark Report 2026 cite integration complexity as a barrier to AI adoption. The product’s value proposition is that one MCP connection replaces a proliferating list of custom API integrations, and that new AI systems can be added or swapped without an IT project each time. That is a credible read of where many firms now find themselves – running Harvey alongside Legora alongside Copilot alongside internal experiments – and the case for treating the integration layer as a commodity rather than a bespoke build is a reasonable one.
What MCP actually does, and what it does not
Some care is needed in describing what is on offer here, because “open protocol” phrasing can flatten important distinctions. MCP standardises how an AI client and a data source negotiate access, authentication, and tool invocation; it does not, in itself, model legal matters, extract parties from documents, or assemble a matter overview. Those interpretive tasks remain with whatever AI sits on the client side of the connection. What iManage’s MCP server does provide – and this is the substantive content of the announcement – is that the documents stay in place, the AI does not store its own copy, and access is authenticated, permission-bound, and fully logged, with ethical walls and access controls respected. The bulk-export problem that has dogged many earlier law-firm AI deployments is, by design, removed.
That governance posture deserves to be taken seriously, particularly in light of the doctrinal pressure now visible in cases such as the recent SDNY ruling on consumer AI use and legal privilege. Keeping privileged content inside the firm’s governed environment, rather than allowing it to be shipped out to a vendor’s processing infrastructure, is not a cosmetic point. It is the practical pre-condition for AI use to be defensible in the cases where defensibility will be tested. The mechanism iManage has chosen – standardised access from outside, with the underlying repository unchanged – is a sensible architectural answer to a question many firms have been struggling with.
The compounding-context problem
There is a more fundamental question that sits behind both announcements, and it applies to either architecture once one looks closely at what the “context layer” is actually doing. If the layer is just high-quality, deterministic metadata – entities, dates, document relationships extracted by rules – then it is useful, but it is not really what either vendor implies when they describe the layer as substantial enough to be compared, in iManage’s case, to the launch of iManage Cloud. If the layer is, on the other hand, doing what those descriptions suggest – probabilistic reasoning, derived semantic signals, AI-generated context – then two generative engines are working sequentially on the same source documents, and the downstream model sees the source only through the upstream model’s interpretation of it. Errors do not just add; they compound, and the downstream model has no way of knowing that the context it has been fed is itself a confabulation. This is structurally similar to the RAG poisoning risk, except without malice: the invisibility is the same.
The shape of the problem differs slightly between the two vendors, which is what makes it worth setting out side by side. NetDocuments has been explicit that the Legal Context Graph constructs derived signals at the matter and global tiers, and surfaces them to downstream models – first-party and third-party alike – through its context engine. The compounding-context risk therefore applies directly: a partner reviewing AI-assisted associate work needs to be able to verify not only the downstream output but also the upstream representation that conditioned it, and at present it is not clear how that second verification step is meant to be performed. iManage’s MCP Server, taken on its own, looks closer to the escape route – documents stay in place, AI clients connect to a governed source – and on its own would substantially reduce the compounding risk. But the release positions MCP Server as part of a wider AI platform that already includes Ask iManage and the Wayfinder programme, and the question that needs answering at ConnectLive is whether MCP-connected clients pull raw documents from the repository, or pull representations already shaped by iManage’s own AI layer. If the former, the architecture is genuinely additive and the lawyer’s chain of verification remains tractable. If the latter, the same compounding problem applies, one layer over. Precisely the same question now needs to be put to NetDocuments’ MCP collaboration with Anthropic, announced on 12 May. NetDocuments has made the natural argument: a graph that exposes deterministic entity and matter-structure signals through MCP, without replacing the underlying documents the client can still pull, would be the additive-enrichment position rather than the compounding one. That is a coherent answer if the architecture is built that way, but it is at present a positioning claim rather than something demonstrable from the public materials. The 12 May announcement describes Claude and other MCP-compatible agents connecting to NetDocuments for search, retrieval and drafting against the document estate; it does not, on its face, describe the Legal Context Graph as a typed semantic surface that consuming agents can interrogate separately from the documents. The architectural detail that determines which of the two positions NetDocuments occupies in practice is the same detail iManage will need to clarify at ConnectLive, and the assessment in both cases will turn on whether external agents receive raw documents alongside separately-addressable typed assertions, or whether they receive a synthesised context blob in which the line between document and inference has already been crossed.
There is a genuine dilemma here for both vendors, which is worth naming plainly. The obvious way to defuse the compounding problem is to characterise the context layer as deterministic and rules-based rather than generative – closer to a structured knowledge graph than to an inference engine. That answer would reduce the hallucination risk substantially, but it would also drain a great deal of the value claim being made for these layers in the first place. The alternative escape route is to insist that downstream models retain full sight of the underlying documents and treat the context layer as purely additive enrichment, but if that is the case the layer is doing less interpretive work than the marketing suggests, and the Cloud-scale comparisons begin to look strained. There is a substantive technical answer somewhere between these two positions, and both vendors will need to articulate it. The market has not yet, in my view, properly confronted the provenance problem that follows from layering AI on AI in legal workflows, and the two announcements this week make that confrontation harder to defer.
The audit question, in a different form
Readers of the NetDocuments piece will recognise the question that follows. I put it to NetDocuments in the form of how a supervising partner reviewing an associate’s AI-assisted work knows what context the Legal Context Graph fed into the model, and whether that is auditable on a per-prompt basis. The same question applies here in a slightly different shape: when an MCP-connected AI system draws on iManage content, can the firm reconstruct, on a per-prompt basis, which documents, which clauses, and which matter context were retrieved, under whose permissions snapshot, by which AI client, against which model version, and retained for how long? The release commits, in general terms, to authenticated, permission-bound, fully logged access, which is the right starting position. The detail that will matter – and that I shall be looking for in subsequent briefings and at ConnectLive – is the granularity, retention, and exportability of those logs, and whether they can be married with the AI client’s own logs to produce an end-to-end record of what entered the model’s context window. Without that pairing, the firm has half the audit trail; with it, the firm has something a court might one day accept.
Implications for the wider market
For firms, the architectural choice now in front of them is genuinely consequential, and it is one that should be framed as such rather than reduced to a feature comparison. A firm choosing the NetDocuments direction is buying into a richer first-party context model, with the trade-off that the model is proprietary and the firm’s leverage to substitute components is correspondingly reduced. A firm choosing the iManage direction is buying into a thinner, more interchangeable connective layer, with the trade-off that the interpretive intelligence must be sourced elsewhere and the firm carries the integration responsibility across multiple AI clients. Neither bet is foolish. Which one fits depends on whether a firm sees its competitive advantage as residing in its document estate plus a coherent first-party experience, or in its ability to assemble best-of-breed AI components around a governed content core.
For the third-party legal AI vendors – Harvey, Legora, and the rest – the iManage move is materially more comfortable than the NetDocuments move. NetDocuments’ first-party AI surface area competes, at least at the edges, with what those vendors offer. 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’ subsequent MCP announcement narrows but does not close that gap: a third-party vendor can now reach NetDocuments content through the same protocol, but does so against a vendor that has built a more developed first-party AI offering on top of the same repository, and the competitive dynamic is correspondingly different. The vendors gain reach; they lose a small amount of stickiness. On balance, most of them will take the trade.
For the wider question of how the 2026 legal DMS market shapes up, what we have now is genuinely different positioning rather than two vendors making the same announcement in different words. The graph and the protocol are not substitutes; in principle they could even co-exist, with a NetDocuments-style context model exposed over MCP, or an iManage repository feeding a third-party context graph. The 12 May NetDocuments announcement begins to put the first of those possibilities to the test, although the extent to which the graph itself is exposed through MCP – as opposed to MCP sitting alongside the graph as a separate document-access channel – remains to be seen. Whether either vendor moves towards the other’s approach over time, and whether the firms voting with their procurement budgets reward one philosophy over the other, is the question to watch through the rest of this year. The two ConnectLive events in Chicago and London will give the first real read on how iManage’s customer base responds; the NetDocuments private preview will give a parallel read on the other side. By the autumn we shall have a much clearer sense of which architectural bet is gaining traction – and, more interestingly, whether the market turns out to want both.
