What is the Model Context Protocol, and when should it be used?

The **Model Context Protocol (MCP)** is an open client-server protocol for connecting AI applications to external tools and context through a standard interface.\n\nAn MCP server can expose:\n\n- **tools** that an AI application may invoke;\n- **resources** that provide data or context;\n- **prompts** that provide reusable interaction templates.\n\nUse MCP when an integration should be reusable across multiple compatible AI hosts, when tools need to be discovered dynamically, or when a provider-neutral interface is more valuable than a custom model-specific adapter.\n\nDo not use MCP merely because it is fashionable. A direct API integration can be simpler and safer for one narrow, stable use case. MCP also does not by itself provide complete execution governance, trust, or protection against prompt injection and malicious tools.

MCP separates the AI application from the systems that provide data and actions.\n\nThe main participants are:\n\n- the **host**, such as an AI IDE or desktop assistant;\n- an **MCP client** created by the host for each connection;\n- an **MCP server** that exposes capabilities.\n\nThe protocol uses JSON-RPC 2.0 at its data layer. It defines lifecycle management, protocol-version negotiation, capability discovery, requests, responses, and notifications. Local servers commonly use standard input and output, while remote servers commonly use Streamable HTTP.\n\nThe three principal server primitives are:\n\n1. **Tools** — executable operations such as reading a database, creating a ticket, querying an API, or modifying a file.\n2. **Resources** — contextual data such as documents, schemas, records, or API responses.\n3. **Prompts** — reusable templates or examples that help structure a model interaction.\n\nMCP is valuable when:\n\n- the same tool should work with several AI clients or models;\n- capabilities need to be listed and discovered at runtime;\n- an organisation wants a consistent integration contract;\n- a local process and a remote service should expose similar semantics;\n- a tool provider wants to avoid building a separate adapter for every host;\n- prompts, resources, and actions belong in one negotiated interface.\n\nA direct API or function-call integration may be better when:\n\n- there is only one client and one stable service;\n- the operation is simple and performance-critical;\n- the security boundary requires a narrowly audited interface;\n- dynamic discovery adds no value;\n- the existing API contract already provides the necessary governance.\n\nMCP standardises communication, not trust. A tool description can be misleading or malicious. A connected server can expose more capability than expected. Remote authorisation must bind tokens to the intended resource, minimise scopes, avoid token passthrough, and use secure OAuth flows. Hosts should present tool identity and arguments clearly, constrain permissions, and require approval for consequential actions.\n\nThe correct adoption question is therefore: **Does a standard, reusable tool-and-context interface provide enough integration value to justify the additional protocol and security surface?**

- [Model Context Protocol — Architecture overview](https://modelcontextprotocol.io/docs/learn/architecture) — defines MCP's scope, hosts, clients, servers, data and transport layers, and tools, resources, and prompts. - [Model Context Protocol — Authorization specification](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) — defines OAuth-based remote authorisation, audience binding, scope handling, token validation, and the prohibition on token passthrough. - [Model Context Protocol — Security best practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices) — documents security risks including session hijacking, prompt injection, and confused-deputy failures. - [Breaking the Protocol: Security Analysis of MCP](https://arxiv.org/abs/2601.17549) — provides independent research on protocol-level trust and prompt-injection risks in tool-integrated agents.