BLOG
Model Context Protocol, or MCP, is an open protocol for an AI application to discover and use capabilities exposed by programs called servers. A server can offer actions, data, and reusable interaction templates. A shared protocol can reduce the need to build a unique connector for every application-service pair. It does not make every tool compatible, safe, or authorized automatically.
Editorial note: this is a conceptual guide based on the current MCP architecture and July 28, 2026 specification. No server was installed or tested for this article. Confirm the protocol and SDK version supported by a particular host before implementation.
Host, client, and server have different roles
The host is the AI application a person uses, such as an editor, desktop assistant, or automation platform. It creates an MCP client for a server. The client is the component that speaks the protocol and maintains that connection. The server is the program that offers context or capabilities. The official architecture guide describes one client per server connection.
“Server” does not necessarily mean another computer. A local process can communicate over standard input and output, known as stdio. A remote service can use Streamable HTTP. A host connected to a calendar server and a CRM server maintains separate connections, but the exact isolation of conversation data still depends on the host and its configuration. Do not assume the protocol alone keeps every source separate.
MCP has a data layer and a transport layer. The data layer defines JSON-RPC communication, version and capability discovery, tools, resources, prompts, and notifications. The transport layer defines how messages travel and how transport-specific authorization works. Two products can both say “MCP” yet require compatible protocol versions, transports, and authentication to connect.
Tools, resources, and prompts are not interchangeable
| Primitive | What it offers | Main control |
|---|---|---|
| Tool | An executable action such as finding an order or creating a draft | Arguments, permission, side effects |
| Resource | Data supplied as context, such as a file or schema | Scope and access to sensitive content |
| Prompt | A reusable interaction template | Origin, instructions, and review |
A client may discover available tools and their argument schemas. A tool can read or write. A call that publishes, sends, deletes, or pays deserves explicit policy and, when appropriate, a human decision. The protocol gives the call a common shape; it does not decide whether a user intended the side effect.
Resources expose information for a host to present to a person or model. Reading a resource may not change the source system, but its contents can still be confidential. Limit which resources can be requested and who may access them. Prompts help structure a task; they are not proof of quality, security, or authorization. Text returned by a server should remain lower trust than the user’s actual instruction.
The July 28, 2026 revision deprecated Roots, Sampling, and Logging for new implementations while retaining compatibility during a transition. Older tutorials may describe a different lifecycle. Match documentation to the version negotiated by the client and server rather than combining examples from different releases.
Example: an assistant reads opportunities from a CRM
Suppose a team asks, “Which opportunities have no contact scheduled today?” The host receives the question. Its MCP client discovers a CRM server tool such as list opportunities with a defined filter schema. The model proposes a read call with date and status. The server checks authorization, queries only permitted records, and returns structured data. The host summarizes the result with references that a person can inspect.
“Send a message to every lead” is a different operation. It can disclose data and initiate external communications. A controlled design separates search from send, caps the number of recipients, previews the exact content, and requires the right approval. Host policy, user authorization, token scopes, and server checks determine whether the action may happen.
The example does not imply that an MCP server can freely see every CRM field or the entire chat. Those boundaries must be implemented and verified. A tool description can be wrong or incomplete, and the server can return an error or unexpected content. Surface those conditions to the user.
How n8n fits into the picture
n8n documents its MCP Client node for using tools exposed by a compatible server. Check the node version, credential type, transport, and workflow design in the installed n8n. A client connection is not proof that every workflow automatically becomes an MCP server, nor that every n8n plan has identical capabilities.
MCP is also not a model, a complete agent, a business API, or a finished automation. The answer still depends on the model, available data, instructions, tool design, permissions, and verification in the host. Sometimes a direct API integration is simpler and easier to audit than introducing an MCP server.
Security risks belong in the integration design
An MCP tool may change a system, expose personal information, or call a paid service. Give it the least privilege needed: read-only where possible, narrow scopes, allowed actions, and separate credentials for test and production. Do not put tokens in prompts, logs, or repository files. Verify how a local process receives its environment variables and what it can read from the user’s machine.
Tool and resource outputs are untrusted input. A CRM note, document, or web page could contain malicious instructions that try to redirect the model. A host should keep external content distinct from system instructions, limit exposure, and require approval for consequential effects.
The MCP security guide describes risks including confused-deputy behavior, token passthrough, server-side request forgery, state-handle hijacking, and overbroad scopes. For HTTP integrations, implement authentication and authorization for the intended audience; do not reuse a downstream token without validating its recipient and permissions. For local stdio, verify the executable, command arguments, and inherited privileges.
Record the server, version, maintainer, exposed tools, scopes, and owner. Review the tool list after updates; a new version may add a write action. Use fictional data in staging, log calls without unnecessary personal content, set timeouts and limits, and keep a path to revoke credentials.
A community server is not trustworthy merely because it supports MCP. Inspect its repository, dependencies, configuration, network access, and filesystem access before running it. A local process may inherit the user’s privileges; a remote server may receive the data the client sends.
When to adopt MCP and how to test it
MCP is useful when a supported host needs a consistent way to discover capabilities across several services. Compare that benefit with the cost of server maintenance, credentials, and observability. If a direct integration already meets the need with less complexity, there is no obligation to introduce MCP.
Start with one read-only tool and fictional records. Verify version, transport, authentication, tool name, input schema, error handling, and logs. Confirm what happens when the server is unavailable or returns unexpected text. Then test one write action in a sandbox with a preview, explicit approval, and a rollback method.
Judge the result, not the label: Did the query return the correct record? Were only necessary parameters sent? Can repeated calls duplicate side effects? Which user authorized it? Can an operator investigate and revoke access? Those answers matter more than a successful connection screen.
For customer data, billing, or other sensitive work, involve the responsible security and legal people under company policy. Minimize fields and retention. Do not share personal data with a server merely because the host can connect to it.
Common questions
Is MCP an API?
It is a protocol for discovery and communication between AI hosts, clients, and servers. An MCP server may call business APIs behind the scenes, but MCP defines another interaction layer.
Do I need a particular language model?
No. The host must implement MCP and connect to a compatible server. The protocol does not prescribe which model powers the application.
Can an MCP server perform actions?
Yes. Tools can execute operations. The host and server should enforce authorization, least privilege, and approval where the action has external effects.
Is an MCP connection secure by default?
No. Security depends on the host, server, transport, credentials, scopes, and review. Use the specification’s controls and test the implementation.
Connect only what the workflow needs
MCP standardizes a way to expose tools and context, but it does not grant permission or guarantee quality. Use it when the host and services benefit from that common interface. Begin with a narrow read-only pilot, verify the data path, and add write actions only with explicit controls.
