Thinking Beyond MCP, What We Learned Building Integrations for Legal AI

Giving an AI system access to external applications raises a foundational architecture question: how should it reach them?

Two approaches dominate. The first is the Model Context Protocol, an open standard introduced by Anthropic in November 2024 for connecting AI applications to external tools and data. The second is direct API integration, where a product team builds and manages the connection to each platform.

Legal teams want AI that works inside the tools they already use: email, file storage, calendars, contract management, and CRM. At GC AI, our Agent Connectors now reach more than 20 of those destinations. Building them, the main lesson we learned is that the hard problems sit in the design of each tool. What can it do, what does it return, and which actions need a human to sign off? The protocol used to call the tool matters far less.

Two Integration Models

A direct API integration means the product team builds the tool layer itself: tool definitions, schemas, response shaping, and auth checks. That takes more engineering work, but it gives full control over scopes, payloads, and observability. MCP standardizes how tools are discovered and called, so any compatible client can use any server’s tools without custom code. That makes integration faster, but the server’s author decides which tools exist and what they return.

MCP and direct APIs sit at different layers

MCP standardizes how an AI application finds and calls tools. It leaves the important product decisions to the builder: which tools exist, how narrowly they’re scoped, what data they return, and which actions require approval. Those decisions come up whether a tool sits behind an MCP server or a direct API call.

So a reader will fairly ask: why not put your curated integrations behind MCP? Three reasons:

1. We own both ends. MCP’s biggest payoff is interoperability: any compatible client can use any compatible server. Our connectors serve one client, our own agent. Putting them behind MCP would add a protocol layer, a server to run and secure, and an extra network hop, without adding a single new user of the tools.

2. Third-party servers lock in someone else’s tool design. A vendor’s MCP server exposes the operations its developer chose, often as a thin layer over the full API. The examples below show why we wanted to design those operations ourselves.

3. Controls belong in the call path. Our permission model has layers. An organization enables a connector, each member connects their own account, and read, write, and delete actions are permitted separately, with approval steps where the stakes call for them. The connected app’s own permissions still apply. Enforcing all of that in the same code that makes the API call gives us one place to audit. It also means we don’t have to vet the credentials, dependencies, and tool outputs of each new third-party server. OWASP and Microsoft both identify tool poisoning and prompt injection through tool outputs as risks there.

MCP is still a strong choice for prototyping, broad read-only access, and platforms where the vendor maintains a reliable server. For confidential legal work and consequential actions, owning the design has paid off for us.

What the difference looks like in practice

Finding the right document in a matter folder

The task: “Pull the latest draft of the MSA from the Acme matter folder.”

Through a generic MCP server: The agent would likely get a general search tool that mirrors the platform’s search endpoint. A query for “MSA” would bring back matches from across the user’s whole drive, each with full metadata. The model would then have to page through results, filter by folder and date itself, and decide which file is the latest. Every extra call adds time, and every irrelevant result is confidential data the model didn’t need to see.

With our direct integration: A scoped tool lists files in a specific folder, filters by date range and file type, and returns only the name, modified date, owner, and link. The agent finds the right draft in one or two calls, with a payload of about 10 KB.

Following an email negotiation

The task: “Summarize where we landed with opposing counsel on the indemnity cap.”

Through a generic MCP server: Email tools typically search and return individual messages with their raw bodies. In a long negotiation thread, each reply repeats everything before it, along with signatures and disclaimers. The model would spend much of its context on duplicate text, and responses would slow down as threads grow.

With our direct integration: Search returns results grouped by thread, with quoted history and signatures removed. A separate tool fetches a full message only when the model needs one. The agent reads the negotiation once, in order, with payload / latency figures.

Updating a CRM record

The task: “Update the Salesforce opportunity with the signed contract date.”

Through a generic MCP server: A general update tool would expose every field on the record. The model would have to choose among several similar date fields. A reviewer approving the action would see a generic “update record” call, which makes it hard to tell exactly what will change.

With our direct integration: Narrow write tools have explicit field lists, so the model can only write to the fields that action allows. Before anything runs, the user sees an approval prompt showing the exact change, and the action is governed by the organization’s write permissions for that connector.

The common thread: Smaller tools with tighter outputs make an agent more accurate and cheaper to run. Anthropic has reported the same effect at the protocol level. In one example, loading tools only when needed cut context usage from 150,000 tokens to 2,000.

How we evaluate each new connector

1. How deep is the access? Light, read-only access can work well over MCP. Write actions or privileged data call for an integration we design ourselves.

2. Can we shape the tools? If the best tool for the job doesn’t exist on an available server, we build it.

3. Where do approvals live? Per-user, per-organization, and per-action controls need a deliberate design, whatever the protocol.

4. Who owns the trust boundary? Someone has to maintain the server, review changes, protect credentials, and respond when behavior shifts.

Conclusion

MCP is a great step forward for ecosystem interoperability, quick prototypes, and broad read-only workflows. But when handling confidential legal files, strict audit trails, and high-stakes write operations, owning the API layer gives us the precision and safety our customers need.

Building for in-house legal or want your platform integrated into GC AI? Reach out to partnerships@gc.ai.