Model Context Protocol
An open standard for connecting models to tools and data — solving a real integration problem, and a standards fight is a political event, not a technical one.
When not to use it
- For one integration. A protocol is overhead until you have several.
- As a security boundary. It standardises connection, not permission. Your authorisation lives in your code.
- When connecting untrusted data to a capable model. The protocol makes this easy, which is not the same as safe.
- When the ecosystem doesn't have what you need. Then it's a spec you're implementing alone.
Reach for something else instead
- Direct function calling — for a handful of tools you own, this is simpler.
- Provider-specific tool APIs — less portable, fewer moving parts.
- A plain HTTP API — if only your app calls it, the protocol buys you nothing.
Sources & further reading
- Anthropic (2024), Model Context Protocol specification — the primary source; read the spec rather than the coverage.
- Greshake et al. (2023), Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection — why every connected data source is an injection surface.
- Microsoft (2016), Language Server Protocol — the precedent; the same M×N problem, solved the same way.
Primary sources, listed so you can check the claims on this page rather than take them on trust.
Where people go wrong
- Treating the protocol as a permission system. It isn't one and doesn't claim to be.
- Connecting a server that reads external content to a model with write capabilities, without thinking about injection.
- Installing servers from an ecosystem with the trust assumptions you'd apply to a signed release. It's a package ecosystem.
- Assuming standardisation implies safety. It implies convenience, on both sides.