You probably think of the Model Context Protocol as a tidier way to register functions with a language model — a slightly more formal version of the tool-calling JSON you already hand to Claude or GPT-5. However, MCP is closer to what USB-C did for peripherals than to anything that lives inside a single vendor's SDK.
It is a wire protocol and a connection model, not a feature of one model's API. That distinction is exactly what makes it load-bearing for the people who own integration sprawl in production.
MCP is an open client-server standard, introduced by Anthropic in November 2024, that lets any compliant AI model reach external tools. It turns one-off agent integrations into a reusable contract instead of bespoke glue code.
What Problem Does MCP Actually Solve?
Every agent you put into production needs to touch systems it did not ship with — Salesforce for the account, Snowflake for the warehouse, ServiceNow for the ticket, GitHub for the repo. Before MCP, each of those connections was a hand-built adapter tied to one model's tool-calling format.
That is the M×N problem in its plainest form: M models or agent frameworks multiplied by N target systems. Six agent runtimes against twelve enterprise systems is 72 bespoke integrations to write, test, and keep from rotting.
Each adapter carries its own auth handling, its own retry policy, and its own schema for what the tool returns. When the Salesforce API shifts or you swap Claude for a Bedrock-hosted model, you are back in the same twelve files.
MCP solves the M×N integration problem. Instead of wiring every model to every system by hand, you build one MCP server per system and one MCP client per agent — turning 72 integrations into 18.
Why MCP Crossed From Novelty To Default
When Anthropic open-sourced MCP in late 2024, it could have stayed a Claude-flavored convenience. Instead, it became one of the rare protocols that competitors adopted on their own roadmaps.
Through 2025, support landed across OpenAI's tooling, Google's agent stack, and Microsoft's developer surfaces, alongside IDEs like Cursor and Zed. On AWS, Bedrock agents and the Strands Agents SDK can act as MCP hosts, so you can keep orchestration inside your account while reusing the same servers.
That convergence is the whole point for an infrastructure team. A standard is only worth adopting when it is genuinely cross-vendor — otherwise you have traded one form of lock-in for another.
By 2026, the practical question has shifted from whether to use MCP to how to operate it at scale. That is a much better problem to have, and it is the one this post is about.
How MCP Works: Hosts, Clients, And Servers
MCP defines three roles, and keeping them straight is the difference between a clean rollout and a confused one. The host is your AI application, the client is the connector it spawns, and the server is the thing that actually exposes a capability.
Messages move over JSON-RPC 2.0, with two standard transports. Local servers run over stdio on the same machine, while remote servers speak Streamable HTTP — the transport that replaced the original HTTP-plus-SSE design in 2025.
The protocol exposes three primitives, and each maps to a different control surface. They include but are not limited to:
- Tools. Model-controlled functions the agent can invoke — query a database, file a ticket, send a message. These are the actions that change or fetch state.
- Resources. Application-controlled data the host can pull into context, such as a file, a record, or a log. The model reads them; it does not trigger side effects through them.
- Prompts. User-controlled templates a server offers — reusable, parameterized instructions that standardize how a capability is invoked.
The payoff of this separation is governance. Because tools, resources, and prompts are distinct, you can reason about what an agent can do versus what it can merely read — which is exactly the line auditors and security teams care about.
An MCP host is the AI app, a client is the connector it opens to one server, and a server exposes tools, resources, and prompts. Messages travel over JSON-RPC 2.0 via stdio locally or Streamable HTTP remotely.
MCP Versus Bespoke Connectors And Raw Function Calling
It helps to put the three approaches side by side, because teams often conflate them. Function calling is a model capability, bespoke connectors are your custom integration code, and MCP is the standard that lets one connector serve many models.
| Dimension | Bespoke connectors | Raw function calling | Model Context Protocol |
|---|---|---|---|
| Reuse across models | None — rebuilt per model | Vendor-specific schema | One server, any compliant client |
| Integration math | M × N | M × N | M + N |
| Auth handling | Per adapter, ad hoc | Inside app code | OAuth 2.1 on remote servers |
| Discovery | Manual documentation | Hardcoded in prompt | Self-describing tool registry |
| Maintenance surface | Highest | High | Centralized in the server |
The column that matters most to an ops budget is integration math. M+N is the only one of these that stops growing quadratically as you add models and systems.
What Steps Should An Infrastructure Team Take To Adopt MCP?
Adoption is incremental, which is the good news — you do not rebuild your agent stack to get value. Here is the sequence that keeps the rollout boring, in the way production rollouts should be boring:
- Inventory your integration surface. List every system your agents touch today and the auth model each one uses. This is your N, and it tells you which MCP servers to build or adopt first.
- Adopt before you build. Many systems already have maintained MCP servers — GitHub, Slack, Postgres, and the major SaaS platforms among them. Reuse a vetted server before writing your own.
- Wrap one system as a pilot. Pick a single high-traffic integration — usually the CRM — and stand up its MCP server in shadow mode. Validate the tool schemas against real calls before any agent depends on them.
- Pin versions and scope credentials. Treat each server like any other production dependency: model-version pinning on the agent side, narrowly scoped tokens on the server side. An over-permissioned server is the most common own-goal.
- Wire in observability from day one. Every tool call should emit a structured trace — who called it, with what arguments, and what came back. You will need this the first time an agent does something surprising.
The throughline is that MCP does not absolve you of operational discipline — it gives you one place to apply it. Centralizing a capability in a server means your retry policy, your audit trail, and your access scoping live in one reviewable surface instead of scattered across adapters.
Start by inventorying every system your agents touch, then adopt maintained MCP servers before building your own. Pilot one system — usually the CRM — in shadow mode, pin versions, scope tokens narrowly, and add tracing from day one.
Where MCP Bites You In Production
A standard removes integration toil; it does not remove failure modes. The ones that catch teams off guard cluster around trust, drift, and visibility.
The first is prompt injection through tool descriptions. Because an MCP server tells the model what its tools do in natural language, a malicious or compromised server can smuggle instructions into that description — which is why you vet and pin servers exactly as you would a dependency from a package registry.
The second is schema drift. When the underlying Salesforce or ServiceNow API changes and the server's tool schema lags, the agent keeps calling a contract that no longer matches reality — and a stale-state read becomes a wrong action.
The third is over-permissioned access. A single server holding a broad token is a tidy blast radius for anyone who compromises it, so scope credentials to the narrowest set of operations the agent actually needs.
The three production risks are prompt injection via tool descriptions, schema drift when a system's API changes, and over-permissioned server credentials. Mitigate by pinning servers, validating schemas, and scoping tokens narrowly.
How Do You Know Your MCP Layer Is Actually Working?
The honest answer is that you do not, unless you instrumented it. MCP standardizes the connection, but it does not hand you a dashboard.
This is where MCP adoption has to be paired with real agent observability and durable agent audit trails. Every tool invocation is a state-changing event, and an event you cannot replay is an incident you cannot explain.
Track the same signals you would for any distributed system: P50, P95, and P99 latency per tool, error and timeout rates per server, and a full argument-and-response trace behind a retention policy. When a server's P99 quietly triples, that is your early warning that a downstream API is degrading before the agent starts failing outright.
The teams who run this well treat each MCP server as a first-class service with an owner, an SLO, and a deprecation path. That posture is the same one we cover in our work on agent orchestration and the broader agent operating model — the protocol is the easy part; operating it is the job.
Wiring Agents Into Your Stack Without The Integration Tax
MCP is the connective tissue, but the value shows up only when it is bolted to disciplined orchestration, governance, and observability. If you are mapping how agents will reach your CRM, warehouse, and ticketing systems, the architecture decisions you make now decide whether the next ten integrations are cheap or painful.
If you are scoping your first MCP rollout — or untangling a pile of bespoke connectors you already regret — the team at iSimplifyMe builds and operates production agent systems across CRM, ticketing, and data-warehouse environments every week. Reach out for a working session: we will inventory your integration surface, name the failure modes you are about to hit, and leave you with a deployable MCP adoption plan.
For the groundwork, start with our guides on how to build an AI agent, CRM agent automation, and the full AI agent operations hub.
Frequently Asked Questions About The Model Context Protocol
No. Function calling is how a single model requests a tool within one vendor's API, while MCP is the transport-level standard that exposes those tools to any compliant client. One MCP server can serve Claude, GPT, and Bedrock-hosted agents alike.
Anthropic introduced MCP as an open specification in November 2024, and it is now developed in the open with contributions from across the industry. OpenAI, Google, and Microsoft tooling adopted it through 2025.
Yes. Bedrock-based agents and the Strands Agents SDK can act as MCP hosts, connecting to MCP servers for tools and data. That lets you keep orchestration inside your AWS account while reusing the same connectors.
The big ones are prompt injection through tool descriptions, over-permissioned credentials on the server, and weak auth on HTTP transports. Pin server versions, scope tokens narrowly, and require OAuth 2.1 on remote servers.
Usually not. You wrap each existing integration as an MCP server once, then point agents at it; the orchestration logic stays the same. Migration is incremental, system by system, not a rebuild.