How RelativityOne MCP Is Reshaping the Legal Technology Stack for eDiscovery Teams

Most conversations about new technology in eDiscovery start with document review. That makes sense. Review is expensive, deadline-driven, and where case strategy meets legal judgment. But one of the more consequential shifts in legal technology is happening at a different layer: the connection between systems.

For eDiscovery professionals, that's what makes the Model Context Protocol (MCP) worth paying attention to.

What MCP Actually Does

MCP is an open protocol that gives software applications a standardized way to interact with external systems and data sources. In practice, it creates a governed interface between front-end tools and enterprise platforms. As a result, legal teams spend less time relying on manual exports, copy-and-paste handoffs, and one-off API projects.

eDiscovery work moves across a long list of systems. A single matter may touch matter management, Microsoft 365, collaboration platforms, legal hold tools, forensic collection software, RelativityOne, document management, ticketing, billing, and reporting.

Review is only one part of the process. Teams are also creating matters, provisioning workspaces, applying templates, granting access, confirming field values, checking groups, tracking usage, and documenting what happened. MCP creates a path to manage those handoffs without leaving the controls that already exist in each platform.

What the RelativityOne MCP Server Does Today

Relativity's current MCP implementation is focused on administration, not document review. The RelativityOne MCP server supports day-to-day administrative tasks: managing matters, configuring workspaces, granting access, and reviewing system usage. It currently supports Claude.ai, Claude Code, and Claude CoWork.

That distinction matters. This is not a document-coding tool. It does not replace attorney judgment or serve as a review workflow. It is a controlled interface that lets an authorized administrator request specific administrative actions inside RelativityOne.

The current toolset includes functions for listing and creating clients, creating and editing matters, listing users and groups, adding or removing workspace groups, creating workspaces from templates, retrieving workspace details, listing object types, retrieving fields and choices, and generating or downloading usage reports.

The practical value is immediate. A system administrator can submit requests such as:

• Show me all external users and the workspaces they can access.
• Create a new matter under this client and build a workspace from the standard template.
• Generate a storage usage report for the last 30 days.

The interface selects from tools exposed by the RelativityOne MCP server based on the request and the permissions assigned to that user. It is not logging into RelativityOne and navigating screens. It is calling approved functions under the identity of the authenticated user.

How the Architecture Works

The setup is straightforward. RelativityOne exposes a remote MCP server. The user connects by appending /mcp to the tenant URL and authenticating through RelativityOne. Authentication uses OAuth 2.0 and flows through the existing RelativityOne login. User credentials remain within RelativityOne rather than passing through the connecting interface.

Once connected, approved RelativityOne tools are available. Those tools run under the authenticated user's identity. Relativity documents that the MCP server acts as the signed-in user, that actions are recorded under that identity, and that Relativity Audit captures all actions taken through the server.

That audit trail is an important design consideration for eDiscovery. The question in legal workflows is not only whether a system can perform an action. It is whether that action is permissioned, attributable, auditable, and explainable later.

The Operational Case for Connected Legal Systems

Some of the most time-consuming work in eDiscovery isn't document review at all. Workspace setup, user access reviews, matter provisioning, and usage reporting are repetitive but sensitive tasks. They require accuracy, proper permissions, and documentation. MCP reduces the manual work involved while preserving the controls already built into RelativityOne.

MCP also lays the groundwork for a more connected legal technology environment where controlled movement between systems replaces manual handoffs.

A practical near-term workflow might look like this: a new matter is approved in a matter management system. An administrator gathers the matter number, client name, responsible attorney, billing code, and data sources from approved systems. The corresponding client, matter, and workspace are created in RelativityOne using the correct template, required fields are confirmed, access groups are checked, and a setup confirmation is posted to the project team. Where other systems are connected, a service ticket can be opened, the document management workspace referenced, and a standard intake summary generated.

The individual steps are recognizable. The hard part has never been connecting systems. It's deciding how those connections should work. Who can trigger actions? Which actions require confirmation? What data can leave each system of record? How will the workflow be audited?

Governance and Access Controls Come First

MCP should not be treated as a shortcut around access control. It is another administrative interface into sensitive legal systems and should be governed accordingly.

Relativity's current implementation requires the authenticated user to be a System Administrator with the granular permissions required for each operation. Because of that requirement, it is not currently possible to grant specific users within a client domain access to this capability on a more limited basis.

That requirement should shape deployment strategy. Most organizations should start with a small group of trained administrators, defined use cases, approved request patterns, and documented review points for create, edit, delete, and access-change actions.

Confirmation behavior also deserves close attention. Some MCP tools support elicitation — a prompt for confirmation or additional input before create, edit, or delete operations — but support depends on the client being used. Relativity currently identifies Claude Code as supporting elicitation, while Claude.ai and Claude CoWork do not. Tools that would otherwise prompt for confirmation may execute immediately in those clients. For teams using MCP to add groups to workspaces, remove access, or create matters, the organization should know before deployment whether a confirmation step is in the workflow.

Data governance is equally important. Relativity's MCP server runs in the same region as the RelativityOne instance, but once data leaves the MCP server and enters the connected interface, it moves according to where that tool is deployed. Relativity advises organizations to review their provider agreements to understand how accessed data may be used, retained, or processed.

That means technical rollout should involve legal, security, privacy, and eDiscovery leadership before deployment begins. The policy questions are concrete: which account types are approved, whether free accounts are prohibited, whether zero-retention agreements are available or required, whether prompts and outputs are retained, whether administrators may use mobile devices, whether multiple Relativity tenants may be connected, and how exceptions are logged.

Relativity also specifically warns that connecting multiple RelativityOne instances through separate custom connectors is not officially supported and that the interface has been observed to retrieve data from the wrong instance under certain conditions. For teams managing multiple clients, matters, or regulated environments, that warning deserves serious attention before deployment

Where RelativityOne MCP Goes from Here

RelativityOne MCP is starting with administrative workflows, which is the right place to begin. Matter setup, workspace creation, group access, field review, template use, and reporting are structured enough to support controlled execution while delivering real operational value.

The next wave of MCP functionality will likely expand further into workspace administration. Future capabilities may include saved search management, view creation, layout review, dashboard setup, batch creation, persistent highlight set checks, and production-prep validation. These are areas where small configuration errors create significant downstream problems.

Quality control is another likely area. MCP could help administrators verify that required fields exist; groups have expected permissions, production fields are populated, documents have extracted text, or that a workspace matches a standard template. That type of workflow is particularly useful for teams managing large numbers of active matters.

Matter reporting will likely grow as well. Usage reporting is already part of the toolset. Future capabilities may help teams answer operational questions across matters. Teams could use it to identify inactive users, monitor storage growth, track completed productions, and find workspaces that are missing required administrative documentation.

The broader opportunity is integration across the legal technology stack. If MCP continues to mature across legal platforms, a matter opened in a matter management system could trigger a RelativityOne workspace setup. A ticketing system could receive status updates from RelativityOne. A billing or reporting system could receive usage summaries automatically. The MCP layer would not replace those systems. It would give authorized users a controlled, auditable way to move work across them without manual handling at each step.

A Deployment Checklist for eDiscovery Teams

The right response is not to connect everything immediately. The right response is to build a controlled pilot with defined boundaries.

Start with low-risk administrative workflows. Workspace template selection, usage reporting, group access review, and field inventory are good candidates. Avoid broad write permissions until the team has confirmed confirmation behavior, logging, account controls, and escalation procedures.

Document the architecture before going live. Identify the RelativityOne tenant, the MCP endpoint, the authorized administrators, the account type being used, the data retention terms, and the data flow paths. Treat the MCP connection as part of the eDiscovery environment, not as an informal productivity shortcut.

Create request and action standards. For example, require administrators to include client name, matter number, workspace template, responsible project manager, and access group when requesting workspace creation. Require a separate confirmation step before access changes. Require exported logs for certain actions until the audit workflow is fully understood and tested.

Coordinate with security and privacy teams before use in active matters. MCP tools perform real actions in production systems. Internal policy should define user authorization, allowed use cases, prohibited use cases, logging requirements, approval workflows, and incident response procedures.

Finally, think beyond RelativityOne. The legal technology stack is moving toward connected systems that work across document management, contract repositories, research platforms, eDiscovery systems, and work product tools. The organizations that will benefit most are the ones that define their governance model now, before new use cases multiply and controls become harder to retrofit.

The Bottom Line

RelativityOne MCP represents a meaningful shift in how eDiscovery teams can operate their legal technology stack. The near-term use case is administrative: matter setup, workspace configuration, access governance, and reporting. Looking further ahead, legal systems are becoming more connected, and governed interfaces are emerging as a standard way to manage enterprise workflows.

The opportunity is real, but so is the responsibility. MCP should be deployed with the same discipline applied to collections, review, productions, and audit trails. The value is not in automating legal judgment. The value is in giving authorized users a controlled, auditable way to move legal data workflows forward across the systems where the work already lives.