MCP-Based Tool Connectivity
What it is: A wire protocol that lets AI applications discover and invoke external tools without building a custom integration for each one.
What it does: An MCP server exposes a set of tools — functions an AI agent can call — along with machine-readable descriptions of what each tool does and what parameters it takes. The agent connects to the server, reads the tool manifest, and can invoke any listed tool using a standard message format. The agent doesn't need to know anything about the underlying API; the MCP server handles that translation. One server, many tools, one protocol.
Who's behind it: Anthropic published the initial Model Context Protocol specification in late 2024 and donated governance to the Linux Foundation in early 2025. Since then, OpenAI, Google DeepMind, Microsoft, and most major AI platform vendors have adopted it. It's moving toward being the de facto standard for agent-to-tool connectivity, which is either a sign of genuine consensus or of everyone wanting to be on the right side of a bet — probably both.
What makes it distinct: The N×M problem, solved at the wire level. Before MCP, connecting ten agents to ten tools meant up to a hundred custom integrations. With MCP, a vendor ships one server and any compatible agent can use it. That's the proposition. Whether the agent uses it wisely is a separate question, and MCP has nothing to say about it.
Okta Concept Mapping: The SAML Parallel
SAML solved the same N×M problem for identity federation. Before it, every service provider and identity provider pair needed a custom integration. SAML introduced a common wire format — assertions, bindings, metadata — that let any compliant SP talk to any compliant IdP. MCP is doing the same thing for agent-to-tool connectivity. Where the analogy holds: both protocols eliminate per-pair integration work by establishing a shared format. Where it breaks: a SAML assertion carries identity claims with inherent semantic meaning — the attribute "email" means something specific. An MCP tool description is natural-language text that the model interprets, which means description quality matters in a way that a SAML attribute definition doesn't. A poorly written tool description produces unpredictable behavior; a poorly written SAML attribute just fails validation.
Bespoke API Integrations
What it is: A custom-built connection between an AI agent and a specific external service, written for that service's API.
What it does: A developer writes code that knows how to authenticate to the target service, format requests, parse responses, handle rate limits, and manage errors. The agent calls a function in the integration layer; the integration layer handles the API call. Each integration is purpose-built. It knows the terrain — the quirks of that one API, the edge cases that aren't in the documentation, the retry logic that actually works in production.
Where it comes from: This is the default pattern that existed before MCP, and it's still how most production AI systems connect to internal tools and legacy services. There's no consortium behind it, no spec to reference. It's just software.
What makes it distinct: Precision at the cost of scale. A bespoke integration can handle authentication flows, pagination, partial failures, and data transformations that a generic protocol can't anticipate. The tradeoff is that every new tool requires a new integration, and every integration is a maintenance obligation. In a world where an agent needs to call three well-understood internal services, that's fine. In a world where the tool landscape is expanding weekly, it becomes a bottleneck.
Comparing the Two: A Scenario Map
Structure note: I'm using scenario mapping here rather than a trait-by-trait comparison. For this audience, the useful question isn't "which approach is better" — it's "which situation am I hearing about, and what does that tell me about the architecture?" The scenarios below trace the arc from early MCP enthusiasm to where the field is actually landing.
Scenario 1: The "connect everything" phase (2024–early 2025)
When MCP gained traction, the initial response from a lot of teams was to stand up MCP servers for every tool they had and let the agent figure out the rest. The logic was hard to argue with: if the agent can see all the tools, it can pick the right one. Technically true. Practically problematic. An agent with access to 40 tools and no governance layer for tool selection will call tools in unpredictable combinations, generate unnecessary API calls, and produce outputs that are hard to audit. Several early enterprise deployments learned this the hard way. The problem wasn't MCP — the wire worked fine. The problem was that "can call" and "should call" are different questions, and MCP only answers the first one.
Bespoke integrations, by contrast, never created this illusion. When you build a custom integration, you're already making a decision: this agent, this tool, this purpose. The integration is the governance. It's not elegant, but it's legible.
Scenario 2: Where bespoke still wins
A few circumstances still favor bespoke integrations, and it's worth being able to name them. Internal legacy systems that predate modern API conventions often require integration logic that would be awkward to express in an MCP server — custom auth flows, SOAP endpoints, batch processing patterns. High-stakes, low-variability workflows where the agent always calls the same tool in the same way benefit from the predictability of a purpose-built integration. And any situation where the integration logic itself is a compliance artifact — where you need to demonstrate exactly what the agent did and why — is easier to audit with bespoke code than with a general-purpose protocol layer.
MCP doesn't replace bespoke integrations in these cases. It supplements them, or it doesn't apply.
Scenario 3: The disciplined architecture (where the field is landing)
The pattern emerging in more mature deployments separates the wire from the judgment. MCP handles discovery and invocation — the agent can find tools and call them using a standard protocol. A separate layer, variously called a skill layer, harness logic, or orchestration layer depending on who's describing it, governs which tools the agent is allowed to consider for a given task, in what order, under what conditions. This layer is where governance actually lives.
In this architecture, MCP is infrastructure. It's the plumbing. The skill layer is where you express policy: this agent, in this context, with this user's permissions, can use these tools. That's a familiar concept if you think about it in IDAM terms, which is exactly what the callout below does.
The Connectivity/Judgment Gap
MCP tells the agent what tools exist and how to call them. It does not tell the agent which tool is appropriate for the current task, whether the current user's context permits that tool call, or what to do when two tools return conflicting results. Those are judgment problems, and they're addressed — to whatever extent they're addressed — by prompt engineering, skill definitions, harness logic, and governance policies that sit above the protocol layer. A vendor who says "we're MCP-enabled" has described their wire. They haven't described their judgment layer, and that's the question worth asking.
Okta Concept Mapping: Authentication vs. Authorization
In IDAM, authentication establishes who's present; authorization establishes what they're permitted to do. MCP is authentication-layer thinking applied to tools — it establishes that the agent can reach a tool and invoke it. Whether the agent should call that tool, given the current user's context and the task at hand, is authorization-layer thinking. That layer doesn't come with MCP. In a federal account conversation, this maps directly: your buyer understands the difference between "the user authenticated" and "the user is authorized to access this resource." The same distinction applies here, and using that framing lands faster than any AI-specific vocabulary.
Where Okta's MCP Server Registration Fits
Okta has publicly announced an MCP server capability that allows AI agents to discover and invoke Okta-managed identity operations — user lookup, group membership queries, policy checks, and similar functions — through the standard MCP protocol. This sits at the connectivity layer. It means an MCP-compatible agent can find and call Okta's identity functions without a bespoke Okta integration for each agent implementation.
Governance of which tools the agent calls, in what order, under what conditions — that's not in scope here. Authorization policy lives elsewhere. So does the decision about when an agent should query identity data versus when it should proceed without it. Those decisions live in the skill layer or harness logic above the protocol, and they remain the customer's responsibility to design.
In a buyer conversation, the accurate placement is this: Okta's MCP server handles connectivity and discovery for identity operations. Agents that need to reason about identity (who is this user, what groups are they in, what policies apply) can reach Okta through a standard protocol instead of a custom integration. When the agent makes those calls, and under what conditions, is still an architecture question the customer has to answer.
Okta Concept Mapping: The Directory Analogy
Think of Okta's MCP server the way you'd think of LDAP directory access. LDAP gave applications a standard protocol to query directory information — user attributes, group memberships, organizational structure. It didn't tell applications what to do with that information or when to query it. Okta's MCP server does the same thing for AI agents: it provides a standard interface to identity data and operations. The application logic — now expressed as agent harness logic or skill definitions — still decides when and why to use it. The analogy has a limit: LDAP queries were deterministic and application-initiated on a predictable schedule. Agent-initiated identity queries can happen at unpredictable points in a reasoning chain, which creates audit and governance requirements that LDAP architectures never had to address.
How to Say This in the Field
The terms below get used interchangeably by buyers and vendors. They're not interchangeable. The "Do say" column is written to be usable verbatim.
| Don't say | Do say | Why it matters |
|---|---|---|
| "We're MCP-enabled" (as a complete answer) | "MCP handles our tool discovery and invocation. What governs which tools the agent actually calls?" | MCP describes the wire, not the judgment layer. The follow-up surfaces whether they've built the governance layer. |
| "The tool calls the API" | "The MCP server calls the API. The tool is the function the server exposes to the agent." | Server, tool, and API are three different things. Conflating them makes architecture conversations impossible to follow. |
| "MCP replaced our integrations" | "MCP replaced the wire protocol. The integration logic — auth, error handling, data mapping — lives in the MCP server implementation." | Saying MCP "replaced integrations" implies the integration work went away. It moved. |
| "A skill is just a tool" | "A tool is a function the agent can invoke. A skill is a governed capability — it wraps one or more tools with policy about when and how to use them." | Vendors use these interchangeably. The distinction is where governance lives. |
| "The model decides which tool to use" | "The model picks from what it can see. What it can see is governed by the tool manifest and whatever skill layer sits above it." | "The model decides" sounds like intelligence. It's actually selection from a list. The list design is the governance question. |
| "Our agent can use any MCP tool" | "Any tool it can discover and is permitted to call. Discovery and permission are two separate controls." | Discovery without permission scoping is the "connect everything" anti-pattern. |
| "Okta's MCP server handles the authorization" | "Okta's MCP server handles connectivity to identity operations. Authorization policy — who can call what, under what conditions — is still your governance layer to define." | Accurate placement of Okta's capability prevents the buyer from assuming Okta is solving a problem it isn't claiming to solve. |
| "We have an MCP server for that" | "You have connectivity covered. What's the skill layer that governs when the agent uses it?" | Surfaces the judgment gap without making the buyer defensive. |
| "MCP is the integration standard" | "MCP is the wire protocol standard. Integration logic still lives in the server implementation; governance logic lives above the protocol." | "Integration standard" implies MCP solves more than it does. |
| "The agent is connected to Okta via MCP" | "The agent can discover and invoke Okta identity operations through Okta's MCP server. Whether it does — and when — depends on the skill layer." | Precise placement of what Okta's MCP server provides versus what the agent architecture provides. |
The field is in the middle of learning that MCP is infrastructure, not intelligence. That's not a criticism of the protocol — infrastructure that works is valuable, and MCP works. The confusion is in how it's been marketed: "connect everything" was an appealing pitch until teams discovered that a well-connected agent with no judgment layer is just a faster way to make the wrong API call. The architectures holding up in production separate the wire from the governance, use MCP for what it's good at, and build the skill layer with the same rigor they'd apply to any policy-bearing system.
When a buyer says "MCP-enabled," you now know what they've described. The question worth asking is what they've built above it.