Architecture: Host, Client, and Server
The Host is the AI application you use. Inside it, a Client communicates with a particular Server, which exposes tools or data. The application may use a model locally or remotely. MCP defines how these parts exchange messages, not how the model thinks.
MCP Host
The AI application itself. This is the program the user interacts with, like an IDE extension or a chat interface. It orchestrates the AI model, which might run locally on your device or remotely in the cloud.
The host coordinates connections. It doesn't connect to servers directly; instead, it creates a dedicated MCP Client for each server it wants to talk to.
Connection is not intelligence: MCP does not train a model or guarantee correct answers. A server may wrap an existing API, read files, or call another model; the protocol does not replace those underlying systems.
Primitives: What can a Server provide?
MCP Servers offer three core "primitives" to the AI application. By combining these, an AI can understand its environment, format its requests correctly, and take action.
Resources
Data sources that provide contextual information to the AI application.
Think of them like files on a filesystem or records in a database. They are read-only from the AI's perspective. The AI can list available resources and read their contents to gain context before answering a question.
The Protocol Exchange
Under the hood, MCP uses JSON-RPC 2.0: structured messages sent back and forth. Compare these abbreviated examples to see how discovering a tool differs from calling it. They are teaching examples, not complete requests you can run.
Permissions & Untrusted Data
Because tools can execute local code or modify databases, security requires a layered approach across both the Server and the Host.
Permissions & Risks
MCP Servers can execute code or access data. The Host (the AI application) should apply safeguards such as asking for approval before a sensitive action. Servers must also enforce their own authentication and access limits.
Tools are not guaranteed to be safe. Even returning plain text from a resource carries risk: untrusted text from the web or an external file could contain prompt injection attempts. The AI must be instructed to treat retrieved data as untrusted so it does not override its core instructions.
Tool Execution Requested
The AI model wants to use the execute_sql tool on your local database.
Knowledge Check
What is an MCP Server's role?
If an AI model generates a request to format your hard drive using a tool, what stops it?
How does the AI application know what an MCP tool does?
Frequently Asked Questions
Why not just build custom API integrations?
Without a standard, every AI application (Claude, VS Code, Cursor, etc.) has to write custom code to support every tool (GitHub, Postgres, Slack). MCP allows a tool developer to write a reusable integration that any MCP-compatible AI host can use, provided it supports the required capabilities, authentication, and configuration.
Is MCP only for local tools?
No. While many developers use STDIO transports to connect local file systems to desktop AI apps, MCP supports HTTP/SSE transports for connecting to remote cloud services (like a Sentry or GitHub MCP Server).
Does the MCP Server know what the user asked?
Not inherently. The Server just receives specific primitive requests (e.g., 'read this file', 'call this tool with these arguments'). The AI model used by the Host processes the user's natural language and decides which requests to send to the Server.
Can an MCP Server trigger the AI to do something?
MCP primarily relies on the Client asking the Server for things. However, servers can send Notifications (e.g., 'my tool list changed') to prompt the client to refresh its state. Servers can also use the Elicitation primitive to ask the client to prompt the user for input.