What Is MCP (Model Context Protocol)? How Agents Connect to Tools

Every agent eventually needs something it does not have: a file on your disk, a row in a database, the current state of a ticket queue, a search result from the live web. Before MCP, each connection between an AI application and an outside system was custom work. The application builder wrote one integration for one tool, the tool builder guessed at one application's interface, and the same database got connected ten different ways by ten different teams. MCP, the Model Context Protocol, is the attempt to replace that tangle with one standard connection, defined once, that any compliant application and any compliant server can use.

This guide explains what MCP actually is, in the terms its own specification uses: the three participants, the three things a server can offer, the two ways messages travel, and the configuration file you will actually touch when you connect a server yourself. It ends with the part most introductions skip: how to judge an MCP server before you install it, because connecting a server means giving a program access to your tools and data, and the standard does not make that decision safe for you. Every protocol claim below was checked against the official documentation at modelcontextprotocol.io, last updated 2026-10-13, on the day this guide was published.

What MCP is, in one paragraph

MCP is an open-source standard for connecting AI applications to external systems. The official documentation makes the comparison itself: think of MCP like a USB-C port for AI applications. Just as USB-C gives electronic devices one standardized way to connect, MCP gives an AI application one standardized way to reach data sources such as local files and databases, tools such as search engines and calculators, and workflows such as specialized prompts. The project is more than a document: it includes the specification itself, software development kits for different programming languages, development tools including an inspector for testing servers, and reference implementations of servers that show the pattern working.

Two consequences follow from it being a standard rather than a product. First, support is spread across the ecosystem rather than owned by one vendor: the documentation lists AI assistants such as Claude and ChatGPT and development tools such as Visual Studio Code and Cursor among the clients that support MCP, alongside many others. Second, a server written once can be offered to every compliant client. That second point is the economic heart of the protocol: the integration work happens once, on the server side, instead of once per application.

The three participants: host, client, server

MCP follows a client-server architecture, and its vocabulary is precise about who does what. The host is the AI application you actually use, for example Claude Code, Claude Desktop, or Visual Studio Code. Inside the host, a client component maintains the connection to one server. The server is the program that provides context: it might run on your own machine or on a remote platform, and the protocol does not care which, because server names the role, not the location.

• One host, many connections: the host creates a separate client for each server it connects to, and each client keeps its own dedicated connection with its server.
• Local servers usually serve one client: a server running on your machine over the stdio transport typically talks to the single client that launched it.
• Remote servers serve many clients: a hosted server reached over HTTP typically serves many hosts at once, the way a website serves many browsers.
• The documentation's own example: when Visual Studio Code connects to the Sentry MCP server, the editor instantiates a client object for that connection, and connecting to a second server, such as the local filesystem server, creates a second client object alongside it.

This split explains a confusion newcomers often hit: installing a server does not add a feature to one specific chatbot. It publishes capabilities in the standard format, and any host you use can connect to it, subject to that host's own support and configuration. When something fails, the three-part model also tells you where to look first: the host's configuration, the client's connection, or the server itself. The companion guide on diagnosing tool-call failures works through that layer-by-layer method in detail.

What a server can offer: tools, resources, prompts

The data layer of the protocol is built on JSON-RPC 2.0, the same request and response pattern underneath many developer tools, and it defines three core primitives that servers can expose. These three words are worth learning exactly, because every MCP conversation, listing, and configuration refers back to them.

• Tools: executable functions the AI application can invoke to perform actions, such as file operations, API calls, and database queries. Tools are the primitive that changes the outside world, so they carry the risk.
• Resources: data sources that provide contextual information, such as file contents, database records, and API responses. Resources are read-side context the model can draw on.
• Prompts: reusable templates that structure interactions with the model, such as a system prompt or a set of few-shot examples, offered by the server for the client to use.

Each primitive has methods for discovery and use. A client can list what a server offers, for example with tools/list, retrieve items, and execute tools through tools/call. Listings are dynamic: a server whose available tools change can notify connected clients, so the menu an agent sees can stay current instead of being frozen at connection time. A single server can mix primitives freely. The documentation gives a database server as the example: tools for querying the database, a resource carrying the database schema, and a prompt holding few-shot examples for interacting with those tools. Context and capability arrive together, which is most of why the pattern works better than handing a model a bare API key and a prayer.

How the messages travel: stdio and Streamable HTTP

Under the data layer sits a transport layer that moves the same JSON-RPC messages between client and server and handles connection setup and authorization. MCP defines two transports, and which one a server uses decides where it runs and how you connect to it.

• Stdio: the client launches the server as a local process and they exchange messages over the process's standard input and output streams. No network is involved, which makes this the natural fit for servers that touch your own machine: your files, your local repositories, your development tools.
• Streamable HTTP: the server runs remotely and the client sends messages by HTTP POST, with optional streaming for long responses. This is the fit for hosted services, and it supports standard HTTP authentication, including bearer tokens, API keys, and custom headers; the protocol recommends OAuth for obtaining tokens.

The practical difference shows up in configuration. A stdio server is described by a command to run, its arguments, and any environment variables it needs. A remote server is described by a URL and, usually, a credential. When you browse this site's MCP server directory, each profile records which shape its server takes, in its setup and configuration fields, because the two shapes fail differently, cost differently, and deserve different levels of trust.

Connecting your first server, step by step

Most desktop hosts read the same configuration shape: a JSON object with an mcpServers key, where each entry names a server and says how to start it or where to reach it. The example below is the filesystem server, the reference server that exposes file operations limited to directories you allow. It is the configuration recorded on this site's Filesystem MCP server profile, with the directory left as a placeholder for your own path.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/dir"]
    }
  }
}

• Pick one narrow server first. A server scoped to a single directory, a single repository, or a single read-only service teaches you the pattern with a small blast radius if you misconfigure it.
• Read the server's tool list before you enable it. The profile and the documentation name what it can do; if a note-taking server asks for shell access, stop and ask why.
• Put the entry in your host's configuration file, with placeholders replaced by your real paths, and keep real keys out of any file you share or commit. Servers that need credentials take them as environment variables named in their documentation, never as values pasted into shared examples.
• Restart or reload the host, then confirm the connection from inside it: the host should list the server and its tools, which is the discovery step working. If the list is empty, the failure is almost always the command, a path, or a missing runtime, in that order.
• Make one small, reversible call, such as listing a directory you chose, and read what the host reports back before you let the agent use the server inside real work.

Notice what the filesystem example teaches about the protocol's safety shape: the server refuses to start with open access. Allowed directories come from the command-line arguments you supply, and if no directory is available the server fails during initialization instead of starting wide open. Well-built servers behave this way. A server that starts happily with unrestricted access to everything is telling you something about its authors' priorities.

MCP is not the agent, and not the only way to connect one

MCP standardizes the connection between an application and its tools. It does not supply the agent's reasoning, its loop, its memory, or its judgment about when to call a tool; those belong to the host application and the framework it is built with, which is why the guides on agent harness engineering and agent memory sit next to this one. A useful mental model: the framework is the kitchen, the model is the cook, and MCP is the standard electrical outlet that lets any compliant appliance plug in. Standard outlets did not make anyone a better cook; they made appliances interchangeable, which turned out to matter enormously.

Native integrations still have their place. When one application needs one tool with unusual depth, a direct integration built by the two vendors can expose behavior a general standard has not caught up with, and a single built-in connector inside a product you already use may be less machinery than running a server yourself. The honest rule: reach for MCP when you want the same capability available across applications, or when a maintained server already exists for the system you need. Build or buy the bespoke connection when the job is one application, one tool, and deep. What MCP removes is the middle case that used to dominate: writing the same shallow integration again for every new AI application your team adopts.

The safety model: a server is a program with your permissions

Connecting a server is not like bookmarking a website. A stdio server runs as a process on your machine, with your user's permissions, and its tools can act in the world: read files, run queries, call APIs with your keys. A remote server receives whatever context and credentials your host sends it. The protocol's transport layer supports authentication and recommends OAuth for remote servers, but no transport feature can decide for you whether a particular server deserves the access it requests. That judgment is the operator's job, and this site's guides on agent tool permissions and agent security risks cover the general discipline.

• Scope follows the server's own limits first: prefer servers that accept an allowed directory, a named repository, or a read-only mode, and give them the narrowest scope that still does the job.
• Treat the tool list as the permission slip. Every tool on it is something the model may invoke; a server with forty tools where you need two is thirty-eight tools of unnecessary exposure.
• Keep credentials in environment variables, scoped to the one service, and rotate them like any other key. A key pasted into a shared configuration file is a key you have published.
• Read-side before write-side. Start a new server in whatever read-only posture it offers, watch what the agent actually calls over a few real tasks, then widen deliberately.
• Remember the human gate sits outside the protocol. For irreversible actions reached through any server, the approval belongs in your workflow, as the reversibility guide describes, not in a hope that the model will ask first.

How to judge an MCP server before you install it

The ecosystem is large and uneven, so a short vetting pass pays for itself. The profiles in this site's MCP directory are built to answer exactly these questions from recorded fields, which is the honest way to use this section: check each candidate against the same list, and let a server with no answers lose to one with documented ones.

• Who publishes it, and is the source public? A server from the system's own vendor, or from the official reference set, starts ahead of an anonymous package with the same tool list.
• Is it maintained? Recorded health signals, such as recent commits and a live repository, separate living servers from abandoned ones that still install fine and fail later.
• What exactly does it expose? The recorded tool names and descriptions, not the marketing summary, are what the model will see and what you are approving.
• What does it require from you? The environment variable names on the profile tell you which credentials it wants. Wanting a broad account token for a narrow job is a finding, not a detail.
• Which transport, and what scope controls? Stdio with an allowed-path argument and remote with OAuth are the strong shapes; a server with no scope controls at all has made its choice, and you should make yours accordingly.

None of this requires deep protocol knowledge, which is rather the point. MCP's contribution is that the questions became standard too: every server can be asked who publishes it, what it exposes, what it needs, and how it connects, in the same vocabulary. Learn the vocabulary once, using the three primitives and the two transports above, and the directory pages, the configuration files, and the failure messages across every host you use will all start reading like the same language, because they are.

Sources and further reading

• Model Context Protocol documentation, What is the Model Context Protocol (modelcontextprotocol.io/docs/getting-started/intro), read for this guide on 2026-10-17: the open-source standard definition, the USB-C comparison, the ecosystem support list, and the project scope.
• Model Context Protocol documentation, Architecture overview (modelcontextprotocol.io/docs/learn/architecture), read for this guide on 2026-10-17: host, client, and server roles; the JSON-RPC 2.0 data layer; the tools, resources, and prompts primitives with their list and call methods; and the stdio and Streamable HTTP transports with their authentication guidance.
• AgentsUse, MCP server directory (this site): recorded profiles for each server named here, including the Filesystem server configuration used in the worked example, with publisher, tools, required environment variables, transport, and health fields checked on the dates the profiles show.
• AgentsUse, Diagnosing Tool-Call Failures (this site): the layer-by-layer method for when a connected server's tools fail inside a run.