Before MCP, connecting an agent to Jira, a database, or a document store meant bespoke integrations per model and per tool—brittle, unaudited, and expensive to maintain. The Model Context Protocol (MCP) is an open standard that defines how reasoning engines discover tools (executable functions), resources (read-only data), and prompts (reusable instruction templates) through standardized servers. Anthropic open-sourced MCP in late 2024; by 2026 major providers and IDEs support it—making MCP a practical integration layer for enterprise agents, not only experimental chat plugins.
This pillar explains MCP for operations and engineering leaders: what it standardizes, when it beats direct API scripts, where token overhead matters, and how to pair MCP with data boundaries, audit trails, and agent workflow design. It is not a directory of community servers—a checklist for adoption lives in the MCP Server Selection Worksheet.
MCP primitives
| Primitive | What it exposes | Enterprise example |
|---|---|---|
| Tools | Callable functions with schema | Create ticket, run approved query, post draft to staging |
| Resources | Read-only structured data | Policy pack snapshot, KB article by ID, CRM field bundle |
| Prompts | Reusable templates | Approved task framing loaded from registry |
MCP decouples the reasoning engine from the execution layer. Security administrators can enforce OAuth 2.0, scoped tokens, read/write separation, and audit logging on servers—without trusting the model to invent safe API calls.
Compare to ad hoc scripts: MCP gives you a consistent discovery and permission model across Claude, Copilot, Gemini, and internal gateways—reducing the "integration tax" when teams pilot multiple models.
When MCP helps—and when CLI is enough
MCP shines when agents need governed, multi-tenant, authenticated access to systems of record—especially where OAuth, compliance logging, and permission boundaries matter.
Direct command-line or lightweight API calls can be more token-efficient for developer agents that grep a repo and run local tests—some MCP operations consume tens of thousands of context tokens per call where CLI equivalents use hundreds. The tradeoff is not "MCP bad"—it is match integration style to task risk and audit requirements.
| Scenario | Prefer MCP | Prefer direct API/CLI |
|---|---|---|
| Enterprise CRM / ticket write with OAuth | ✓ | |
| Local repo search in dev sandbox | ✓ | |
| Cross-tenant SaaS with scoped tokens | ✓ | |
| One-off script in controlled CI | ✓ | |
| Audit must prove tool name + args | ✓ |
Northline piloted MCP for read-only KB and ticket thread fetch in support-reply-v3 while keeping send actions in existing CRM integration—not because MCP was trendy, but because OAuth scopes and audit fields mapped cleanly to their governance RACI.
Security architecture
Enterprise MCP adoption fails when security is bolted on after connectors go live. The protocol exposes tools and resources to reasoning engines that cannot be trusted to self-limit—so authentication, authorization, logging, and output sanitization belong on the server and gateway layers before any pilot touches customer data. Northline B2B treated MCP servers like microservices with their own threat model: each server got an owner, a data-class label, and a review gate tied to their existing governance RACI. That framing kept engineering velocity without turning "open standard" into "open perimeter."
Governance-as-code at the MCP layer includes:
Authentication — OAuth 2.0 or API keys on servers; no long-lived secrets in prompt text.
Allowlists — explicit tool names per workflow ID; deny by default.
Read/write separation — distinct scopes; read-only MCP for retrieval-heavy steps.
Audit logging — tool name, arguments hash, response metadata, actor, timestamp.
Sanitization — treat all tool returns as untrusted input; strip instructions that attempt to override system policy.
Prompt injection via tool returns
Malicious content in emails, web pages, or ticket bodies can instruct the model to call write tools or exfiltrate data. Defenses:
- Never pass raw tool output directly to write tools without a checker step.
- Structured parsing — extract fields; drop free-text directives.
- Human send gate on customer-facing actions in v1.
- Eval cases with injection strings in held-out set.
Pair with Securing MCP and Agent Tools for allowlist worksheets and incident runbooks, and data boundaries for agents for enforcement patterns—this pillar defines the architecture.
MCP vs bespoke integrations
The build-vs-standardize decision is not ideological. Bespoke scripts win when a team needs a narrow, low-audit integration with minimal token overhead—grep a repo, run a test suite, post to an internal webhook. MCP wins when multiple agents, models, or business units must share governed access to the same systems of record with consistent OAuth scopes and uniform audit fields. Northline compared both paths for ticket retrieval: a direct CRM API wrapper cost less to prototype, but MCP's resource primitive gave Legal a cleaner story for read-only scopes and centralized logging across three pilot workflows.
| Dimension | Bespoke per tool | MCP standardized |
|---|---|---|
| Setup per model | High | Lower once server exists |
| OAuth / multi-tenant | Reinvent each time | Server-native patterns |
| Audit consistency | Varies | Uniform tool call logs |
| Token overhead | Often lower for simple calls | Can be higher—budget accordingly |
| Vendor lock-in | Per SDK | Model-agnostic servers |
Enterprises adopt MCP when integration count and compliance burden exceed the overhead cost—not for a single spreadsheet query.
Wiring MCP into agent workflows
Follow How to Design an AI Agent Workflow before enabling tools:
- Define outcome and error tolerance — not tool list first.
- Allow/deny matrix — map MCP tools to workflow ID.
- Eval set — include tool-misuse and injection cases.
- Human escalation — when tool returns low confidence or policy conflict.
- Registry link — prompt templates that invoke MCP prompts use prompt registry IDs.
Log fields minimum: mcp_server_id, tool_name, workflow_id, prompt_version, policy_pack_version.
Token and cost discipline
MCP does not eliminate context cost—it can amplify it when agents preload tool schemas, fetch large resource bundles, or chain parallel calls without budgets. Finance and engineering should review MCP workflows the same way they review model spend: cost per completed task, not cost per API invocation. Northline's support-reply-v3 pilot tracked MCP resource fetches separately from model tokens and found that just-in-time retrieval cut average run cost by roughly one-third compared to an earlier design that embedded full KB excerpts in the prompt. Token discipline is a design choice, not a platform default.
Context engineers should:
- Fetch just-in-time via resources—not preload entire corpora into prompt.
- Cache static tool schemas outside hot path where platform allows.
- Cap parallel tool calls per run.
- Measure cost per successful task, not per call—CLEAR-style framing in P2 eval playbook.
Context architecture applies: MCP does not remove the need to design layers; it standardizes how layers reach systems of record.
Rollout pattern (Northline sketch)
Phased MCP rollout beats "enable everything" because each new tool surface expands injection and exfiltration risk. Northline B2B sequenced MCP the same way they sequenced agent autonomy: prove read paths, add staging writes, and only then consider customer-facing actions—each phase gated by eval smoke and a risk-forum vote. Process owners stayed accountable for outcomes; IT owned server scopes and log schema. That split prevented the common pattern where engineering ships connectors and operations discovers missing audit fields under incident pressure.
Phase A — read-only: KB resource server + ticket thread resource; no write tools.
Phase B — staging write: Draft reply to staging field only; human send unchanged.
Phase C — expanded tools: Only after eval pass and forum vote; new server scopes per workflow.
Each phase re-ran eval checklist smoke before promotion.
Anti-patterns
These patterns recur in enterprise MCP pilots because connectivity feels like progress. They are how useful agents become incident generators—broad tool catalogs, missing allowlists, and injection tests deferred because "our data is internal." Northline's risk lead blocked two community servers that lacked maintainer accountability and scoped OAuth; that delay frustrated a demo-minded sponsor but avoided a production dependency on unaudited code. Treat anti-patterns as release blockers, not post-mortem footnotes.
- Enabling every community MCP server "for flexibility."
- No allowlist per workflow—agents inherit tools from desktop config.
- Logging final text only, not tool calls.
- Skipping injection eval because "our data is internal."
- Replacing data boundaries matrix with hope.
Where to go next
Design bounded tasks in agent workflow guide. Enforce boundaries in data boundaries for agents. Log completely per audit trails. For framework selection when MCP orchestrates multi-step graphs, see LangGraph vs CrewAI for Production. For procurement of automation platforms that host MCP, see Choosing Workflow Automation for AI Pipelines.