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 agents discover tools (executable functions), resources (read-only data), and prompts (reusable instruction templates) through standardized servers. Anthropic introduced MCP in late 2024 and donated it in December 2025 to the Agentic AI Foundation under the Linux Foundation. By 2026 major providers and IDEs support it—a common integration contract for enterprise agents, not only experimental chat plugins.
This pillar explains MCP for operations and engineering leaders: what it standardizes, when a direct API still wins, where catalog size drives context cost, 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 terms: Glossary.
The 2026-07-28 specification made remote MCP a stateless HTTP request/response protocol: no initialize handshake, optional discovery, routing headers a gateway can enforce without parsing JSON, and cache hints on list results. This page stays at operator altitude. Transport details belong with platform engineering; security runbooks live in Securing MCP and Agent Tools.
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 model from the execution layer. Security administrators can enforce OAuth 2.0 or OIDC, scoped tokens, read/write separation, and audit logging on servers and gateways—without trusting the model to invent safe API calls. The protocol does not enforce authorization policy, data boundaries, or approvals. Those sit around the connection.
Compare to ad hoc scripts: MCP gives a common integration contract across Claude, Copilot, Gemini, and internal gateways—reducing the integration tax when teams pilot multiple models. Host consent, approval UX, and capability support are not identical. Do not treat “we speak MCP” as a shared permission model.
When MCP helps—and when a direct API is enough
MCP shines when several agents or hosts need governed, multi-tenant, authenticated access to the same systems of record—especially where OAuth, compliance logging, and permission boundaries matter. A direct API still wins when one controlled application owns both sides of a narrow integration, or when latency and tenancy isolation already live in a certified gateway.
Local CLI remains a valid developer shortcut—grep a repo, run tests in a sandbox. It is not the enterprise alternative to MCP. The tradeoff is match integration style to task risk and audit requirements, not “MCP is secure; CLI is simple.”
| Scenario | Prefer MCP | Prefer direct API / CLI |
|---|---|---|
| Enterprise CRM / ticket write with OAuth | ✓ | |
| Local repo search in a dev sandbox | ✓ (CLI) | |
| Cross-tenant SaaS with scoped tokens | ✓ | |
| One controlled app, one certified API | ✓ (API) | |
| Audit must prove tool name + args | ✓ |
Northline B2B (composite) piloted MCP for read-only KB and ticket-thread fetch in support-reply-v3 while keeping send actions on the 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 models that cannot be trusted to self-limit. Identity, authorization, logging, and untrusted-content handling belong on the server and gateway before any pilot touches customer data. Northline 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 velocity without turning “open standard” into “open perimeter.”
Controls around the connection include:
Authentication — OAuth 2.0 / OIDC as the remote baseline. API keys only for limited legacy or internal servers. No long-lived secrets in prompt text. Tokens issued for Server A must not authorize Server B; do not pass an incoming MCP token through to a downstream API.
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.
Untrusted content — tool descriptions, schemas, and returns are data from another trust domain. Prefer structured outputs and schema checks. Returned text must never change authorization policy. readOnlyHint and similar annotations are hints, not guarantees.
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:
- Untrusted tool output must not expand permissions or authorize a side effect. High-risk actions pass deterministic policy checks and, where required, explicit approval. An extra model can help detect; it is not the gate.
- Structured parsing — extract fields; drop free-text directives.
- Human send gate on customer-facing actions in v1.
- Eval cases with injection strings in a 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. A bespoke API wins when a team needs a narrow, low-audit integration—or when a certified gateway already injects tenant and dual-control. MCP wins when multiple agents, models, or business units must share access to the same systems of record under one allowlist and uniform audit fields. Northline compared both paths for ticket retrieval: a direct CRM 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 a 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 | Catalog size can dominate—budget it |
| 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. For the regulated decision procedure—MCP, custom API, or hybrid, with owners and evidence—see MCP vs Custom Tool APIs for Regulated Teams.
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. Full field lists live in audit trails for AI workflows.
Token and cost discipline
MCP does not eliminate context cost. The main problem is rarely the protocol envelope. It is catalog size: a server that exposes dozens or hundreds of tools charges context before the real task starts and can worsen tool selection. Finance and engineering should review MCP workflows the same way they review model spend: cost per completed task, not cost per invocation. Token discipline is a design choice, not a platform default.
Context engineers should:
- Keep task-specific catalogs—do not mount the desktop tool list.
- Fetch just-in-time via resources—not preload entire corpora into the prompt.
- Honor MCP cache hints (
ttlMs,cacheScope) on list and resource results instead of rediscovering unchanged catalogs every run. - Cap parallel tool calls per run.
- Measure cost per successful task, not per call—CLEAR-style framing in the 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 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.
- Treating output stripping or a second LLM as the authorization gate.
Where to go next
Design bounded tasks in agent workflow guide. Choose the connector surface in MCP vs custom tool APIs. 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.
