What an MCP Server Does Inside an Agent Architecture
The Model Context Protocol standardizes how an AI agent connects to external tools, data sources, and prompts. That standardization happens across four components, each of which represents a distinct point of trust rather than a single unified permission surface.
| Component | Role |
|---|---|
| Host | The AI application that orchestrates agent behavior and initiates connections to MCP servers. |
| Client | Maintains a stateful one-to-one connection to a single MCP server on behalf of the host. |
| Server | Exposes tools, resources, and prompts to the agent; each server is a distinct trust boundary. |
| Transport | JSON-RPC 2.0 over stdio or HTTP(S)/SSE; security posture depends on the deployment choice, not the protocol itself. |
Because each server operates as its own trust boundary, a host that connects to several MCP servers is managing several independent trust relationships at once, not one centrally governed permission set.
Where Authentication and Authorization Gaps Emerge
The current MCP specification allows OAuth 2.1 as the authorization framework for HTTP-based servers, but it does not require every implementation to adopt it consistently. Enterprises evaluating an MCP deployment should confirm that each server is treated as an independent trust boundary requiring its own authentication, even when multiple servers feed a single agent host. Where a server accepts connections over HTTP, the OAuth 2.1 authorization flow defined in the current specification should be used in place of a custom authentication scheme.
Authorization gaps compound this problem. Tool exposure should be restricted to least-privilege scopes for each server rather than granting broad tool sets by default, and servers should be version-pinned so that authentication behavior does not shift unexpectedly when an unreviewed spec update is adopted upstream.
Tool Poisoning and Documented Vulnerabilities
Because tool descriptions and metadata enter an agent's reasoning context directly, unvalidated or unsanitized descriptions create an avenue for tool poisoning: manipulation of agent behavior through malicious metadata rather than a compromised credential. Descriptions and metadata should be validated and sanitized before they reach the agent's context to reduce this exposure.
Debugging and inspection interfaces present a related but separate risk. These tools should be isolated from production networks, and teams should monitor vendor advisories for known CVEs affecting MCP server or tooling dependencies, with a defined process for patching them as they are disclosed.
Governance Beyond the Protocol Specification
The protocol does not standardize a logging schema, which means tool-call