Quick answer: The Model Context Protocol (MCP) is an open, client-server protocol that standardizes how an AI application connects to external tools and data sources. Instead of building a separate custom integration for every tool, an app talks to lightweight MCP servers over one common interface, and each server exposes a set of tools, resources, and prompts the model can use. It defines the connection and the message format, not the model itself.
The problem it solves
Without a shared protocol, every AI application needs its own connector for every data source and service it wants to reach. As the number of apps and services grows, the number of one-off integrations multiplies, and each one handles auth, error handling, and data shapes differently. MCP collapses that into a single client-server contract. A server written once can be used by any compatible host, and a host can support many servers without learning each vendor's private API. The common analogy is a universal port: one connector shape on both sides.
The roles
The architecture has three parts that are easy to conflate. The host is the application the user runs and in which the model lives. Inside the host, a client manages the connection to a single server, with one client per server. The server is a separate, small program that exposes capabilities and runs outside the model, often as a local process.
| Role | What it is | Responsibility |
|---|---|---|
| Host | The AI application | Runs the model, holds context, enforces consent |
| Client | Connector inside the host | One per server, manages the session |
| Server | External program | Exposes tools, resources, prompts |
The three primitives
A server can offer three kinds of capability. Tools are functions the model can invoke, such as running a query or creating a record; they may have side effects, so a host normally asks for user approval before one runs. Resources are readable data, like a file or a database row, that the model or user can pull into context. Prompts are reusable templates and slash commands that shape how a task is started. Tools are actions the model takes, resources are data it reads, and prompts are authored starting points.
How they talk
Messages use JSON-RPC 2.0, with requests, responses, and notifications flowing in both directions. When a session starts, the client and server exchange capabilities so each side knows what the other supports. Two transports are common: stdio, where the host launches a local server as a subprocess and communicates over standard input and output, and a remote HTTP transport for servers reached over a network. The same primitives work over either transport; only the carrying mechanism changes. If you want to see what a tool call actually does before wiring it into an agent, you can exercise the underlying HTTP request in a local workspace; Powerduck keeps that request and its response visible rather than hiding behavior behind a tool name.
Security and consent
MCP does not grant a server automatic trust. The host stays in control of which tools run and can require confirmation for actions with side effects, and the model cannot reach a resource the user has not authorized. Remote servers use standard authorization such as OAuth, and the principle is least privilege: a server gets access to only what it needs. Connecting a server does not make its output correct, and a malicious or poorly written server is still a risk the host and user must evaluate.
Honest limits
The protocol standardizes the connection, not the quality or safety of what sits behind it. It does not validate that a tool behaves correctly, that returned data is accurate, or that a server handles errors well, and it does not solve naming collisions, versioning, or rate limits across many servers on its own. Those remain engineering and operational choices. MCP is also not a model and does not run inference, and importing or connecting a server does not deploy a backend. Treat it as a well-defined transport for context and actions, with the real guarantees coming from how each server is built and reviewed.
Frequently asked questions
Is MCP an AI model? No. It is a protocol that connects an AI application to external tools and data; the model stays inside the host.
What is the difference between a tool and a resource? A tool performs an action and may have side effects; a resource is data that is read into context.
Does an MCP server run locally or remotely? It can do either. Local servers commonly use stdio, while remote servers use an HTTP transport.
Does connecting a server make it safe? No. The host still controls consent and authorization, and the server's behavior and security need separate review.
The bottom line
MCP gives AI applications one standard client-server interface for reaching tools, resources, and prompts over JSON-RPC, replacing a sprawl of custom connectors, while leaving trust, consent, and data quality to the host and the server authors. For more on building and operating these servers, see the MCP server guide hub.
