What Is an MCP Server? A Complete Explanation

An MCP server is a program that makes a specific capability available to an AI agent using the Model Context Protocol, an open standard Anthropic published in late 2024 and since adopted across the major model providers.

Concretely, an MCP server wraps something an agent cannot do on its own. A GitHub MCP server lets an agent open pull requests. A Postgres MCP server lets it run queries. A Slack MCP server lets it read and post messages. Without the server, the model can only produce text about GitHub. With it, the model can act on GitHub.

The word "server" causes most of the confusion here, so it is worth settling immediately. An MCP server is a role in a protocol conversation, not a machine in a rack. It is closer to a plugin or a driver than to a web server. Most of them are a single command that an AI application launches as a background process on the same computer.

MCP defines three participants, and keeping them separate makes the rest of the protocol easy to read.

The host is the AI application the person is using: Claude Code, an IDE, a desktop assistant, an internal agent platform. The host holds the model and decides what the agent is allowed to do.

The client is a connector the host creates. The host opens one client per server, and each client maintains a single dedicated session. Five connected servers means five clients inside one host.

The server exposes capabilities. Everything the agent gains from MCP arrives through a server.

Servers offer three kinds of capability, and the distinction matters because each one is controlled by a different party:

• Tools are functions the model itself decides to call. create_issue, run_query, send_message. These are model-controlled, which is the source of both the usefulness and the risk.
• Resources are data the application pulls in as context, such as a file, a record, or a document. These are application-controlled.
• Prompts are templates a user deliberately invokes, usually surfaced as a slash command or menu item. These are user-controlled.

Clients can offer capabilities back to the server as well. A server can ask the host's model to generate a completion on its behalf, ask the user a question mid-task, or request the filesystem boundaries it is allowed to operate within.

Messages travel as JSON-RPC. Transport is where the practical split lives. A local server runs as a subprocess and communicates over standard input and output, which is why it has no address and never appears in a network scan. A remote server runs over HTTP and behaves more like a conventional service, with OAuth-based authorization and a real URL.

That local case is the one most security teams have not accounted for. A developer adds a few lines to a JSON config file, and a new integration with real credentials starts running on a laptop. Nothing was provisioned. Nothing was requested. Nothing was logged anywhere central.

This is the most common question about MCP, and the usual answer, that MCP is "a USB-C port for AI," describes the goal without explaining the mechanism.

The real difference is who reads the documentation and when.

An API is documented for humans. A developer reads the reference, decides which endpoints matter, writes code that calls them in a fixed order, and ships it. The integration is decided at build time and does not change until someone edits the code.

An MCP server documents itself to a model. When a client connects, the server returns a machine-readable list of its tools, each with a description and an input schema. The model reads that list and decides, at runtime, which tool to call and with which arguments. Nobody wrote that sequence in advance.

Two consequences follow, and they explain nearly everything else about MCP:

1. One integration serves every agent. Because the interface is standardized, an MCP server written once works with any compliant host. This is the reason adoption moved so quickly.
2. The call sequence is not knowable in advance. A traditional integration does what its code says. An agent with tool access does what the model decides in the moment, which may be a chain of calls across several servers that no reviewer anticipated.

An MCP server is not a replacement for an API. It is almost always a wrapper around one. The API is still underneath, still authenticating, still enforcing whatever permissions the credential carries. MCP changes who is driving.

Real deployments cluster into a few patterns:

Developer tooling. Servers for GitHub, Sentry, Jira, and filesystems let a coding agent read the repository, inspect an error, and open a fix. This is where MCP adoption started and where most servers still run.

Data access. Servers for Postgres, Snowflake, BigQuery, and internal warehouses let an agent answer questions against live data instead of a stale export.

Business systems. Servers for Salesforce, ServiceNow, Workday, and similar platforms let an agent read records and take actions inside the systems a company runs on.

Local capability. Filesystem, shell, and browser servers give an agent the ability to act on the machine it runs on. These carry the widest reach and the least visibility.

The catalog matters less than the pattern. Each server the agent can reach adds to what that agent can do, and those capabilities compose. An agent with a database server and a messaging server can read customer data and send it somewhere, even though neither server on its own was scoped to allow that.

Here is where the definition stops being academic.

An MCP server holds a credential. That credential belongs to somebody, usually the developer who set it up, and it carries that person's permissions. When an agent calls a tool on that server, the downstream system sees the credential, not the agent, and certainly not the person who typed the prompt.

Three properties follow, and together they describe why MCP servers are difficult to govern with existing tooling.

Effective authority does not match theoretical configuration. A server's config file says what it was set up to do. The credential it holds says what it can actually reach. Those two answers diverge constantly, because credentials accumulate scope over time and configuration is written once. Reviewing the config tells you the intent. Only runtime behavior tells you the reach.

The agent becomes a machine insider. A human without Salesforce access can prompt an agent whose MCP server holds Salesforce credentials, and the data comes back. No permission was bypassed and no exploit was used. The access was inherited, which is exactly why access reviews and identity tooling do not flag it.

Blast radius is the union, not the maximum. Risk is not the most privileged single server. It is the combination of everything one agent can reach in a single session. A read-only data server is low risk. A messaging server is low risk. An agent holding both can move data out through two legitimate tool calls.

None of this makes MCP servers unsafe to use. It makes them impossible to govern from a config page.

You cannot govern connections you cannot enumerate, and MCP servers are unusually good at staying unenumerated. Local servers have no network presence. They are added by individuals, not provisioned by IT. They appear between audits and disappear before the next one.

A workable approach has four parts:

Inventory continuously, not periodically. A point-in-time audit records the servers that existed on the day it ran. Because MCP servers are added in seconds by individual developers, a quarterly inventory is wrong within days. Discovery has to be ongoing to mean anything.

Separate sanctioned from unsanctioned. Some servers were reviewed and approved. Most were not. That divide is the first governance decision, and it is impossible to make without the inventory underneath it.

Read effective access, not declared configuration. For each server, the question worth answering is not what it was configured to do. It is what its credential actually reaches inside the connected system, and whether that exceeds what the workflow requires.

Score the combination. Evaluate what one agent can reach across every server available to it in a session, and flag the pairings that create a path from sensitive data to an external destination.

Obsidian builds this inventory from runtime activity rather than configuration, surfacing sanctioned and unsanctioned MCP servers across connected AI platforms, mapping the effective access each one holds, and scoring the toxic combinations that appear when an agent's servers are considered together.