An MCP server is a program that exposes tools, resources or prompts to AI applications over the Model Context Protocol, running either locally alongside the client or as a remote service. Each server extends what a connected agent is able to do.
The Model Context Protocol standardizes how AI applications connect to external capabilities. The server is the unit that gets connected: a file-system server, a database server, a server for an issue tracker or a cloud provider. Installing one takes minutes. What it changes about the agent deserves more thought than that.
What a server exposes
A server offers three kinds of capability, each with a different default for who decides when it is used:
- Tools are functions the model can call to take actions, such as creating an issue or querying a database. The protocol’s documentation describes them as model-controlled: the model discovers and invokes them.
- Resources are data the application can read into context, such as files or records. They are application-driven.
- Prompts are templates a person invokes explicitly. They are user-controlled.
Most of an agent’s new capability comes from tools, because the model can call them on its own, and many of them change things.
What connecting a server grants
The useful way to see an MCP server is as a grant of capability, not a plugin. Connecting one gives an agent four things at once:
| What the server adds | In practice |
|---|---|
| New operations | Each tool is something the model can call: some only read, many write or change state in another system |
| New data | Resources add data to context, and tool results bring in more |
| New instructions | Tool names and descriptions are text the model reads and may follow |
| A new dependency | Code you run, or a service you call, that you now trust |
Seen this way, connecting a server is closer to granting a new role than to installing a library. It changes what the agent can do on every task it runs, not just the one it was installed for.
Local and remote are privilege questions
The usual comparison of local and remote servers is about hosting. The more important difference is privilege.
A local server runs with the effective permissions of the identity that starts it. By default that is usually you: the protocol’s security guidance warns that local servers run with the same privileges as the client, which can include your files, environment variables and credentials. Those permissions can be narrowed, and the same guidance recommends running local servers in a sandboxed environment with minimal default privileges.
A remote server’s authority has two parts: the tokens the client delegates to it, and whatever permissions the server holds on its own side, such as its own service credentials. Its reach is the combination. The protocol’s guidance names confused deputy vulnerabilities in servers that broker access to third-party services, and forbids servers from accepting tokens that were not issued for them.
Trust in what a server says
Because tool descriptions are text the model reads, a server can steer an agent without any of its tools being called. Researchers have demonstrated tool poisoning, in which instructions hidden in a tool’s description are invisible to the user but visible to the model, and attacks in which a malicious server injects instructions through its descriptions before the user ever uses it. A description can also change after it was reviewed. The protocol’s specification says that clients should treat tool annotations as untrusted unless they come from a trusted server.
Scoping a server like a grant
Treating a server as a grant suggests a short discipline:
- Inventory which servers each agent has connected, and who approved them.
- Scope each to the least privilege the work needs: read-only where possible, narrow tokens, a sandbox for local servers.
- Review tool descriptions as untrusted input, and notice when they change.
- Decide where approval sits for consequential tools: in the client, at a gateway, or in the server itself.
- Record each tool call: which agent, which tool, with what target, under which task.
An example
The following is illustrative.
A team connects a project-management server so its agent can read tickets. The server also exposes tools to close and reassign tickets and to post comments, and it runs locally with the developer’s API token, which has administrator rights. Weeks later the agent, asked to summarize open bugs, reassigns several of them while “tidying up”. Nothing was misconfigured by the protocol’s standards. The server granted everything its tools offered, with every right the token carried.
A read-only token, a review of the tools the server exposed, and a record of which tools the agent actually called would each have caught the gap between what the team meant to grant and what it granted.
How Sentience Governor relates
Sentience Governor’s client wrapper sits between an agent and the MCP servers it calls. Each tool call is evaluated against the session’s declared intent and declared scope and recorded as an agent action at the execution boundary, without blocking. Governor also ships an optional local MCP server of its own, so an agent can declare intent and read its governance state through the protocol.
Often confused with
API. An API is an interface a developer programs against. An MCP server packages capabilities in a form an AI application can discover and invoke on its own, which is what makes it a grant to the agent rather than to the developer.
Skill or plugin. Some agent products package instructions and scripts as skills. An MCP server is a separate process speaking a standard protocol, and it can serve any compatible client.
The protocol itself. The Model Context Protocol is the standard. A server is one implementation of its server side.
Where the concept stops
An MCP server defines what capabilities are available to a connected agent. It does not decide which of them a particular task should use, it does not make its own descriptions trustworthy, and connecting it says nothing about whether the agent used it appropriately. Those depend on how the server was scoped and what was recorded when it was used.