AI & LLMChecklist
MCP security checklist: what to verify before connecting a server
A practical MCP security checklist covering provenance, permissions, OAuth, tool metadata, prompt injection, isolation, validation and logging.
AI & LLMPractical guide
What is MCP? Model Context Protocol explained
Understand MCP hosts, clients, servers, tools, resources and prompts, plus what the 2026-07-28 specification changes for AI agents.
THE USEFUL ANSWER
MCP, or Model Context Protocol, defines a common way for an AI application to discover and use external capabilities. An MCP server can expose executable tools, readable resources and reusable prompts. The protocol does not replace the model, the agent or authorization; it mainly standardizes how those parts connect.
- MCP standardizes communication between an AI application and external capabilities; it does not create an agent by itself.
- Its core primitives include tools, resources and prompts, each serving a different purpose.
- The 2026-07-28 revision introduces a stateless protocol core and strengthens authorization-related behavior.
MCP connects AI to the rest of the system
A language model can generate text from its context, but it does not automatically have access to your files, APIs, databases or internal tools. MCP provides a common protocol for describing those capabilities and allowing an AI application to discover and use them under the policies enforced by the client and server.
The important word is protocol. MCP does not replace the model, the chat interface or your business logic. It defines messages, capabilities and conventions between a client and a server, so integrations can share a common language instead of inventing a different interface for every tool.
Host, client and server: who does what?
In an MCP architecture, the host is the AI application that owns the user experience, such as a development environment or assistant. That application uses an MCP client to communicate with one or more servers. A server then exposes structured capabilities backed by real services: files, databases, APIs, search systems, developer tools or internal platforms.
This separation matters because it avoids mixing decision and execution. A model may propose a tool call, while the client still has to apply policy, request approval when appropriate and show useful information to the user.
| Component | Role | Example |
|---|---|---|
| Host | Owns the application and user experience | Assistant or IDE |
| MCP client | Communicates with a server through the protocol | Connection built into the host |
| MCP server | Exposes structured capabilities | File, data or API server |
| Target service | Performs the real work or stores data | Git, SQL database, business API |
Tools, resources and prompts serve different jobs
MCP servers can publish several primitives. Tools are meant to perform an action or computation. Resources expose content that a client can read. Prompts provide reusable instruction templates. Official SDK documentation exposes these families through list and call or read operations.
Keeping those roles separate reduces ambiguity. Project documentation does not need to masquerade as a write-capable tool. Conversely, an operation that creates a ticket, edits a file or triggers a deployment should be treated as an action with controls that match its impact.
| Primitive | Main purpose | Question to ask |
|---|---|---|
| Tool | Execute an action or active computation | What can this call really change? |
| Resource | Provide context or readable data | Which data is exposed and to whom? |
| Prompt | Reuse an instruction structure | Who selects the template and inputs? |
MCP does not replace your APIs
An MCP server can call an existing REST, GraphQL or internal API behind the scenes. The API remains the business interface of the service, while MCP becomes a layer designed for AI applications. For one tightly controlled integration, a direct API can still be simpler. MCP becomes more attractive when the same set of capabilities needs to be discovered and used by several compatible clients.
MCP should not be treated as a synonym for model function calling either. Function calling usually describes how a model selects from functions made available inside a specific product. MCP covers a broader integration layer: capability discovery, client-server exchanges, resources, prompts and transport conventions.
Local or remote: transport changes the risk
A local server can run as a process and communicate through standard input and output. A remote server can use the HTTP transport defined by the ecosystem. In either case, MCP compatibility is not a security guarantee. A local process can have excessive rights on the machine; a remote service can receive sensitive data or hold over-broad permissions.
Before connecting a server, map the full data path: application, MCP server, target service and any downstream provider. This is closely related to the questions in local AI vs cloud AI: data location, maintenance, access control and responsibility.
What the 2026-07-28 specification changes
The revision released on July 28, 2026 makes a major architectural change: the modern protocol core is stateless at the protocol layer. It also introduces discovery behavior, caching hints on selected list and read results, routing headers, multi-round-trip requests and several authorization hardenings.
That means an MCP article written in 2024 or early 2025 may describe a different connection lifecycle. When implementing a client or server, check the protocol revision supported by the SDK instead of copying an old example. Official SDKs may support more than one protocol generation, which is why two valid examples can look structurally different.
A concrete example: a coding agent
Imagine a coding agent that must inspect a repository, read project documentation and then create an issue. One server can expose controlled file access, another can provide ticket operations, and the host can present those capabilities to the model. The model proposes the calls it needs, while the application decides what can execute automatically and what requires confirmation.
The goal is not to give the model every available permission. A well-designed integration narrows the scope: only the relevant repositories, only the necessary operations and explicit approval for sensitive actions. Agent quality therefore depends on its environment and safeguards as much as on the model.
When MCP is a good fit
MCP is worth considering when you want to connect multiple tools to different assistants, standardize capability discovery or keep the AI application separate from the services it uses. For an internal script that calls one stable API, adding an MCP server can create another layer without immediate benefit.
A useful decision rule is to start with the requirement: how many clients need the capability, is dynamic discovery useful, which permissions are required and what isolation level do you expect? Then choose the protocol. As with evaluating an AI tool, the architecture should be judged on a real task rather than popularity alone.
Compatibility is not authorization
An MCP server can expose powerful actions and tool descriptions that become part of the model's context. OWASP recommends controls such as least privilege, input and output validation, server isolation, source verification and human confirmation for sensitive operations.
Before installing an unfamiliar server or giving it access tokens, read our MCP security checklist. The protocol makes connection easier; it does not decide what deserves trust.
One more question?
Is MCP an API?
MCP is an integration protocol. An MCP server can sit on top of an existing API, while adding conventions aimed at AI clients and applications.
Does MCP replace function calling?
No. Function calling usually describes how a model selects functions inside a product; MCP standardizes client-server integration and also covers resources and prompts.
Should every AI integration use MCP?
No. A direct API can be lighter for one simple integration. MCP is more useful when several clients need to discover and use the same capabilities.