MCP explained: how Model Context Protocol connects AI to systems
MCP is an open standard that lets AI apps call tools and read data from your systems through one protocol, so long as you control permissions and inputs.
Short answer: The Model Context Protocol (MCP) is an open standard that lets an AI application discover and use tools and data from other systems through one common interface, instead of a custom integration for each. An MCP server wraps a system (a database, a file store, a ticketing tool) and exposes its tools, resources and prompts; the AI app connects through an MCP client and calls them. It saves integration work, but it also gives AI a direct path into your systems, so permissions, approvals and input handling matter more, not less.
What problem does MCP solve?
Language models are only as useful as the information and actions they can reach. Before MCP, every AI application had to write its own connector for every system: one for the CRM, one for the file share, one for the ticket queue. Ten apps and ten systems meant up to a hundred integrations.
Anthropic introduced MCP in November 2024 as "an open standard that enables developers to build secure, two-way connections" between data sources and AI tools. The announcement described the problem plainly: "Every new data source requires its own custom implementation." MCP's goal is to replace those one-off connectors "with a single protocol".
The idea is similar to a common plug. Build a system's MCP server once, and any AI app that speaks MCP can use it.
How does MCP work?
MCP has three participants. The names are easy to mix up, so here they are in plain terms:
| Part | What it is | Example |
|---|---|---|
| Host | The AI application the user works in | A chat assistant, an IDE, an internal agent |
| Client | A connector inside the host, one per server | The host's link to the "tickets" server |
| Server | A program that wraps a system and offers its capabilities | A server in front of your ticketing API |
The official architecture guide says the host creates one MCP client for each MCP server, and each client keeps a dedicated connection to its server. A host can connect to many servers at once.
Messages use JSON-RPC 2.0, a simple, widely used request and response format. There are two standard ways to carry them:
- stdio: the server runs as a local program on the same machine and talks through standard input and output. Good for local tools.
- Streamable HTTP: the server runs remotely and talks over HTTP. Good for shared services. The spec recommends OAuth for getting access tokens.
What are MCP tools, resources and prompts?
An MCP server can offer three kinds of things. The spec calls them primitives.
- Tools are actions the model can call: run a query, create a ticket, send a message. Each tool has a name, a description and a JSON Schema for its inputs. The spec describes tools as "model-controlled", meaning the model decides when to call them.
- Resources are data the AI app can read for context: file contents, database records, a schema.
- Prompts are reusable templates, such as a standard way to ask for a weekly summary.
The architecture guide gives a helpful example: a database server could expose tools for querying, a resource containing the database schema, and a prompt with worked examples of good queries.
Clients find out what a server offers by asking. A tools/list request returns the available tools, and tools/call runs one. Servers can also notify clients when their tool list changes, so the AI app always sees what is currently available.
The client side has its own feature. With elicitation, a server can ask the user for more information or for confirmation of an action mid-task.
What does a typical MCP request look like?
Here is the flow when a user asks an assistant to "log a ticket for the broken printer on floor 3":
- The host has already connected to a tickets server and listed its tools, including
create_ticket. - The model reads the request and the tool's description and decides to call
create_ticketwith a title, location and priority. - The host shows the user what is about to happen (good hosts do this; more on why below).
- The client sends a
tools/callrequest to the server. - The server validates the inputs, checks the caller's rights and calls the real ticketing API.
- The result, such as a ticket number, goes back to the model, which replies to the user.
If something goes wrong, the spec separates two kinds of error. Protocol errors mean the request itself was malformed. Tool execution errors, such as "date must be in the future", are returned to the model so it can correct itself and try again.
Is MCP still changing?
Yes. The specification is versioned by date and has been revised several times since launch. The current architecture guide describes revision 2026-07-28, which makes each request carry its own version and capability information so servers do not depend on connection state, and deprecates the older "sampling" feature that let servers ask the client's model for completions.
In practice: pin the protocol versions your clients and servers support, read the changelog before upgrading, and test servers against the version your hosts actually speak.
How is MCP different from an API or function calling?
These three are often confused because they work together.
| What it is | Who defines it | |
|---|---|---|
| API | The interface a system already has, such as a REST endpoint | The system's owner |
| Function calling | A model's ability to request a named function with structured arguments | Each AI app, for its own functions |
| MCP | A shared protocol for discovering and calling tools and data across apps | An open specification |
An MCP server usually calls an existing API underneath. The model still uses function calling to choose a tool. MCP standardises the part in between, so a tool built once can be found and used by any compatible app.
What are the security risks of MCP?
MCP makes it easy to give an AI system real reach into your data and tools. That is the point, and also the risk. The protocol defines how messages move; it does not decide what a server should be allowed to do. The main risks are below.
| Risk | What happens | Main defence |
|---|---|---|
| Prompt injection | Text in a document, web page or tool result tells the model to do something else | Treat external content as untrusted; limit what tools can do; approval for risky actions |
| Over-broad permissions | A server or token can do far more than the task needs | Least privilege, narrow scopes, checks in the target system |
| Untrusted servers | A third-party server misdescribes its tools or runs harmful code locally | Only install reviewed servers; sandbox local ones |
| Token misuse | A server accepts or forwards tokens not meant for it | Validate token audience; never pass tokens through |
| Silent actions | Tools run without the user seeing them | Show tool calls and inputs; confirm sensitive operations |
Prompt injection
OWASP ranks prompt injection first in its 2025 Top 10 for LLM applications. Indirect prompt injection is the version that matters most for MCP: the model reads content from an outside source, such as an email or a web page returned by a tool, and hidden instructions in that content change what it does.
OWASP notes that prompt injection may not be fully preventable. Its recommended mitigations include least privilege, clearly separating untrusted content, validating outputs in code, and human approval for high-risk actions. The goal is to limit the damage a fooled model can do.
Over-broad permissions
The MCP security guidance warns against wildcard or "full access" scopes. A stolen broad token gives an attacker everything at once, and a single catch-all scope makes audit logs less useful. It recommends starting with a minimal scope for low-risk reads and asking for more only when a privileged action is first attempted.
This matches what OWASP calls Excessive Agency: tools that can do more than needed, access beyond what the task requires, and high-impact actions without an independent check.
Untrusted servers and tool descriptions
A tool's description goes straight into the model's context, so a malicious server can use it to steer the model. The spec says clients must treat tool annotations as untrusted unless they come from trusted servers.
Local servers carry an extra risk because they run code on the user's machine. The security guidance says clients offering one-click setup must show the exact command before running it and get explicit approval, and recommends sandboxing local servers with minimal privileges.
Tokens and sessions
The security guidance explicitly forbids "token passthrough", where a server accepts a token that was not issued for it and forwards it to another API. It also says servers must not use sessions for authentication and must verify every inbound request.
What does the spec say about human approval?
The tools section is direct: "there SHOULD always be a human in the loop with the ability to deny tool invocations." It recommends that applications:
- show clearly which tools are exposed to the model;
- show clear indicators when tools are called;
- present confirmation prompts for operations.
It also asks servers to validate all tool inputs, enforce access controls, rate-limit tool calls and sanitise outputs, and asks clients to show tool inputs before calling, apply timeouts and log tool usage for audit.
When should you use MCP?
MCP earns its place when integration work repeats. Good fits:
- Many AI apps, same systems. Several teams want their assistants to reach the same knowledge base or ticket system.
- One app, many systems. An assistant that needs tools from different teams or vendors benefits from one way of discovering and calling them.
- Tools that change. Discovery and change notifications mean the app sees new tools without a redeploy.
It is less useful when:
- you have a single internal agent with two or three tools that rarely change, where direct function calls are simpler;
- the action is high-risk and you want a fixed workflow with no model-chosen tool calls at all;
- you cannot yet review, host and monitor the servers you would be connecting to.
A practical rollout:
- Start with read-only servers over low-sensitivity data.
- Give each server its own narrowly scoped credentials, never a shared admin key.
- Turn on confirmation for every write action.
- Log every tool call with the user, inputs and result.
- Add write tools one at a time, after reviewing real traces.
How CloudOEngine helps
CloudOEngine is one platform and one console for connecting data (databases, files and camera streams), running pipelines, and running AI, including an AI runtime with an LLM gateway, agents with tool access, and RAG. The questions MCP raises about permissions, approvals and audit are the ones CloudOEngine is built around.
Agents run real tools, such as filing a ticket, under one permission model and one audit trail. Every step and tool call is traced and inspectable, so you can see what the model chose, with which inputs, and what came back.
Autopilot runs triggered agents with approval rules: a person approves an action in the app or through an email approve link before it runs. That gives you the human-in-the-loop control the MCP specification recommends, applied to your own tools.
Governance is included, not upsold: tenant isolation, role-based access, audit logs and per-tenant encrypted secrets, so tool credentials stay scoped to the tenant that owns them.
CloudOEngine is built in Bengaluru, India.
Book a demo or see the AI runtime.
Frequently asked questions
What is the Model Context Protocol (MCP)?
MCP is an open standard, introduced by Anthropic in November 2024, for connecting AI applications to external tools and data. An MCP server exposes tools, resources and prompts, and any MCP-capable AI app can use them without a custom integration.
What is the difference between an MCP client and an MCP server?
The MCP host is the AI application. It creates one MCP client per connection, and each client talks to one MCP server. The server is the program that wraps a system, such as a database or ticketing tool, and offers its capabilities to the AI.
Is MCP secure?
MCP defines how messages flow, and its specification includes security guidance, but safety depends on how servers and clients are built and configured. The main risks are prompt injection, over-broad permissions, untrusted servers and weak token handling.
Does MCP replace APIs?
No. An MCP server usually sits in front of an existing API or database and translates it into tools and resources an AI app can discover. The underlying API still does the work and should still enforce its own access rules.
When should I use MCP instead of a direct integration?
Use MCP when several AI apps need the same tools, or one app needs many tools from different teams or vendors. A single, tightly controlled internal agent with two or three tools may be simpler with direct function calls.