Anthropic released MCP in late 2024. Fifteen months later, the reference servers repository on GitHub has over 78,000 stars, official SDKs exist in ten languages, and the protocol is hosted by the Linux Foundation. Microsoft, OpenAI, and Google have all shipped MCP integrations. If you build agent systems and have not looked at MCP yet, the window where you could comfortably ignore it has closed.
That said, most of the coverage around MCP reads like either a hype pitch or an SDK tutorial. Neither is particularly useful for a senior engineer who needs to decide whether to adopt, how to structure adoption, and what governance to put around it. This article fills that gap. Think of it as the conceptual foundation -- the mental model you need before you start writing config files.
For teams already navigating MCP adoption, platforms like AgentPMT have emerged to solve the operational layer -- providing a managed marketplace of hundreds of MCP-compatible tools with built-in credential isolation and budget controls, so engineers can focus on architecture instead of plumbing. We will reference specific capabilities throughout, but first, the fundamentals.
The Mental Model: Clients, Servers, and Three Primitives
MCP follows a client-server architecture, but the vocabulary is specific enough that it is worth defining precisely.
An MCP host is your AI application -- Claude Desktop, VS Code with Copilot, a custom agent runtime, whatever runs the model. The host creates one or more MCP clients, each of which maintains a dedicated connection to an MCP server. The server is the program that exposes capabilities. It could be a local process communicating over standard input/output (the stdio transport), or a remote service communicating over Streamable HTTP. One host can connect to many servers simultaneously through separate client instances.
The mental model to hold in your head: the host is the orchestrator. Each client is a dedicated pipe to a single server. Each server is a boundary you can reason about independently.
What flows through those pipes is defined by three primitives:
Tools are executable functions the model can call. Search a database, send an email, create a calendar event. Each tool has a name, a JSON Schema describing its inputs, and an optional output schema. Tools are model-controlled -- the LLM decides when to invoke them based on context. The MCP spec is explicit that a human should always be able to deny a tool invocation, but the protocol does not enforce that. Your application does.
Resources are passive data sources. File contents, database schemas, API documentation, previous conversation logs. They are identified by URIs and are application-controlled -- meaning the host decides how and when to surface them, not the model. Resources are read-only context. If you are used to thinking about retrieval-augmented generation, resources are where your retrieved context enters the protocol.
Prompts are reusable instruction templates. A server can expose a "plan-vacation" prompt or a "code-review" prompt with typed parameters. The user (or application) selects and invokes them explicitly. They are useful for packaging domain-specific workflows alongside the tools and resources those workflows require.
The key distinction worth internalizing: tools act, resources inform, prompts guide. Mixing those up -- treating a resource like a tool, or giving a tool the freedom of a resource -- is where designs go sideways.
How the Protocol Actually Works
Under the hood, MCP is JSON-RPC 2.0. If you have ever worked with a language server in your editor, the interaction model will feel familiar. Client sends a request, server sends a response, both sides can send notifications.
The lifecycle starts with a capability negotiation handshake. The client sends an initialize request declaring what it supports (sampling, elicitation). The server responds with what it supports (tools, resources, prompts) and which notification types it will emit. This is important because it means neither side assumes the other can do everything. A minimal server might only expose tools. A richer server might expose all three primitives plus real-time list-change notifications.
After initialization, the client calls tools/list to discover available tools, resources/list to discover resources, or prompts/list for prompts. Each returns a paginated list with schemas and metadata. When the model decides to use a tool, the client sends tools/call with the tool name and arguments. The server validates, executes, and returns results -- which can be text, images, audio, or structured JSON.
The transport layer is cleanly separated from the data layer. Stdio transport is zero-network-overhead, ideal for local servers running as subprocesses. Streamable HTTP is the remote transport, using HTTP POST for client-to-server messages with optional Server-Sent Events for streaming. Google has been pushing to add gRPC as a third transport option, specifically because enterprises already standardized on gRPC infrastructure find the HTTP transport layer to be unnecessary friction. As Spotify engineer Stefan Sarne noted when demonstrating their internal MCP-over-gRPC work, "Because gRPC is our standard protocol in the backend, we have invested in experimental support for MCP over gRPC."
This transport-agnostic design is a deliberate architectural choice. The same tool definition, the same JSON-RPC messages, the same schema validation -- regardless of whether the server is a local subprocess or a cloud service on another continent. This cross-platform compatibility is also what makes AgentPMT's approach possible: because MCP standardizes the interface, AgentPMT can serve tools to Claude Code, VS Code, OpenAI-based agents, and any other MCP-compatible host from a single managed endpoint.
Why MCP Matters for Agent Systems Specifically
You could read the MCP spec and think "this is just a nice way to call functions." That misses the point. Agents have a specific problem that MCP solves better than ad-hoc integration: they need to discover capabilities at runtime, reason about what those capabilities do, and invoke them through a consistent interface -- across vendors, across tools, across deployment environments.
Before MCP, every agent framework invented its own tool format. LangChain had one. AutoGen had another. OpenAI function calling had a third. If you wanted your agent to use a Slack integration and a database query tool and a payments API, you wrote glue code for each. Swap the agent framework, rewrite the glue.
MCP replaces that with a single contract. A tool written as an MCP server works with Claude Code, VS Code, OpenAI's Agents SDK, Cursor, and any other MCP-compatible host. The official MCP GitHub organization now maintains SDKs in TypeScript, Python, Java, Kotlin, C#, Go, PHP, Ruby, Rust, and Swift. Microsoft's Azure guidance explicitly recommends MCP as the way to connect agents to tools. OpenAI's Agents SDK supports four MCP transport types natively, including a hosted mode where tool execution happens entirely within OpenAI's infrastructure.
The portability matters, but the real value for agent builders is the governance surface it creates. When every tool interaction goes through a protocol with defined schemas, discovery methods, and capability negotiation, you get natural points to insert policy. You can inspect what tools an agent has access to. You can validate inputs before they reach the server. You can log every invocation with a structured audit trail. You can require human confirmation for specific operations. None of this requires hacking the agent framework or intercepting raw HTTP calls. It is built into the protocol's interaction model.
The MCP spec itself says clients "SHOULD prompt for user confirmation on sensitive operations" and "SHOULD show tool inputs to the user before calling the server, to avoid malicious or accidental data exfiltration." Those are not just aspirational suggestions. They are the design philosophy: make the control points explicit so that hosts can enforce policy without fighting the protocol.
This is also where a layer like AgentPMT's DynamicMCP approach adds value. Instead of preloading every tool into your agent's context at startup -- which burns tokens and creates a sprawling attack surface -- DynamicMCP fetches tools on demand from a centralized catalog. The agent searches for what it needs, the control plane enforces budgets and allow-lists, and tool execution happens server-side. It is the difference between giving someone the keys to every room in the building and giving them a concierge who opens specific doors when asked.
The Adoption Path: Start Read-Only, Add Writes Incrementally
The fastest way to get MCP wrong is to start with write operations. An agent that can read a database is a research tool. An agent that can write to a database is a liability until you have proven it makes correct decisions under failure conditions.
The adoption path that works in practice looks like a ladder:
Rung one: read-only tools. Connect your agent to MCP servers that expose only safe reads. Filesystem servers with read-only access. Database query tools that cannot modify data. API wrappers that only fetch information. At this stage, the worst outcome is a wasted API call. You are learning how the agent discovers and invokes tools, how latency affects the conversation loop, and how tool results flow back into the model's reasoning. Instrument everything -- attach a run ID to each tool invocation, log the tool name, the arguments, and the result.
Rung two: bounded writes with strict schemas. Once you trust the read path, introduce tools that can modify state -- but only through narrow, schema-validated interfaces. A tool that updates a single field in a CRM record with an enum of valid values, not a tool that accepts arbitrary SQL. Require idempotency keys so retries never cause duplicates. Set budget caps per run. If a tool cannot say "no" safely -- if it has no concept of input validation or graceful rejection -- it is not production-ready, regardless of how useful it is in a demo.
Rung three: multi-step workflows with approval gates. Now you can chain tools into workflows where some steps require human confirmation. The MCP spec supports this through the elicitation primitive (servers can request user input) and through application-level approval flows. OpenAI's Agents SDK implements this as a require_approval parameter that can be set per-tool or per-server, with options for "always," "never," or a per-tool-name mapping. Build workflows where irreversible actions -- sending an email, processing a payment, modifying a production record -- require explicit approval while safe reads auto-execute.
Rung four: autonomous operation under policy. This is where the agent operates with minimal human intervention, but within a policy envelope. Budgets cap spend. Allow-lists restrict which tools and which servers the agent can access. Monitoring detects anomalies. The safety comes not from human review of each action but from the constraints being enforced server-side, where the agent cannot circumvent them. Platforms like AgentPMT enforce this pattern natively -- budget controls and audit trails operate at the infrastructure level, not the prompt level, which means policy survives model upgrades and prompt changes.
Each rung earns trust through evidence. You do not promote a workflow from rung two to rung three because someone feels confident about it. You promote it because you have replay tests showing it handles partial failures correctly, adversarial inputs gracefully, and budget limits strictly.
Governance Before You Ship
MCP makes tool integration cheaper. That is the point, and it is also the risk. When adding a new tool is as simple as pointing a client at a server URL, the temptation is to treat tool installation as a developer convenience. It is not. It is a supply chain decision.
Every MCP server your agent connects to is a dependency. It can change behavior between versions. It can introduce new data egress paths. It can start returning different error codes that your retry logic does not handle. The moment you connect to it, you have accepted its risk profile into your system.
Governance for MCP adoption comes down to a few concrete practices:
Pin versions. Treat MCP server upgrades like you treat library upgrades -- review the changelog, test in staging, diff the capability list. If a server starts exposing new tools or changes its schema between versions, your control plane should notice before your agent does.
Centralize tool policy. If governance lives in prompt instructions, it will drift the moment someone updates the system prompt. Policy needs to live above the agent, in a layer that enforces allow-lists, budgets, and access controls regardless of which model or prompt is driving the conversation. This is one of the core problems we built AgentPMT to solve -- central policy over a dynamic tool catalog, so that adding a new tool does not mean adding a new governance gap.
Log for attribution. Every tool call should produce a record that includes the run ID, the tool name and version, the policy decision (allowed, denied, escalated), the cost, and the outcome. You should be able to explain why your agent did what it did and how much it cost without reading raw conversation transcripts. When an incident occurs -- and incidents will occur -- attribution is the difference between diagnosis and blame.
Treat annotations as untrusted. The MCP spec includes tool annotations that describe behavior -- whether a tool is read-only, whether it has side effects, its intended audience. The spec is explicit: clients "MUST consider tool annotations to be untrusted unless they come from trusted servers." This is good advice. If a third-party MCP server claims its tool is read-only, verify that claim. Trust but verify is the wrong posture here. Verify, then trust.
Design for revocation. Fast rollback is a feature. If you discover a tool is misbehaving, you need to be able to disconnect it without redeploying your application. If your MCP setup requires restarting the host to remove a server, your architecture has a gap. The protocol's listChanged notification mechanism supports dynamic tool list updates -- use that to your advantage.
Implications for Engineering Teams
The standardization of MCP has consequences that extend beyond the protocol itself.
Build-versus-buy shifts toward buy. When every tool speaks the same protocol, the cost of integrating a third-party tool drops to near zero. Engineering teams that previously built custom integrations because the integration cost was high relative to the tool cost will increasingly find it cheaper to adopt managed tools from marketplaces like AgentPMT -- which offers hundreds of pre-built, credential-isolated MCP tools -- than to maintain bespoke implementations. The engineering effort shifts from building connectors to evaluating and governing them.
Agent infrastructure becomes a discipline. MCP creates a new category of infrastructure: the tool control plane. This is the layer that manages which tools are available, who can use them, what they cost, and what happens when they fail. Teams that treat this as an afterthought -- hardcoding tool lists into agent configs, managing credentials in environment variables, ignoring cost tracking -- will accumulate operational debt that compounds with every new tool and every new agent.
Security review processes need updating. Traditional application security review focuses on APIs your application exposes. With MCP, you also need to review the APIs your agent consumes. Every MCP server is a trust boundary. Every tool invocation is a potential data flow. Security teams need to add MCP server review to their threat modeling workflows, and engineering teams need to make that review cheap by centralizing tool access through auditable control planes.
The talent bar shifts. Engineers who understand both the protocol layer and the governance layer -- who can design tool schemas, configure policy engines, and reason about agent behavior under failure conditions -- will be disproportionately valuable. MCP fluency is becoming a practical skill, not a niche specialization.
What to Watch
Three trends will shape how MCP adoption plays out over the next twelve months.
First, transport convergence. Google's push for gRPC transport support, Anthropic's Streamable HTTP, and the community's work on pluggable transport interfaces all point toward a world where the data layer is stable while the transport layer adapts to enterprise requirements. Watch for the gRPC proposal to land in the official SDK -- it will remove a significant adoption barrier for backend-heavy engineering organizations.
Second, governance tooling. The protocol provides the control points. The ecosystem has not yet built mature tooling around them. Expect to see more central policy engines, tool catalogs with provenance tracking, and runtime monitoring specifically designed for MCP server fleets. This is the layer where infrastructure like AgentPMT's DynamicMCP and x402Direct sit -- connecting agents to tools through a managed control plane with budget enforcement and usage-based payment built in.
Third, the security surface. As MCP adoption grows, so does the target surface for supply chain attacks through malicious or compromised MCP servers. The MCP spec already includes security guidance -- input validation, rate limiting, output sanitization, access controls -- but implementation varies wildly across the open-source server ecosystem. The teams that treat MCP servers like production dependencies with security review processes will avoid incidents that catch others off guard.
MCP is not a silver bullet and it is not vapor. It is a practical protocol that solves a real coordination problem between agents and tools. The mental model is straightforward: hosts connect to servers through clients, servers expose tools, resources, and prompts through a JSON-RPC interface, and the whole thing is designed with control points baked in.
The engineers who adopt it well will be the ones who treat it as infrastructure, not as a developer shortcut. Pin your versions. Start read-only. Centralize your policy. Log everything. Then scale.
If you are evaluating MCP for your team and want a managed path that handles credential isolation, budget controls, and audit trails out of the box, explore AgentPMT -- it is built specifically for engineering teams adopting MCP at scale.
Key Takeaways
- MCP is a client-server protocol with three primitives -- tools (actions), resources (context), and prompts (templates) -- that standardizes how agents discover and invoke capabilities across any compliant host.
- The safest adoption path is incremental: start with read-only tools, add bounded writes with strict schemas, layer in approval gates for irreversible actions, and only then move toward autonomous operation under server-side policy enforcement.
- Every MCP server is a supply chain dependency -- pin versions, centralize tool policy above the agent layer, log all invocations for attribution, and design for fast revocation when things go wrong.
Sources
- MCP Architecture Overview - modelcontextprotocol.io
- MCP Tools Specification - modelcontextprotocol.io
- MCP Resources Specification - modelcontextprotocol.io
- MCP Server Concepts - modelcontextprotocol.io
- Model Context Protocol - GitHub Organization - github.com
- Microsoft Learn - Build Agents using Model Context Protocol on Azure - learn.microsoft.com
- OpenAI Agents SDK - MCP Integration - openai.github.io
- Google Pushes for gRPC Support in MCP - infoq.com
- Awesome MCP Servers - github.com