Every few months a protocol shows up and gets described as the USB of something. MCP earned the comparison more than most, but the analogy stops exactly where the interesting engineering starts. Here is what the Model Context Protocol takes off your plate, and what it very deliberately does not.
The Integration Problem Before MCP
Before MCP, every AI tool integration was bespoke. You wanted a model to query your database, so you wrote code for that model, that database, and that application. Then you wanted a second model to do the same thing and you wrote it again. Same database, same operation, different implementation, and both of them rotted independently.
MCP replaces that with a client-server protocol built on JSON-RPC 2.0. You build one server that exposes a capability, and any MCP compatible client can discover and invoke it without integration code written for that specific pairing. Discovery, invocation and result formatting work the same regardless of which model is on the other end.
Hosts, Clients And Servers
The three roles are worth getting straight, because most confusion in discussions comes from mixing them up. The host is the application the user is actually in. The client lives inside the host and holds one connection. The server is the process exposing capabilities, and it can be a local binary talking over stdio or a remote service over HTTP.
That separation is why one host can hold many servers at once with no combinatorial glue: a filesystem server, a GitHub server, an internal one you wrote this afternoon. The host is responsible for what gets connected and what the user sees, and the servers stay ignorant of each other.
Tools, Resources And Prompts
There are three primitives and they answer three different questions. Tools are functions the model can call, and they are the ones with side effects. Resources are data the application can read into context, closer to a file than to a function. Prompts are templates the user invokes deliberately, which matters because it puts a human in the loop by design rather than by convention.
Most implementations reach for tools and ignore the other two, then end up rebuilding resource loading badly inside a tool call. If your server is mostly returning documents, that is a resource, and treating it as one keeps the model's decision surface smaller.
Where The Security Burden Sits
This is the part the spec hands back to you. A tool description is text, and that text reaches the model as instruction. The moment a third party supplies the server, its descriptions are untrusted input that can shape your agent's behaviour before any call happens. Version drift makes it worse: pull latest and a renamed or expanded tool changes what your agent does with no change in your code.
Practical answers are unglamorous. Pin third party servers to versions you have reviewed. Keep destructive operations behind your own confirmation layer instead of the model's judgement. Log the tool calls with their arguments so an incident is reconstructable. None of this is in the protocol because none of it can be, it is a property of your deployment.
The Takeaway
MCP standardizes the wire format, the handshake and the shape of a capability. It does not decide what your agent is allowed to do, and it never will. If you want the longer version, covering architecture, transports, capability negotiation and the full security model, I keep a complete guide at autolearningagents.com.
Treat the protocol as solved and spend your effort on the trust boundary, which is where the actual failures happen.
Top comments (0)