What Is MCP (Model Context Protocol)?
The plug standard for connecting AI to everything else
What MCP actually is, how it differs from ordinary tool use, when it is the right way to connect an agent to a system, and the authentication and security details that catch people out on their first integration.
What is the Model Context Protocol?
MCP is an open standard for connecting AI models to external tools and data sources. Rather than every application writing bespoke integration code for every service, a service publishes an MCP server once and any MCP-capable client can use it. Think of it as a plug standard: its value comes from the same connector working across different applications instead of being rebuilt inside each one. Under the hood, an MCP-provided capability still reaches the model as an ordinary tool call.
Key Facts:
- An open standard, not a Claude-only feature
- A service publishes one server; many clients can use it
- MCP capabilities still surface to the model as tool calls
- Credentials live outside the agent, injected after the request leaves it
- Hosted servers usually want OAuth tokens, not the service's native API key
The Problem It Solves
Before a standard existed, every AI application that wanted to reach a given system wrote its own integration. Your product wrote a connector for a ticketing system. So did every competitor. So did every internal tool. The same integration work happened over and over, none of it reusable, all of it needing separate maintenance as the underlying API changed.
MCP inverts that. The service, or someone in its ecosystem, publishes one server that speaks the protocol. Any client that speaks MCP can then use it without knowing anything specific about that service. The integration work happens once, on the side that actually understands the system.
This is unglamorous plumbing, and it is worth being clear-eyed that plumbing standards succeed or fail on adoption rather than elegance. The relevant question for a given project is not whether MCP is well-designed but whether a good server exists for the system you need.
What it does not do
MCP does not make an agent smarter, safer, or cheaper. It does not remove the need to think about which actions an agent should be able to take. It does not validate that the server on the other end is trustworthy or well-built. It standardizes how a capability is described and invoked, and that is the whole of it.
Teams occasionally reach for MCP expecting it to solve an agent design problem. It solves an integration distribution problem. Those are different, and conflating them leads to disappointment.
MCP Server or Your Own Tool?
Both end up as tool calls. The question is who owns the integration and who else needs it.
| MCP server | Your own tool | |
|---|---|---|
| Who writes the integration | Whoever publishes the server, often the service or its community | You |
| Reusable elsewhere | Yes, by any MCP-capable client | No, it lives in your codebase |
| Schema control | The server decides what it exposes | Complete, you define it |
| Approval and gating | Configured on the client side, per server or per tool | Whatever you build, at any granularity |
| Best for | Common third-party systems, or capabilities several of your apps need | Actions specific to your product, or anything needing a bespoke approval path |
| Main risk | You inherit the server's design decisions and its security posture | You own the maintenance, forever |
A common and sensible pattern is both: MCP for the third-party systems your agent touches, and your own tools for the actions that are specific to your business and need tight control.
The Details That Catch People Out
Consistently the first four things to go wrong on a new MCP integration.
OAuth tokens, not API keys
Hosted MCP servers generally expect OAuth bearer tokens. A service's native integration token authenticates against its REST API and will not necessarily work against its MCP server. These are separate auth systems that happen to belong to the same company.
Credentials belong outside the agent
Do not put keys in the system prompt or in a message. Those persist in session history and are readable for the life of the conversation. The correct pattern stores credentials separately and injects them into the outbound request after it leaves the agent's environment.
Network policy silently breaks it
If the agent runs in a restricted-egress environment, it must be able to reach the MCP server's domain. When it cannot, tools fail in ways that look like model confusion rather than connectivity, and people debug the wrong layer for hours.
Tool results are untrusted input
Content coming back from a third-party server can attempt prompt injection. Treat it with the same suspicion as anything a user typed, and do not let it silently escalate what the agent is willing to do.
How Credentials Should Actually Flow
The design worth understanding, because it generalizes beyond MCP, is that the credential never enters the environment where the agent runs.
In Anthropic's Managed Agents the agent definition declares its MCP servers by name and URL with no authentication attached. Credentials live in a separate vault, and a vault is attached to a session rather than baked into the reusable agent config. When the agent calls an MCP tool, the request is routed through a proxy that fetches the credential and adds it to the outbound call after it has left the sandbox.
The security property this buys is worth stating explicitly: code running inside the agent environment, including code the agent itself writes, cannot read the credential. That holds even if the agent is successfully prompt-injected, because there is nothing in its reach to steal. Contrast this with putting a key in the system prompt, where a single well-crafted injection exfiltrates it.
The same pattern without MCP
If you need an agent to call something that is not an MCP server and you cannot use a managed credential store, the equivalent pattern is to keep the call on your side entirely. Declare a custom tool, and when the agent invokes it, your own orchestrator executes the authenticated call with its own credentials and returns the result. The agent gets the answer; the secret never leaves your infrastructure.
If your design has an API key sitting somewhere the agent can read, that is the design to change first, before anything else about the integration.
MCP, FAQ
Common questions about the Model Context Protocol.
Connecting an agent to your systems?
We build production Claude agents, including the integration and credential design that keeps them safe to run. Bring us the systems and we will tell you how we would wire them.
Related Services
Explore our other technical consulting services
Tell us what you're building.
Bring us the problem you're solving. We'll tell you how we'd build it, what it takes, and how Simple Engineers can help your business scale its technology.
Get in Touch
hello@simpleengineers.com
We typically respond within 2-4 hours
Phone
+1 (888) 966-0773
Mon-Fri 9AM-6PM EST
Location
Global Remote Team
Serving clients worldwide
Response Time
Within 24 hours
Emergency support available
Why Partner with Simple Engineers?
- Senior engineers who build and ship, not just advise
- We stay on to run and grow what we build
- You own everything: your code, your cloud, your keys
- Scaling companies from startup to enterprise since 2016
Send Us a Message
Tell us about your project or goals and we'll get back to you within one business day.