An MCP server is a program that exposes capabilities to an AI agent through the Model Context Protocol. When an agent needs to query a database, read a file, call an API, or trigger a workflow, an MCP server is what actually makes that capability available in a standardized way.
This guide covers what an MCP server actually is, how it differs from both tools and agents, what changed in the July 2026 specification revision, the documented security risks, and the practices production deployments require.
What Is the Model Context Protocol?
The Model Context Protocol, commonly abbreviated MCP, is an open standard defining how AI applications connect to external data sources and tools. Anthropic released it in November 2024, and adoption has moved faster than most security teams anticipated.
Before MCP, every integration between an AI application and an external system required custom work. MCP standardizes that connection, which is genuinely useful and also concentrates risk in a new place worth understanding deliberately.
MCP Server vs Tools vs Agent: The Distinction That Matters
These three terms get used interchangeably and mean genuinely different things.
An MCP server is the program. It runs as a process, either locally on the same machine or remotely over HTTP, and it exposes a defined set of capabilities.
Tools are the individual capabilities that server exposes. A single filesystem MCP server might expose separate tools for reading a file, writing a file, and listing a directory. Tools are what an agent actually invokes.
An agent is the system deciding which tools to call and in what order, based on what a user asked for. The agent reasons. The server executes. Conflating these makes security conversations confusing, because the trust boundaries sit in different places for each.
Component | What It Is | What It Does |
MCP server | A running program | Exposes tools, resources, and prompts over the protocol |
Tool | A single capability within a server | Performs one specific operation when invoked |
Agent | The reasoning system | Decides which tools to call and interprets results |
The security implication of this distinction is direct: an MCP server acts with its own credentials, not the credentials of whoever asked the agent to do something. Treat every MCP server as a privileged service in its own right.
What Changed in the July 2026 Specification
The MCP specification revision dated 2026-07-28 made several changes that matter for anyone deploying in production.
It deprecated Dynamic Client Registration, added issuer validation requirements, and introduced issuer-bound client credentials. For remote HTTP servers, the specification treats the server as an OAuth 2.1 resource server, with PKCE, resource indicators binding tokens to specific server URLs, and Protected Resource Metadata so clients can locate the authorization server.
Two requirements deserve particular emphasis. An MCP server must not accept any token that was not explicitly issued for that server itself. And token passthrough patterns, where a token intended for one service gets forwarded to another, are explicitly prohibited because they bypass the audience validation the model depends on.
Confirm the current specification revision directly before building, since this standard has revised meaningfully more than once and will likely revise again.
Documented MCP Security Risks
These are not hypothetical. Each has been documented in real deployments.
Tool poisoning embeds malicious instructions inside a tool’s description. Because tool descriptions load directly into the model’s context, a compromised description can manipulate agent behavior before the agent ever calls anything.
Prompt injection through tool results is a related and distinct problem. OWASP identifies prompt injection as LLM01 in its 2026 GenAI Top 10, and tool output is explicitly an injection channel. An agent processing data returned by a tool is processing untrusted input.
Broken authentication on remote servers has produced real disclosed vulnerabilities. Security researchers disclosed flaws in both the Dolt MCP and Grafana MCP servers in 2026, where an unauthenticated caller could run tools using the server’s own credentials.
Sandbox escape has also been documented. Anthropic’s Filesystem MCP server was found to have a symlink containment bypass permitting arbitrary file access.
Over-broad permissions compound every risk above. A server granted more access than its purpose requires turns any single successful exploit into a much larger incident.
MCP Server Security Best Practices
Run every MCP server in an isolated container with minimal permissions, a non-root user, a read-only root filesystem where possible, and no host network access unless genuinely required. Without isolation, a compromised server reaches your filesystem, network, and environment variables directly.
Enforce per-request identity rather than shared credentials. Every call should carry the identity of the specific user or agent making it, authenticated through a standard protocol such as OAuth 2.1 or OIDC.
Maintain an inventory and an allowlist. Know every MCP server an agent can reach, and approve servers and tools explicitly rather than permitting whatever happens to be configured.
Keep secrets out of configuration files. Do not paste API keys or connection strings into MCP JSON configs. Use environment variable references, an OS keychain, or a secret manager that the server reads at startup.
Log every tool invocation with the caller identity, and route those logs somewhere a security team actually watches. If you cannot see what your MCP servers are doing, you cannot detect an incident involving them.
Inspect tool descriptions on every update. A supply chain attack against a third-party MCP server package could modify a tool description specifically because descriptions reach the model’s context directly.
MCP Server Best Practices for Reliability
Security is not the only production concern. Design each server as a single bounded context rather than a catch-all host for unrelated tools, which keeps permissions narrow and reasoning clearer for the agent selecting among them.
Use strict typing, documented error cases, and consistent naming in your schemas, since both humans and models have to reason about them without ambiguity. Externalize state rather than holding it in server memory, which makes scaling elastic without introducing context drift.
Choosing MCP Servers in 2026
Queries about the best MCP servers in 2026 are common, and the honest answer resists a simple ranking. The ecosystem moves quickly, and a server that is well maintained today may not be in six months.
Evaluate a candidate server on specific criteria instead: active maintenance and a responsive security disclosure process, whether it follows the current specification’s authorization requirements, how narrowly its tools are scoped, and whether its permissions can be constrained to your actual use case. A widely used server with broad permissions and stale maintenance is a worse choice than a less popular one meeting these criteria.
Enterprise Use Cases
A Business Running MCP Servers Without an Inventory
Problem: A business has MCP servers configured across several teams and no central record of which servers agents can actually reach.
Solution: Building an inventory of every MCP server in use, then establishing an allowlist of approved servers and tools rather than permitting whatever is configured locally.
Outcome: The business knows its actual MCP attack surface and can evaluate each server deliberately rather than discovering an unmaintained one during an incident.
A Team Storing Credentials in MCP Config Files
Problem: A team pasted API keys and database connection strings directly into MCP JSON configuration files for convenience during development.
Solution: Moving every secret into a secret manager or OS keychain, with the server reading credentials at startup through environment variable references instead.
Outcome: Credentials no longer sit in configuration files that get copied, committed, or shared, closing a direct and avoidable exposure path.
An Enterprise Unable to Audit Agent Tool Usage
Problem: An enterprise’s agents invoke MCP tools regularly, but no log records which identity triggered which tool call.
Solution: Logging every tool invocation with the caller identity and routing those logs to the security team’s existing monitoring system.
Outcome: The enterprise can reconstruct exactly what an agent did and on whose behalf, which is the baseline requirement for investigating any incident involving agent actions.
Decision Tree: Is Your MCP Deployment Production-Ready?
RTC LEAGUE MCP Deployment Security Framework v1.0
A five-step RTC LEAGUE framework for deploying MCP servers responsibly in production.
Step 1: Inventory every MCP server an agent can reach. Establish an allowlist of approved servers and tools.
Step 2: Isolate every server in its own container. Apply minimal permissions, non-root execution, and constrained network and filesystem access.
Step 3: Enforce per-request identity through OAuth 2.1 or OIDC. Confirm no server accepts a token not issued specifically for it.
Step 4: Move every secret out of configuration files. Use a secret manager or OS keychain read at startup.
Step 5: Log every tool invocation with caller identity. Route logs to a system your security team actively monitors.
Outcome: Completing this sequence produces an MCP deployment where each server is treated as the privileged service it actually is, rather than a convenient integration configured once and forgotten.
Final Take
An MCP server exposes tools to an AI agent through an open standard that has genuinely simplified integration work. That same standardization concentrates privilege in a place many teams have not yet treated as a security boundary, and the documented vulnerabilities in 2026 reflect exactly that gap.
The clearest recommendation: treat every MCP server as a privileged service with its own credentials, isolate it, enforce per-request identity, keep secrets out of config files, and log every tool call. Confirm the current specification revision before building, since this standard continues to evolve.
