Model Context Protocol: The Standard for Enterprise Agent Integrations

What MCP is, the client-host-server model, tools vs resources vs prompts, why enterprises adopt MCP over custom integrations, and how security boundaries work at the protocol level.

Most production AI systems cobble together tool integrations one by one: a custom function to call the CRM, another to query the database, another to write to Slack. Each integration is bespoke, untested against others, and impossible to reuse. MCP — the Model Context Protocol — exists to fix this.

MCP is an open protocol that standardizes how LLM applications connect to external tools, data sources, and context providers. Think of it as USB-C for AI integrations: one standard port, many devices.

The Architecture

MCP follows a client-host-server model with three distinct roles:

• Host: the LLM application itself (Claude, a custom agent, a chatbot). The host decides which MCP servers to connect to and manages the connection lifecycle. Client: a connector embedded in the host that speaks the MCP protocol. One host can have multiple clients — one per server. Server: an external process that exposes tools, resources, or prompts to any compliant client. Servers are reusable across hosts.

The key insight: servers are decoupled from hosts. A Salesforce MCP server built once can be used by any MCP-compliant agent, not just yours.

Three Primitives: Tools, Resources, Prompts

MCP servers expose three types of capabilities:

• Tools: callable functions with side effects. The LLM can invoke them with structured arguments. Examples: send_email(), update_record(), run_query(). Tools change state in the world. Resources: data and context that the LLM can read. Examples: a customer's account history, a document, a database view. Resources are read-only. Prompts: reusable prompt templates provided by the server. They encode domain knowledge about how to use the server's tools effectively.

Why MCP Instead of Custom Integrations?

The question you will get in a senior interview: 'Why would an enterprise agent platform adopt MCP instead of building its own tool integration layer?'

• Standardization: any MCP server works with any MCP host. No glue code, no translation layers. Reusability: a compliance team builds an audit-log MCP server once. Every agent in the enterprise can use it without re-implementation. Security boundaries: MCP defines where context flows and who can invoke what. Easier to audit than custom integrations where context flows are implicit. Governance: because MCP servers have explicit schemas and permission models, you can enforce least-privilege at the protocol level, not the application level. Ecosystem: open standard means third-party MCP servers (GitHub, Slack, databases) you can drop in rather than build.

Security Boundaries in MCP

MCP's security model is explicit about what crosses boundaries:

• Tool invocation requires explicit approval from the host. The server cannot call back into the host without the host initiating. Context isolation: each client-server session has its own context. A server cannot read context from another server. Permission scoping: tools declare their required permissions in the schema. The host can enforce these before connecting. Audit trail: every tool call and resource access is logged at the protocol level, giving you an audit trail without custom instrumentation.

# Minimal MCP server (Python SDK)
from mcp import Server, Tool

server = Server('crm-server')

@server.tool()
def get_customer(customer_id: str) -> dict:
    '''Read customer record — read-only, no side effects'''
    return crm.fetch(customer_id)

@server.tool()
def update_customer_status(customer_id: str, status: str) -> bool:
    '''Update customer status — WRITE operation, requires approval gate'''
    audit_log.record(customer_id, status, caller=server.context.session_id)
    return crm.update(customer_id, {'status': status})

MCP in Enterprise Context

Enterprise agent platforms (Teradata, Salesforce Einstein, Microsoft Copilot) are converging on MCP because IT governance demands it. When an agent can touch CRM, ERP, databases, and email simultaneously, you need a standardized way to audit, revoke, and govern those connections — not a tangle of custom integration code.

The practical implication: if you are building an enterprise AI agent system in 2025–2026 and you are not thinking about protocol-level tool governance, you are going to be retrofitting it later at significant cost.