Guide
What is MCP (Model Context Protocol)? A plain guide for people running AI agents
By Atlas AI Resources · Published October 27, 2026
MCP, the Model Context Protocol, is an open-source standard for connecting AI applications to outside systems: your files, a database, Gmail, GitHub, a search engine. Instead of every AI app building its own one-off integration for every service, a service is wrapped once as an MCP server, and any app that speaks MCP can plug it in. The official docs compare it to “a USB-C port for AI applications.” For anyone running agents, the practical point is simple: each MCP server you connect is a new set of things your agent can read and do, so choose them the way you’d choose who gets a key to the office.
1. How it works: host, client, server
The architecture overview names three roles:
- Host: the AI app you use, such as Claude Desktop, Visual Studio Code, or Cursor. It runs the model and manages connections.
- Client: the connector inside the host. The host creates one client per server, and each keeps its own dedicated connection.
- Server: the program that offers context and capabilities, for example a filesystem server or a Sentry server.
Under the hood, clients and servers exchange JSON-RPC 2.0 messages. You rarely need to know more than that unless you’re building a server yourself.
2. What a server offers: tools, resources, prompts
Per the server concepts page, a server can expose three kinds of things, and who controls each one matters:
- Tools: actions the model decides to call, like searching flights, sending a message, or writing to a database. These are the ones that can change things.
- Resources: read-only context the app pulls in, like a file, a schema, or a calendar.
- Prompts: reusable templates a user picks on purpose, like “plan a vacation.”
Tools are where the risk lives. The specification is blunt about it: “Tools represent arbitrary code execution and must be treated with appropriate caution.”
3. Local vs remote servers
MCP defines two standard transports:
- Local (stdio): the host launches the server as a program on your own machine and talks to it over standard input and output. It typically serves one client.
- Remote (Streamable HTTP): the server runs somewhere else and the host talks to it over HTTP. It typically serves many clients and can use bearer tokens, API keys, or headers. MCP recommends OAuth for getting tokens.
The official local server security guide makes the difference concrete. A local server is “an ordinary operating system process” that inherits your environment variables, can read anything your account can read, and can reach the network. Its advice: if a server only wraps an online service and needs none of your files or local tools, prefer the remote version.
4. What it means for a small fleet of bots
- Most connectors are MCP servers. When an agent app offers “Connect Gmail” or “Add the GitHub app,” you’re usually adding an MCP server and the tools that come with it.
- Give each bot only what its one job needs. A bot that summarizes your inbox doesn’t need GitHub. The official guide warns that every server you add shares the model’s context, so “every server you add extends the surface the others are exposed to.”
- Start read-only. The MCP docs’ security best practices recommend starting with a minimal scope limited to low-risk read operations and adding more only when a task needs them, not asking for everything up front.
- Treat tool results as untrusted input. An email, web page, or ticket a tool returns can contain instructions aimed at your agent. That’s prompt injection, and it’s why sends and deletes need a human check. More in Keeping AI agents safe from prompt injection.
Our advice: a checklist before you install a server
- Who publishes it? Prefer the service’s own official server or an app’s built-in connector. Can you tie the package to a real maintainer and a readable source repository? Check the exact package name, because lookalike names are a known trick.
- A listing isn’t a review. The official MCP Registry’s moderation policy says consumers “should assume minimal-to-no moderation,” and it won’t remove servers just for having security vulnerabilities.
- What tools does it expose? Read the tool list and descriptions before you rely on it. If a description contains instructions unrelated to the tool’s job, remove the server.
- Read or write? Note which tools only read and which can send, edit, delete, or spend. Servers can label tools as read-only or destructive, but the spec says to treat those labels as untrusted unless the server is trusted. A label is a claim, not a guarantee.
- Where do the tokens live? Give each server its own narrowly scoped token instead of one broad personal token, keep long-lived secrets out of plain-text config files, and know how to revoke access.
- Local or remote? If it runs locally, pin the version and consider a container with only the folder it needs. If it only wraps a web service, prefer the remote version.
- Prompt-injection risk: anything a tool returns, such as email bodies, web pages, issue comments, or documents, can carry instructions. Plan for it.
- Start read-only. Run the bot for a week with read scopes and draft-only output before granting anything that writes.
- Human approval for sends, deletes, and spend. The spec says there should always be a human in the loop who can deny tool calls. A confident agent is not the same as your yes.
As general architecture advice, the strongest limits live outside the model. A read-only credential or a scoped service account means a write can’t happen even if the agent is talked into trying. The protocol itself says it “cannot enforce these security principles at the protocol level.” That job falls to the app, the credentials, and you.
If you run Grok Bot
Grok Bot “supports the same MCP servers, plugins, and skills as Cursor,” per the official Grok Bot 101 guide. Apps you add under Connect apps are connected apps (MCP servers). Two details from the computer and apps docs matter for a fleet:
- Apps are account-wide. A connected app is available to every Bot you run, so “only the connectors this job needs” goes in each bot’s job description and in your approval rules. It isn’t a separate per-bot switch.
- App logins stay off the computer. OAuth tokens are held on Cursor’s connector backend, and the Bot invokes tools without receiving them.
Guardrails in Grok Bot are plain-language rules checked by a review agent, not code. The current docs put them in Settings → General → Auto-review, as Ask first and Allow automatically rules (the 101 guide calls this Settings > General > Agent, with allow and block lists). Write narrow rules such as “Ask first before sending any external email.” The docs note that Auto Review is model-based and should complement least privilege, not replace it. Their least-privilege list starts with “Connect only the tools a workflow needs.” Team admins can also allow or block connectors through the team’s connector policy (see Grok Bot security). For how one bot per job fits together, see What is a one-job Grok Bot? and small AI fleets and handoffs.
Short glossary
- MCP: Model Context Protocol, an open standard for connecting AI apps to outside data and tools. Anthropic introduced it on November 25, 2024.
- Host: the AI application that runs the model and opens connections.
- Client: the connector inside the host, one per server.
- Server: the program that exposes tools, resources, and prompts.
- Tool: an action the model can call. It can change things.
- Resource: read-only context, like a file or record.
- Prompt: a reusable template the user chooses.
- stdio: the local transport, where the server runs as a program on your machine.
- Streamable HTTP: the remote transport, where the server runs elsewhere and is reached over HTTP.
- Registry: a directory of published servers. The official one is at registry.modelcontextprotocol.io.
Useful public resources
The official starting point: what MCP is, what it enables, and the USB-C comparison.
Hosts, clients, and servers, the data and transport layers, and local vs remote examples.
Tools, resources, and prompts, and who controls each.
The formal spec, including its security and trust principles: user consent, data privacy, and tool safety.
How tools are listed and called, the human-in-the-loop warning, and security rules for servers and clients.
Practical defaults for local servers: provenance, pinning, tool-description review, containers, per-server tokens, and network limits.
Attack patterns such as confused deputy, token passthrough, and local server compromise, plus scope minimization.
The official directory of published servers, in preview. Read its moderation policy before you treat a listing as vetted.
A small set of reference servers maintained by the MCP steering group. The README says they’re educational examples, not production-ready solutions.
The November 2024 announcement that introduced MCP as an open standard.
How one host does it: mcp.json, the transports it supports, tool approval by default, admin allowlists, and security tips.
Connecting apps, account-wide availability, and where app tokens are held.
Related: Keeping AI agents safe from prompt injection · What is a one-job Grok Bot? · Small AI fleets and handoffs · Cursor Cloud Agents guide · Grok Bot templates · Complete Grok Bot setup guide · The research papers behind agentic AI · GitHub Copilot cloud agent guide