MCP Connectors in Legal AI: Vendor-Built vs Firm-Built

By Jude Lee · · News

Two lawyers in a small firm conference room reviewing research on a laptop next to case binders

Why one vendor connector is a signal, not a headline

Trade press covering legal technology has reported that Harvey now reaches Midpage through an MCP connector. Treat that as reporting rather than a verified product fact: before you plan anything around it, confirm the current state with each vendor’s own documentation.

The interesting part isn’t the pairing. It’s the plumbing. Two legal AI companies chose an open protocol — the Model Context Protocol — rather than a private one-off integration. When vendors do that, the integration layer stops being a moat and starts being a commodity. That shift matters more to a seven-lawyer firm than it does to a large-firm buyer, because small firms have historically been stuck waiting for a vendor roadmap to reach them.

What MCP is, in one honest paragraph

MCP is an open standard, introduced by Anthropic in late 2024 and published openly at modelcontextprotocol.io, for giving an AI assistant governed access to outside data and tools. An MCP server wraps a system — your document management system, your practice management database, a research platform — and exposes a defined list of actions: search_matters, get_document, create_time_entry. An MCP client (Claude, and increasingly other assistants and agent platforms) calls those actions when it needs them. It is not magic and it is not intelligence; it is a well-specified plug. The intelligence is still the model, and the model still gets things wrong. What MCP changes is that the model can stop guessing from a pasted excerpt and start reading the actual file, with the permissions you granted and a log of what it touched. If you want the mechanics compared against older approaches, we covered plugins vs MCP vs Zapier for law firm automation separately.

When vendors adopt an open protocol, the question stops being “does my software integrate?” and becomes “who do I want holding the keys?”

Three ways your firm gets a connector

Vendor-built connector (inside their app)
The AI lives in a product you buy and the vendor decides which systems it reaches. Upside: nothing to maintain, security reviewed by someone with a compliance team, works on day one. Downside: you get the connectors on their roadmap, in their order, shaped by their biggest customers. If your firm runs an unusual records system or a homegrown intake spreadsheet, you may never show up on that list.
Firm-built MCP server (inside your assistant)
You run an assistant (Claude or similar) and point it at MCP servers you write. Upside: you decide the scope, the read/write boundary, and the order of work. Downside: someone has to own it. Servers break when APIs change, logs need reviewing, and a half-finished connector is worse than none because people start trusting it. See our walkthrough on building a custom MCP server over your firm’s matter data.

The middle path: a vendor-published MCP server, your own assistant

What it is: the vendor writes and hosts the server; you connect your assistant to it. Upside: governed access without writing or maintaining server code, and the vendor carries the API-change burden — usually the cheapest first step for a small firm. Downside: you are limited to the actions and scopes the vendor chose to expose, you inherit their authentication model, and endpoints can change or be deprecated without regard for your workflow. Availability shifts quarterly, so check current vendor documentation rather than any list — including this one.

A worked example: research-to-draft in a litigation boutique

Say a six-lawyer insurance defense firm runs Clio for matters, NetDocuments for files, and a research subscription. An associate drafting an opposition brief today does this manually: pull the complaint and prior motions from the DMS, run research, copy passages into a draft, re-check cites.

With connectors in place, the agent version looks like this: the assistant reads the pleadings from the DMS through a read-only MCP server, pulls the firm’s prior briefs on the same issue, runs a research query, and produces a draft with a table of every proposition and the source it came from.

The obvious failure is that the connector returns a stale or superseded document — the first-filed complaint instead of the second amended one. So build detection into the output, not into trust: require the agent to return document ID, version, and filed date for every pleading it used, and have the associate reconcile that against the court docket before relying on a word of the draft. A connector that can’t tell you which version it read isn’t ready for drafting work.

Notice what did not change: a lawyer still reads and owns everything. ABA Formal Opinion 512 (July 2024) addresses generative AI and the duties of competence, confidentiality, communication and reasonable fees — read it directly rather than a summary, and confirm your own state bar’s position, which may differ.

Where confidentiality and conflicts actually break

Two failure modes deserve specific attention before any firm-built connector goes live.

Scope that ignores ethical walls. An MCP server pointed at the whole DMS under a service account will happily return documents from a matter you have screened a lawyer off. The model has no concept of a screen. Permissions must mirror your existing matter-level access control — ideally by passing the individual user’s credentials through, not a shared admin token.

Logs that become a second confidential file. The audit trail you add for defensibility captures prompts containing client names and facts. If those logs land in a third-party logging service, a general IT ticket queue, or an unretained bucket, you have created a copy of confidential client information outside your retention and breach-notification framework.

Before go-live, a named human should: log in as a screened user and confirm the connector returns zero results for the walled matter; confirm in writing where logs are stored, who can read them, and how long they persist; and confirm the vendor’s training-data terms. Where screening or confidentiality obligations are in play, verify the design with your ethics counsel or state bar’s guidance rather than assuming.

What small firms are actually running today

The honest map for small and mid-size firms has four layers, and most firms touch two or three. Products named below are illustrative examples of each category, not recommendations or an evaluation.

  1. Practice-management AI

    Built-in features in tools like Clio, MyCase or Smokeball — summaries, time-entry suggestions, drafting help. Lowest friction, narrowest scope.

  2. General assistants

    Claude, ChatGPT, Copilot — used for drafting, summarizing, brainstorming. This is where most real daily usage lives, including the ungoverned kind.

  3. Specialist legal tools

    Research platforms, contract review, discovery, citation checking. Deep in one job, usually a closed box.

  4. Connected or custom agents

    An assistant wired into firm systems via MCP, with packaged skills for repeated jobs. This is the layer the Harvey–Midpage style of connector is pushing forward.

Modeling the upside without inventing numbers

Ignore vendor hour-savings headlines, including ours — we don’t have your data. Here is the method, with every input flagged as an assumption you replace:

hours × rate
The only ROI formula that survives contact with a real firm P&L
1–3
Workflows to connect first — example starting point, pick ones you repeat weekly
Read-only
Sensible default access level for a first connector (our opinion)

Assume two associates each spend 3 hours a week pulling and summarizing prior briefs — that’s an assumption; time it for four weeks instead of guessing. Assume the agent credibly handles 60% of that: 1.8 hours. Halve it, because review time is real: 0.9 hours each per week. Over an assumed 46 working weeks and two people, that’s 0.9 × 46 × 2 ≈ 83 hours a year. Multiply by R, your realized rate or loaded cost for that person — not list rate — for a gross of 83 × R. Then subtract assumed license fees, assumed build cost amortized over two years, and assumed maintenance hours × the rate of whoever maintains it. Add, separately, the work that gets done instead of deferred (follow-ups, collections, intake responses) and errors avoided.

Every figure above is a placeholder. If plugging in your own numbers doesn’t clear your costs comfortably under conservative assumptions, don’t build it.

When the answer is “neither”

Some jobs don’t need an agent at all. If your bottleneck is a missing checklist, an unstaffed phone line, or a partner who won’t approve templates, a connector won’t fix it. Rule-based automation in your existing practice management system is cheaper, more predictable, and easier to audit than anything model-driven. And for a solo weighing a big legal-AI platform against a custom build, the honest first move is usually a paid assistant subscription plus a written usage policy — not a development project.

Related: connecting Claude to Clio via MCP and Harvey or CoCounsel against a custom build.

Where is your firm losing billable hours?

Get a free automation audit: we map your intake-to-invoice workflow and show you exactly what's worth automating — before you spend a dollar.

Get a free automation audit

Related guides