Model Context Protocol is a specification that standardizes how AI applications discover and invoke external tools. A wire protocol, specifically. Its job is narrow and important: make tool connectivity vendor-agnostic, so an AI application built on one foundation can call tools built on another without a custom integration in between.
Anthropic published the initial MCP specification in November 2024. The Linux Foundation took on governance in early 2025. Adoption moved faster than most protocol standards do, partly because the problem it solves is genuinely painful and partly because the major model providers got behind it early. By mid-2026, MCP server implementations exist for most major enterprise platforms — document stores, ticketing systems, CRMs, code repositories — and the AI application vendors are treating MCP support as table stakes rather than a differentiator.
What the field is now learning, the hard way: MCP handles connectivity. It does not handle judgment. Those are different problems, and conflating them is where the early enthusiasm started going sideways.
• MCP: A wire protocol that standardizes how AI applications discover available tools and invoke them across vendor boundaries, replacing one-off integrations with a common interface. It says nothing about whether the caller should be allowed to use what it finds.
How It Works
Two components. An MCP server exposes capabilities — tools the agent can call, resources it can read, prompt templates it can use. An MCP client is the AI application or agent that connects to the server and uses those capabilities.
The interaction starts with discovery. The client connects to the server and asks, essentially, "what do you have?" The server responds with a manifest: a structured list of available tools, each with a name, a natural-language description, and an input schema specifying what parameters the tool accepts. A document management server might expose tools named search_documents, retrieve_document, and submit_for_approval. The manifest tells the client what each tool does and how to call it.
Those natural-language descriptions aren't for the client's benefit. They're for the LLM's benefit. The language model reads the tool descriptions and decides which tool to invoke based on what it's trying to accomplish. The agent doesn't have hard-coded logic that says "use search_documents for this task." It reads the description, infers the match, and makes the call.
Once the agent selects a tool, the client sends a structured invocation request — tool name, parameters — and the server executes it. The server returns results in a standardized format. The agent incorporates those results into its context and continues.
That's the full loop: connect, discover, invoke, receive. MCP standardizes every step of it. What happens inside the tool when it executes — what systems it touches, what data it returns, what side effects it produces — is entirely outside MCP's scope.
A practical scale anchor: a reasonably capable MCP server might expose twenty to forty tools. An enterprise deployment with multiple servers connected to a single agent could surface a hundred or more. The agent's decision about which tool to call, for which task, at which moment, is happening across that entire space every time it acts.
• MCP mechanism: Client connects to server, receives a manifest of available tools with natural-language descriptions, selects and invokes tools based on those descriptions, and receives structured results. The LLM reads the descriptions; the protocol handles the plumbing.
Okta Concept Mapping: MCP and LDAP
MCP is to agent tool access what LDAP is to directory queries. Both are protocols for finding and reaching things — LDAP lets you query a directory to locate users and resources, MCP lets an agent query a server to locate and invoke tools. The analogy holds at the structural level: discovery protocol, standardized query format, returns structured data.
Where it breaks: LDAP operates inside a mature authorization stack. Decades of tooling — ACLs, group policies, PAM systems, your Okta tenant — sit on top of it and govern what the caller can actually do with what it finds. MCP is operating in an environment where that authorization layer is still being assembled. The protocol will let an agent discover and invoke a tool that modifies production records if the server exposes it and the agent decides to call it. Nothing in MCP stops that. The "who decided the agent could do this" question is yours to answer, not the spec's.
When You'll Encounter It
The conversation usually surfaces in one of two ways. Either a CAIO mentions that their new AI assistant "uses MCP" to connect to agency systems, or a procurement document lists MCP support as a technical requirement and someone needs to know what that means before the next call.
A scenario that's becoming common in federal civilian agencies: a contract office is piloting an AI assistant to help contracting officers research vendors, draft acquisition documents, and check compliance status. The system connects via MCP to the agency's document management platform, its vendor database, and its contract tracking system. The CAIO, in a briefing, says the architecture is "MCP-native" and the assistant can reach any system that has an MCP server.
Yes, and that's the connectivity story. The harder question — the one the CISO will ask in the next meeting — is what governs when the assistant reaches those systems, under what identity, with what scope, and with what audit trail.
MCP doesn't answer any of those questions. It answers "can the agent find and call the tool?" The questions the CISO cares about are downstream of that. Who authorized the agent to act on behalf of this contracting officer? What happens when the agent's session token expires mid-task? If the assistant submits a document for approval, whose identity is attached to that action in the audit log?
These aren't hypothetical concerns. They're the questions that determine whether a deployment survives its first security review. MCP gets the agent to the door. Your identity stack decides who's allowed through it.
The early pattern of "connect everything via MCP and let the agent figure it out" is giving way to something more deliberate. MCP handles the wire. Skills — the curated set of tools an agent is actually given access to — handle scope. Prompts and harness logic handle when and how those tools get invoked. The agent doesn't need to know about every tool on every connected server; it needs to know about the tools appropriate to its role, governed by the same least-privilege logic you'd apply to a human user.
That framing should feel familiar. It's the same argument you've been making about service accounts for fifteen years.
• Practical implication: MCP answers the connectivity question. The identity, authorization, and audit questions are separate — and they're where the conversation gets hard. When a buyer says "MCP-native," your follow-up is: what governs the agent's scope, and under whose identity does it act?
The Corrective the Field Is Learning
The enthusiasm for MCP was real and the adoption is real. The problem is that "the agent can reach everything" is not the same as "the agent should reach everything," and MCP doesn't distinguish between those two states.
The disciplined pattern from practitioners who've run agents in production: MCP for the wire, skills for scope, prompts for intent, harness logic for oversight. The agent gets a curated manifest — not the full catalog of everything every connected server exposes, but the specific tools appropriate to its function. The prompts it operates under constrain how it uses those tools. The harness — the orchestration layer wrapping the agent — enforces checkpoints before consequential actions.
None of that is MCP's job. MCP is doing its job correctly when it reliably connects the agent to the tools it's supposed to reach. The judgment layer is built on top of it, and right now, building that layer well is where the actual engineering work lives.
For the conversation ahead: if a buyer is excited about MCP, that's legitimate. The connectivity problem it solves is real, and the standardization is genuinely useful. If a buyer thinks MCP solves their agent governance problem, that's the moment to ask what's sitting on top of the wire. Because the wire, by itself, doesn't know the difference between a read and a write, between a test environment and production, or between an action the user intended and one the agent inferred.
The spec is honest about what it is. The field is still catching up.