Model Context Protocol (MCP): meaning and definition
Model Context Protocol (MCP) in plain language
MCP standardises part of the link between an AI app and a tool or data source. It does not replace the business system behind it, choose the model for you, or make every server work with every app.
Picture a document-search service used by several apps that support MCP. Each app still needs its own setup, sign-in and permission checks. A local server can also send information to a model running in the cloud, through the app that hosts it.
How it works
Where the MCP connection sits
One connection, inside a wider application
- Host + client
The AI application manages an MCP client for this connection.
- MCP server
Exposes supported capabilities through the protocol.
- Data or service
The underlying documents, database or business API.
Requests travel towards the service; results return through the server and client to the host.
Connect and discover
The host app connects to the server and finds out what it can do. Whether they work together depends on how each is built and which protocol features they use.
Request an allowed capability
The application uses an available tool, resource or prompt through the connection. Treat server content as external input rather than trusted instructions.
Use the returned context
The host decides how the result is presented or supplied to the model. The protocol does not define the application’s whole reasoning workflow.
Illustrative example · Fictional data
Connecting a policy-search service
- Input
- A made-up staff assistant needs to find a passage in the expense policy. Its MCP server offers a read-only search.
- Process
- The request is signed in and limited to the policies this employee is allowed to see. The server sends back a passage, the document’s ID and its revision label.
- Expected output
- The assistant summarises the passage and links to the permitted source. It cannot approve an expense simply because it can search the policy.
- How to check it
- Use two test identities with different access. Confirm restricted passages do not reach the wrong user or appear in their model context.
Where it helps
- Sharing an internal search capability across compatible AI applications.
- Connecting development tools to permitted repository or ticket information.
- Providing a consistent integration boundary while keeping business logic in the existing service.
MCP versus APIs and tool calling
- Business API
- Implements the underlying operation, such as searching an order system.
- MCP
- Defines a protocol boundary through which an AI application accesses supported capabilities.
- Tool calling
- Lets a model request an operation. That operation may be connected through MCP or a direct integration.
Tools, resources and prompts: concrete examples
A tool could look up an order using a validated identifier. A resource could expose an approved policy document or schema. A prompt could supply a reusable investigation template. These are distinct capabilities: a host may support or present them differently, and discovery does not grant permission to execute an action.
The host contains clients that connect to servers, agree what each side can do and exchange messages. Servers make their own systems available through the protocol. Sign-in, mapping data, handling errors and making it work with the host still take integration work; a standard does not mean every client supports every server feature.
Local stdio and remote Streamable HTTP
The specification defines two ways to connect: stdio and Streamable HTTP. With stdio, a client usually starts a local server and talks to it directly. Streamable HTTP uses ordinary web requests between client and server, and can stream updates. Older HTTP plus SSE versions need care to stay compatible.
Local execution is not the same as local-only data. A local server can contact remote services, and the host may send returned context to a hosted model. Trace the whole data path, use least-privilege credentials, validate inputs and apply approval rules for consequential actions. Treat tool output as untrusted data, not instructions that override the user.
Related reading and learning pathways
Common pitfalls
- Installing a server does not establish who may access its data.
- Local execution does not guarantee local-only data processing.
- A shared protocol makes connections more alike, but differences in setup, versions and features remain.
Put the idea to work
Try it yourself
Draw the host, client, server and underlying data store for a read-only integration. Label where credentials live and where returned data could leave the organisation.
Common questions
Is MCP only for one model provider?
No. MCP is an open protocol. A host must implement the required client behaviour; model choice is a separate application decision. Several assistant and developer tools act as MCP hosts, and one MCP server can be reused by any host that implements the protocol, which reduces custom integration work.
Is MCP safe to use with sensitive enterprise data?
It can be, but the protocol alone does not make it safe. Safety comes from how the host, the server and your organisation set it up. Four questions decide it. Where does the server run? A local server keeps a request on your machine, while a remote server sends it to someone else; and a local server can still call out to an online service. How is access granted? A remote server needs proper sign-in, with tokens limited to that server and that user, never a shared login that can reach more than the task needs. What can the server do? List its capabilities, keep them narrow, and make a person approve any action that matters, rather than leaving it to the model. And what comes back? Treat anything a server returns as untrusted. Instructions hidden in a document or tool result are data, not commands to follow. That is how prompt injection works, and it needs only a harmful document the server can read, not a harmful server. The specification publishes security best practices on these points; read them alongside your own rules on data, logging and review.
Does MCP replace an API?
Usually not. A server can wrap an existing API and expose selected capabilities to compatible hosts. The API still does the underlying work. MCP adds a standard way for an AI application to discover the server’s tools, resources and prompts and call them consistently.
Are all MCP servers safe to install?
No. Review the publisher, code or service, requested access and data flow. Protocol compatibility is not a security endorsement. Prefer servers from known publishers, grant the narrowest permissions that work, keep secrets out of shared configuration and review what data each tool can read or send.
Your next step
Continue learning
Connected concepts
Sources and further reading
Examples on this page are teaching exercises using fictional information. They are not client case studies or measured outcomes.