MCP (Model Context Protocol) is an open standard that lets an AI model or agent connect to outside tools and data, like a database, a CRM, or an internal API, through one shared protocol instead of a custom integration per tool. You build the connection once as an MCP server, and any MCP-compatible client can use it.
That's the whole idea. The rest of this post is what it means when you're the one building the agent.
The problem it fixes
Say you're building an agent that has to check an inventory database, read a Slack channel, and look up support tickets.
Before MCP, that's three hand-written integrations. Three auth flows. Three response shapes to normalize into something the model can use. Three things that break on their own schedule when an upstream API changes.
Now do that for every tool a real business runs. The AI part stops being the hard part. The plumbing is.
How MCP splits the work
MCP has two sides:
- MCP server — wraps a tool or data source and exposes what it can do (tools to call, resources to read) in a standard shape.
- MCP client — lives inside the AI app or agent, discovers what a server offers, and calls it.
The model never needs to know whether a tool talks to Postgres or a SaaS API. It sees a list of tools with descriptions and input schemas, picks one, and the client makes the call.
The analogy I use with clients is USB. USB didn't make printers smarter. It made plugging them in a solved problem. MCP does that for AI-to-tool connections.
Adoption is the reason it matters now. Anthropic, OpenAI, Google and the Linux Foundation have all backed the standard, and there are thousands of public MCP servers. If a tool you need already has one, wiring it in is a config job, not a sprint.
MCP is not the agent
This trips people up. MCP is the connector. The agent is the thing with a goal that decides what to do next.
You can have an agent with no MCP at all: two tools, hand-wired with plain function calling. You can also run MCP servers that nothing agentic ever touches. They show up together in 2026 because MCP is the cheapest way to give an agent wide reach. They're still different layers.
MCP is not RAG either
- RAG is about answering accurately from your own documents. Retrieve the relevant chunks, put them in the prompt.
- MCP is about reaching live systems and acting on them. Query a table, call an API, update a record.
They stack fine. An agent can treat a RAG-backed knowledge base as one MCP tool and use three other MCP tools for everything else.
The security part you can't skip
An agent is only as trustworthy as the servers it's connected to.
A malicious or careless MCP server can hide instructions in its own tool descriptions or metadata. If your agent auto-approves tool calls, those instructions can push it into doing something you never meant it to do. It's prompt injection, arriving through the tool list instead of the user.
What I do on client builds:
- Don't auto-approve tool calls from servers you didn't write or haven't read.
- Give each server the narrowest access that works. Read-only where reads are enough.
- Keep a human approval step on anything that writes, pays, sends, or deletes.
- Review what's connected the same way you'd review any third-party dependency.
None of this is new. MCP just made connecting things so easy that it's also easy to connect something you shouldn't.
Where I've used the pattern
On an ERP I built for an industrial distributor, staff ask an internal AI assistant stock questions and it answers from the live database, read-only, instead of guessing or pulling a stale report. Same principle: a narrow, scoped connection to real data, with writes kept behind human approval. Write-up here: AI ERP platform case study.
TL;DR
- MCP = one standard protocol for AI-to-tool connections.
- Server wraps the tool, client lives in the agent.
- It's the connector, not the agent, and not RAG.
- Treat third-party MCP servers like untrusted dependencies. No blind auto-approve.
Originally published on faisalkhandev.com, with a less technical version for business owners.
Top comments (1)
For the inventory example, the authorization question belongs to each request, even when the server is read-only. Two staff members may have different warehouse or customer scopes, and a shared server credential can otherwise make every answer look equally authorized.
I would include a tenant-scope failure in the first integration test: a valid tool name and schema, but an identity that cannot access the requested record. The server should return an explicit access result rather than leaking existence or substituting an unrestricted query. MCP standardizes the connection; preserving the application's identity and data boundaries still needs deliberate implementation.