MCP & Software Integrations
We connect Claude and other AI to the software a legal team runs on: DMS, CLM, practice management, and Microsoft 365. Using the Model Context Protocol, the AI works inside your systems instead of beside them in a separate window.
The difference between AI that sits beside your systems and AI that works inside them is integration, and in 2026 the standard for that integration has a name: the Model Context Protocol (MCP). We connect Claude and other AI to the software a legal team actually runs on, including document management, contract lifecycle, practice management, and Microsoft 365, so the assistant acts on your real matter data through governed, auditable tools instead of guessing from whatever someone pasted into a prompt. It is part of our Legaltech & AI practice.
What MCP is, and why legal should care
MCP is an open standard, originally from Anthropic, that lets an AI assistant connect to external data sources and tools in real time. 2026 was the year it arrived in legal in force. Thomson Reuters connected Claude directly to CoCounsel Legal over MCP, giving the assistant grounded access to 1.9 billion Westlaw and Practical Law documents with a citation ledger that makes every source traceable. Anthropic’s Claude for Legal shipped with more than twenty connectors into mainstream legal software. The practical upshot is that a lawyer can move between general-purpose AI and citation-grounded legal work without leaving the workflow.
Connectors, not copy-paste
Copy-pasting matter content into a chat window is slow, error-prone, and a confidentiality problem. A connector exposes a system, such as matter data, documents, or a clause library, to the model as a governed tool. The model retrieves what it needs, when it needs it, and every call is recorded. That is the difference between an assistant that can cite your live clause library and one that approximates it from training data.
| Approach | Governance & audit | Maintenance | Use when |
|---|---|---|---|
| Copy-paste | None | None | Never, for client data |
| Custom MCP connector | Full: scoped, logged | You own it | Your systems, bespoke needs |
| Vendor MCP endpoint | Vendor-managed | Vendor-managed | CoCounsel and similar exist |
| Scripts / RPA | Limited | Brittle | No usable API exists |
The systems worth connecting
- Document management. iManage and NetDocuments: search, retrieve, and draft against the document store, with matter-level permissions enforced.
- Contract lifecycle (CLM). Query and draft against the live clause library and playbooks from inside the workflow.
- Practice and matter management. Pull matter context so answers are grounded in the actual file. Legacy systems are not exempt; we have written about reviving dormant InterAction installs.
- Microsoft 365. Word, Outlook, and Excel, where most of the drafting day already happens.
The security model comes first
We design the access model before we build the connector. Authentication and scoping mean the AI only ever sees what the user is already entitled to see, per-matter permissions are enforced at the connector rather than assumed, every call is logged, and customer data is not used to train third-party models and does not leave your environment. Least privilege is the default, not an upgrade. The same posture underpins how we set up document review pipelines and the firm-wide governance framework.
Common pitfalls we are brought in to fix
- Over-broad scope. A connector that can see everything is a breach waiting to happen. Scope to the matter and the user.
- No logging. If you cannot show what the AI accessed, you cannot govern it. Every call is recorded.
- Brittle one-offs. An integration nobody maintains breaks at the next vendor update and gets switched off.
- Connecting everything. Start with the one or two systems that carry the work, not a big-bang of every tool at once.
Build versus buy
Where a vendor already ships an MCP endpoint, like CoCounsel, the fastest safe path is to use it and govern access around it. Where the value sits in your own systems, a clause library, a matter database, a bespoke precedent bank, a custom connector is worth building because it is what no vendor will ship for you. Most firms end up with a mix: vendor endpoints for research and citation, custom connectors for the firm’s own knowledge. We help decide which is which, then build and maintain the custom side.
How a connector gets built
A connector is a small, governed service that sits between the model and a system. We start by mapping what the model needs to read or do, and what it must never see. We define the tools the connector exposes, each one scoped and named, and wire authentication so a call inherits the user’s existing permissions rather than a service account’s. We add logging on every call, test against real matters with real access controls, and only then put it in front of users. The build is deliberately boring, because the interesting failures in legal integrations are all security failures.
Worked example: a live clause library
A corporate team wanted Claude to draft against their actual playbook, not a generic one. We built an MCP connector to their contract system that exposed the approved clause library and fallback positions as a governed tool, scoped to the matters each user could already see. Drafting moved from copy-pasting clauses out of a wiki to asking for the right fallback in context, with the source clause cited. Because the connector enforced existing permissions and logged every retrieval, the firm adopted it without widening anyone’s access by a single document.
Latency, reliability, and the boring guarantees
An integration that lawyers will rely on has to behave like infrastructure, not a demo. We cache where it is safe to, fail closed rather than open when a system is unreachable, and surface a clear message instead of a wrong answer when a retrieval returns nothing. Connectors are monitored, versioned, and rolled back cleanly if a vendor ships a breaking change.
None of this is glamorous, and all of it is the difference between a connector that becomes part of the day and one that gets quietly abandoned the first time it returns a stale clause at the wrong moment. We treat the integration layer as a product with an owner and an on-call expectation, not a one-off script, which is the same standard we hold the platform we operate in-house to.
Build, and then keep it alive
An integration that rots is an integration that gets switched off. We build custom MCP servers for the systems you run, connect to vendor MCP endpoints where they exist, and then own the maintenance, monitoring and updating connectors as vendors change their APIs. If a system has no usable API, we will say so and find a safe path rather than ship something brittle. This integration layer is what makes a Claude deployment stick.