Start here
Model Context Protocol (MCP) in plain language
MCP standardises part of the connection between an AI application and a capability provider. It does not replace the underlying business API, decide which model to use or automatically make every server compatible with every host.
Think of a document-search service reused by several compatible applications. Each still needs appropriate configuration, authentication and permission checks. A local server can also return information to a cloud-hosted model through its host application.
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 establishes a client connection and discovers supported capabilities. Compatibility depends on the implementations and protocol features in 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 fictional staff assistant needs to find an expense-policy passage. Its MCP server exposes a read-only search capability.
- Process
- The authenticated request is restricted to policies the employee may access. The server returns a passage, document identifier and 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, negotiate capabilities and exchange protocol messages. Servers adapt their underlying systems to the protocol. Authentication, data mapping, error handling and host compatibility still require integration work; standardisation does not mean every client supports every server feature.
Local stdio and remote Streamable HTTP
The specification defines stdio and Streamable HTTP transports. With stdio, a client commonly launches and communicates with a local server process. Streamable HTTP uses HTTP for client/server communication and can use server-sent events for streaming. Older HTTP+SSE implementations require version-aware compatibility handling.
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 common protocol reduces integration differences, but does not remove deployment, version and capability differences.
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 does not make it so on its own — the security properties come from how the host, the server and the surrounding organisation are configured. Four questions decide it in practice. Where does the server run: a local server keeps a request on the machine, while a remote server sends it to another party, and local execution still does not guarantee local-only processing if the underlying service calls out. How is access established: a remote server needs proper authorisation, with tokens scoped to that server and to the acting user, never a shared credential with more reach than the task. What may the server actually do: capabilities should be enumerated and limited, with consequential actions requiring explicit human approval rather than a model’s judgement. And what comes back: content returned by a server is untrusted input, so treat instructions embedded in a document or a tool result as data rather than commands the assistant should follow — that is the prompt-injection path, and it does not require a hostile server, only a hostile document the server can read. The specification publishes security best practices covering these areas; read them alongside your own data-handling, logging and review requirements.
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.