# Thinking Beyond MCP, What We Learned Building Integrations for Legal AI > Source: > Published: 2026-10-09 00:00:00+00:00 Giving an AI system access to external applications raises a foundational architecture question: how should it reach them? When you connect an AI agent to workplace tools, you immediately hit a core architecture choice: do you use direct API integrations, or adopt and open standard like Anthropic’s [Model Context Protocol](https://www.anthropic.com/news/model-context-protocol) ([MCP](https://gc.ai/blog/mcp-for-legal-teams))? At GC AI, our [Agent Connectors](https://gc.ai/agent-connectors) now connect to more than 20 legal and enterprise platforms, from document management and email to CRMs and billing systems. Across all of them, the biggest lesson we’ve learned is that the protocol itself rarely matters. The hard work is always tool design: what data gets returned, how tightly actions are scoped, and where human approval is required. ## 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 solves discovery and calling conventions, but it delegates the critical product decisions to whoever wrote the server: how tools are scoped, what data payloads look like, and how permissions are enforced. If MCP makes tooling interoperable, why not just wrap our own bespoke integrations in MCP servers? In practice, three things pushed us toward direct API: 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 signatures, disclaimers, and quoted replies stripped out. A secondary tool fetches specific full messages only if necessary. The agent gets the context it needs in a single pass without blowing through token limit. ### 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. **Takeaway from real workloads:** Focused tools with minimal, clean payloads make models faster, more reliable, and dramatically cheaper. Anthropic observed similar results when optimizing tool definitions. In one case, dynamically scoping tools cut context usage from 150,000 token down to 2000. ## 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. ## The takeaway 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](mailto:partnerships@gc.ai).