Choose Connectors or Engineers: The Enterprise AI Split Behind Anthropic MCP and OpenAI FDE

Anthropic's legal MCP release and OpenAI's Deployment Company answer the same enterprise AI question in opposite ways: Anthropic is trying to make integrations reusable through Model Context Protocol connectors, while OpenAI is putting Forward Deployed Engineers into customer organizations. The practical difference is ownership. With MCP, the integration layer can live in a protocol ecosystem. With FDEs, the integration layer is built and maintained as a client-specific deployment project.

The contrarian read is that this is not mainly a model race. It is a distribution race over who controls the path between a model and the systems of record: law firm document stores, contract systems, e-discovery platforms, financial data terminals, healthcare coding databases, and internal workflows that never become clean APIs.

Anthropic is productizing the integration layer through legal connectors

Anthropic's legal push is a connector strategy, not a generic legal chatbot launch. LawNext reported on May 12, 2026 that Anthropic released more than 20 MCP connectors for Claude's legal workflow surface, plus 12 practice-area plugins and four managed agents for commercial, corporate, litigation, and product work (LawNext, retrieved 2026-05-13).

The connector list matters because it maps onto systems lawyers already use:

TechCrunch described the same move as Anthropic entering a legal AI market already sensitive to "AI slop," especially after lawyers have been sanctioned for citing fabricated cases (TechCrunch, retrieved 2026-05-13). That risk explains why legal is a good stress test for connectors. Legal buyers do not only need answers; they need to know what system was searched, under whose permissions, and what artifacts came back before a human signs off.

That is where MCP changes the product shape. Anthropic's MCP connector help docs say connectors let Claude connect to organizational tools, data sources, and services without leaving chat, and that Claude inherits the user's permissions when a connector uses delegated OAuth (Claude Help Center, retrieved 2026-05-14). For Claude for Government specifically, Anthropic says the MCP service, token storage, and connector-execution audit logging stay inside the FedRAMP High authorized environment. That is narrower than a blanket compliance promise, but it supports the central point: connector execution can be governed as infrastructure, not treated as an invisible prompt trick.

OpenAI is betting that engineers solve the last mile

OpenAI's counter-position is human-intensive deployment. TechWyse's coverage of OpenAI's Deployment Company reports a roughly $4 billion launch backed by TPG, Bain Capital, and Brookfield, built around the acquisition of Tomoro and its 150 Forward Deployed Engineers (TechWyse, retrieved 2026-05-14). The company is designed to embed engineers inside enterprises, redesign workflows, and turn frontier models into durable operating systems rather than isolated demos.

That is a coherent bet. Many enterprise workflows are not waiting for a clean connector. They are spread across legacy databases, spreadsheets, approvals, Slack threads, vendor portals, and exception paths that only a small group of operators understands. A good FDE can sit with the team, reverse-engineer the actual process, build the glue, and own the deployment until it works.

The tradeoff is scalability. One embedded engineering team can go deep on a customer. A reusable connector can serve many customers once it exists. FDE work can become a strong moat for a single enterprise account, but the knowledge often lives in implementation details. MCP pushes the moat toward protocol-compatible tools and reusable workflow primitives.

This is why the "150 engineers vs 20 connectors" framing is useful but incomplete. OpenAI is not claiming 150 engineers replace all enterprise software. Anthropic is not claiming connectors eliminate all services work. The split is about the default path: should enterprise AI adoption begin with a standard connector surface, or should it begin with a custom deployment team?

Legal is the wedge because regulated workflows punish black boxes

Legal is a natural wedge for MCP because it combines high-value work, fragmented systems, and a low tolerance for unsupported claims. A large firm might use Relativity for e-discovery, iManage or NetDocuments for document management, DocuSign or Ironclad for contracts, Datasite for deal rooms, and Thomson Reuters tools for research. The model does not need to replace those systems. It needs a controlled way to query and act across them.

The key is not that MCP magically makes legal AI safe. It does not. The stronger claim is that MCP gives developers and admins a standard place to define tool names, schemas, permissions, and invocation boundaries. Anthropic's tool-use documentation shows Claude returning tool_use content blocks when it decides to call a tool, which gives API builders a concrete event to inspect and log in their own application layer (Anthropic tool-use docs, retrieved 2026-05-14).

That distinction matters for reviewers. The earlier draft overstated the case by implying MCP exposes private model reasoning and resolves legal or financial compliance by itself. A more defensible formulation is: MCP and Claude tool use expose structured tool invocations, and some Anthropic connector environments document connector-execution audit logging. Compliance still depends on the buyer's retention policies, connector permissions, matter scoping, human review, and the downstream system's own audit trail.

Finance and healthcare show the same enterprise pattern

Anthropic's legal move is not isolated. Its finance agents release follows the same vertical playbook: reference workflows plus connectors into the tools finance teams already use. Anthropic lists ten financial workflow templates, including Pitch Builder, Earnings Reviewer, and Credit Memo, plus connectors for Moody's, Dun & Bradstreet, Guidepoint, Third Bridge, IBISWorld, SS&C Intralinks, FactSet, S&P Capital IQ, and PitchBook (Anthropic finance agents, retrieved 2026-05-13). Anthropic also names Citadel, FIS, and Walleye Capital in the release, but those testimonials should be read as adoption signals, not proof that every integration passed a public security review.

Healthcare has a similar shape. Claude for Healthcare lists prior authorization review, insurance claims and appeals, and ambient scribing as administrative workflows, with integrations or partners including CMS Coverage Database, ICD-10, NPI Registry, PubMed, Elation Health, Carta Healthcare, and Commure (Claude for Healthcare, retrieved 2026-05-13). The pattern is consistent: regulated industries have valuable, repetitive workflows tied to specialized systems of record. Connectors make those systems reachable without forcing the buyer to replace them.

The Anthropic MCP partner directory reinforces the horizontal reach of the standard by listing connectors across legal, finance, cloud, productivity, and specialized data providers (Anthropic MCP partners, retrieved 2026-05-13). I am intentionally not using unverified ecosystem numbers here. The connector directory is enough to support the argument that MCP is becoming a shared integration surface; download counts and community-server totals need a more stable primary source before they belong in a G0-ready draft.

Build the tool trace before you sell the automation

For developers, the lesson is to build for traceability first. Here is a minimal Claude API tool-use pattern that represents a legal document connector. It is not a full remote MCP server; it is the application-level shape you should expect to log before attaching real iManage, NetDocuments, or Relativity calls.

```python import anthropic

client = anthropic.Anthropic()

legal_document_search = { "name": "search_legal_documents", "description": "Search scoped legal documents for a matter.", "input_schema": { "type": "object", "properties": { "matter_id": { "type": "string", "description": "Matter ID approved for this review" }, "query": { "type": "string", "description": "Search phrase for relevant clauses or filings" }, "doc_types": { "type": "array", "items": {"type": "string"}, "description": "Allowed document categories" } }, "required": ["matter_id", "query"] } }

response = client.messages.create( model="claude-opus-4-7", max_tokens=1200, tools=[legal_document_search], messages=[{ "role": "user", "content": ( "Search Matter 2024-ACME-001 for indemnification clauses " "with uncapped liability. Return the document IDs and flag " "anything that needs partner review." ) }] )

for block in response.content: if block.type == "tool_use": print("tool:", block.name) print("input:", block.input) elif block.type == "text": print(block.text) ```

Expected output shape:

``text tool: search_legal_documents input: { "matter_id": "2024-ACME-001", "query": "indemnification uncapped liability", "doc_types": ["contract"] } ``

Anthropic's current model overview lists claude-opus-4-7 as a Claude API ID and recommends Opus 4.7 for complex tasks (Anthropic model docs, retrieved 2026-05-14). The important production move is not the model name; it is persisting the request ID, user identity, matter scope, tool name, tool input, tool result IDs, and final answer in your own audit store. MCP gives you a standard integration contract. Your product still has to implement retention, access review, and rollback or escalation workflows.

Use the decision framework to avoid buying the wrong wedge

The MCP-versus-FDE decision is a workflow question, not a loyalty test.

If your legal, finance, or healthcare workflow already lives in supported systems, start with MCP-style connectors and force the product team to show the tool trace. If your workflow depends on undocumented edge cases and internal political knowledge, an FDE team may be the only way to get from demo to production. The hybrid answer is common: use connectors for the stable systems of record, then reserve custom engineering for the exceptions that create real business value.

> KnowledgeCheck: A law firm wants Claude to review DocuSign and Ironclad contract records, but the compliance team needs to inspect which search tool was called and what matter scope was passed. Which design gives the cleanest starting point? > > A) A system prompt that tells Claude to be careful > B) A connector or tool-use design with logged tool invocation inputs and scoped credentials > C) A one-off chat transcript copied into the matter file > D) A custom model fine-tune with no external tool calls > > Answer: B — the reviewable artifact is the structured tool invocation plus the app's own log of who requested it, what matter scope was used, and what downstream records were returned. A prompt alone does not create a tool trace.

Anthropic's legal MCP release is the clearest sign yet that enterprise AI adoption is shifting from "which model answered best?" to "which integration layer do we trust?" Developers who want to build in this wedge should start with connector schemas, scoped permissions, and audit storage before they add autonomous workflows. The next step is Claude Tool Use from Zero: From Basics to Production Connectors, then MCP from First Principles to Production: Why JSON-RPC over stdio beat WebSockets + OpenAPI for server transport, OAuth, and gateway-level audit logging; for retrieval patterns, read 2026-05-12-rag-with-mcp-connectors and mcp-2026-roadmap-explained.