If you use Claude, ChatGPT or Copilot, you have probably noticed the ceiling: they can help draft a client email or a legal document. What they cannot do is tell you anything about your firm — which questionnaire your clients are actually filling in, what your welcome email currently says, which of your intake sections people abandon. It does not know, because it has no way to look.
It also cannot configure your Legal Tech software. Until now.
The Model Context Protocol is the answer the industry settled on. This article explains what it is, what it is realistically good for in a law firm, and more usefully, what to ask any vendor who tells you they support it.
What MCP actually is
MCP is an open standard for connecting an AI assistant to a specific software product, with the account holder's permission. Anthropic published it in late 2024 and it has since been adopted by the other major assistant vendors, which is the only reason it is worth your attention: it is a shared standard rather than one company's proprietary hook.
Mechanically, a vendor publishes a set of operations their product will accept — a defined list, not open access. You authorise a connection from your own assistant account. From then on you describe what you want in plain language, the assistant picks the operations that achieve it, and the vendor's software does the work and records who asked.
The useful comparison is to the integrations you already have. A traditional API integration or an automation tool needs somebody to build the workflow in advance: when this happens, do that. It is excellent for things you do a thousand times and useless for the thing you need today. MCP inverts it. Nobody builds the workflow. You say "duplicate my standard intake, call it Trust Intake, and strip out the sections that only apply to simple wills," and it happens, once, because you asked.
Why this matters in a law firm, and where it doesn't
Set aside the AI-does-your-legal-work framing. That is a separate argument with separate risks, and it is not what a connector is for.
The work MCP is actually good at is the administrative layer that every firm carries and nobody has time for. Your intake questionnaire needs a section on digital assets. Your client emails or reminders need a refresh. Your letterhead needs an update. The list goes on, and none of this is difficult work. All of it is the kind of work that sits on a list for eleven months, because it means learning a settings page well enough to change one thing in it, and the client-facing work is always more urgent.
That is the real cost of configurable software: the configuration is possible in theory and deferred in practice. A connector collapses it, because describing the outcome is faster than finding the screen.
What it is not good for, and what you should be suspicious of anyone claiming: it is not judgment, it is not advice, and it does not remove your obligation to check the result. The assistant is operating your software. You are still the one responsible for what your software does.
The question that actually matters: what can it see?
Here is the distinction we would encourage every firm to insist on, because it is the whole ballgame and it is easy to miss.
There are two completely different things a connector might reach:
| Surface | What it holds |
|---|---|
| The configuration surface | How your software is set up. The questions on your intake form, your email templates, your document styling, your firm settings. Sensitive to your business, but it contains nothing a client told you. |
| The data surface | What your clients entered. Answers, assets, account details, family relationships, documents. Confidential client information, every byte of it. |
A connector can be built to reach one, or both. The two choices look identical in a demo and are not remotely the same thing. You already know what your confidentiality obligations require; the practical problem is that "we have an AI integration" tells you nothing about which side of that line it sits on.
So ask. And ask for the answer in terms of what is possible, not what is intended — "the AI is instructed not to look at client files" is a policy, and policies are not boundaries. The answer you want is that no operation exists which returns client data, so there is nothing to instruct.
What to ask a vendor about their MCP connector
- What is the complete list of operations? It should be a finite, published list. "It can do anything you can do in the interface" is a different and much larger claim.
- Can any operation return client data? Not "will it" — can it. If yes, you need to know exactly which ones, and decide whether that is acceptable to you.
- Can it read our stored credentials? API keys and integration tokens should be excluded from the connector entirely, in both directions.
- Who is allowed to connect, and is that checked on every request? A token checked once at setup is weaker than an identity re-verified on each call.
- Is every request recorded, including reads and refusals? Changes alone are not enough. A single read can export your entire configuration, and a blocked attempt is exactly what an audit trail exists to show.
- Can we revoke access instantly, and is there a kill switch separate from the token? You want to be able to shut it off without first finding the credential.
- What happens on a destructive request? Anything irreversible, anything that emails a client, anything that reaches every client at once should be refused on the first attempt and require explicit confirmation — enforced by the software, not left to the assistant's discretion.
- Is the assistant vendor a subprocessor now? Understand what leaves your system and where it goes, and check it against the agreements you already have.
Take that list to any vendor, ours included. A good connector is defined by what it refuses, and a vendor who has thought about it will have crisp answers to all eight.
How Eternal Pro answers those questions
Briefly, since the detail lives elsewhere in this knowledge base.
The Eternal Pro connector is configuration only. It reaches your intake questions, questionnaires, email templates, document exports, translations and firm settings. No operation returns a client's answers, contacts, assets, documents, passwords, emergency card or vault — there is nothing to instruct it not to do, because nothing is there. Stored credentials are excluded in both directions. The one operation that resolves a client returns the matter structure and never so much as the client's name.
Every request re-verifies that the person asking is a real administrator on your install, so a stolen credential still cannot act as somebody who is not one. Every request is written to your audit trail, attributed to a named person, reads and refusals included. You can revoke a token, rotate it, or switch the whole connector off from your own settings page. Anything consequential is refused on the first attempt with a plain statement of what it would do.
Connecting it uses your own assistant subscription. There is no key to buy from us and no per-request cost.
Where this is going
Worth being honest about maturity. MCP is young. The standard is settled enough to build on and broad adoption is recent, which means the firms connecting their software this year are early. Early is not reckless — the boundaries are enforceable and the audit trail is real — but it does mean the tooling will look different in eighteen months.
What we think is durable is the direction. Configuration by conversation is simply better than configuration by settings page, for the same reason a good assistant beats a good filing system: you describe the outcome instead of learning the mechanism. The firms that get value from it first will be the ones that asked the boundary question early and got a straight answer.
If you want to see it working, the setup is documented here:
Part 1 — Setting up the Claude integration
Part 2 — Connecting Claude with the MCP Connector, and
Part 3 — What you can ask Claude to do.
How to import clients from Lawmatics using a Zapier webhook ?
How to import clients from MyCase using a webhook ?
How to sync client intake data to Lawcus?
united states
