Product names, plans and features change often. Check the vendor’s current documentation before relying on any detail here, and apply your own jurisdiction’s professional-conduct rules.
Here is the shape of AI in most firms that have adopted it. A paralegal opens the case management system, finds the matter, copies the relevant facts, opens a browser tab, pastes them in, asks a question, reads the answer, copies the useful part, goes back to the case management system, pastes it in the right field.
Every one of those steps is a human being acting as an API.
The copy-paste tax
The cost is not just the minutes, though the minutes add up faster than people expect. It is three other things.
The context is always partial. What gets pasted is whatever the person thought was relevant, decided in a hurry. Claude then answers on an incomplete picture and does so confidently, because it cannot know what was left out.
It is where confidentiality goes wrong. A considered decision about what may go into which tool becomes a snap judgment made forty times a day under time pressure. That is not a policy, it is a hope.
It does not scale. Every new matter costs the same again. Nothing compounds.
Connecting the system directly fixes all three at once. Claude works from the actual record, the access boundary is enforced by configuration rather than judgment, and the setup cost is paid once.
What a connector is
A connector lets Claude reach your apps and services: retrieve data, and where you allow it, take actions. Connect Claude to your drive and it can search your files. Connect it to a ticketing system and it can create issues. Connect it to your calendar and it can read your week.
Underneath, most of this is MCP, the Model Context Protocol. An MCP server sits between Claude and one system and exposes a defined set of operations that Claude may perform there. The point of a protocol, rather than a bespoke integration per tool, is that anything speaking MCP works with anything else speaking MCP.
The important consequence for a firm: a connection exposes a defined list of operations, not general access. What Claude can do in your billing system is what the connector exposes, full stop. Scoping that list is the security control. It is far more reliable than instructing a model to be careful.
Three kinds of connection
They get conflated constantly, and the differences matter.
Ready-made connectors from the directory. Each entry sets out its use cases, its read and write capabilities, and where it is available. You authenticate and you are done. This covers the common ground: drive, mail, calendar, Slack, project tracking. Start here, always.
Custom connectors over remote MCP. Your own MCP server, reachable over HTTPS. You add it under Customize, then Connectors, then Add custom connector, give it the server URL and authenticate. The thing to understand: Anthropic's cloud connects to your server, not your laptop. The server has to be reachable from the internet, which makes this the right shape for a system that already lives on the internet, and the wrong shape for something sitting on a machine in your office.
Local MCP servers and desktop extensions. These run on your own machine and are reached through the desktop app. This is what you want for something local: a folder, a local database, a tool that never leaves the office. Desktop extensions package the same idea for one-click install, which matters when you are rolling out to non-technical staff who will not edit a config file.
Which one you need
A short decision path that covers nearly every firm.
- Is there a directory connector for it? Use it. Do not build.
- Is the system internet-reachable with an API? Custom remote MCP.
- Does it live on a machine in the office? Local MCP server, desktop app.
- Does it have no API at all? You automate around it, not through it, and you note that at renewal.
Point four deserves honesty. If your practice management system is closed, that is a genuine constraint and nothing here removes it. You connect the things that are open, mail, calendar, drive, billing, accounting, and you accept a manual step where the closed system sits. Firms should know that a closed system now carries a real efficiency cost, and factor that in when the contract comes up.
Making a write-capable connection safe
Reading is low risk. Writing is where the thinking goes, and legal MCP setups are fundamentally credential-handling systems: if a token leaks, your firm's name is attached to whatever happens next.
Five rules we apply to every connection we build.
- Read-only until proven otherwise. Most of the value is in reading. Ship the read-only version, use it for a month, and add writes only where the manual step is genuinely painful.
- Expose specific writes, never general ones.
create_time_entryis a safe operation.update_recordis an unbounded one. Build the narrow tool even though the general one is less work. - Delete does not get exposed. Some servers ship with delete or update tools that have no business in a legal workflow. Remove them, or gate them behind explicit confirmation. There is no research task that needs to delete a matter.
- Manual approval until you know its failure mode. Claude pauses and asks before each action. Slow and correct. Move to Auto only once you have watched a workflow run correctly many times.
- Its own credentials, least privilege, rotated. Not a partner's login. A service account scoped to exactly what the connection does, with credentials you can revoke without breaking anything else.
Scope the connection, not the prompt. A connection limited to five safe operations stays safe on the day someone writes a careless instruction.
When you have to build one
Custom work is worth it in a narrow, real set of cases.
The system is yours, or bespoke, and nothing in the directory touches it. The directory connector exists but exposes far more than you want to hand over, and a narrow one is safer. Or the workflow spans several systems and you want one operation that does the whole sequence, rather than Claude orchestrating four connectors and getting it subtly wrong on the fifth run.
A custom MCP server is a small, ordinary piece of software. The work is not in the protocol, it is in deciding precisely which operations to expose and in handling credentials properly. Those are the parts to be careful about, and they are the parts a general developer will underestimate in a legal context, because the question "should this tool exist at all" is a professional-duties question before it is a technical one.
Where to start
Not with your case management system. Start with calendar and mail, on read-only, from the directory.
The reason is not technical. It is that you need to watch this work on something where you can immediately tell whether the answer is right. Ask it what your week looks like and what you have not replied to. You will know within a day whether you trust it, and you will learn what it is bad at on material where being wrong costs nothing.
Then add drive, still read-only. Then billing. By the time you connect the system of record, you will have opinions about permissions that you cannot form any other way.
If you want the connections built and scoped properly, including a custom MCP server for whatever your firm runs that nobody else has heard of, that is the work we do.