A buyer is going to ask you, sometime in the next quarter, whether your solution "speaks MCP." If you're not sure what that means, this is the piece to read before that meeting.
What Function Calling Actually Is
When a language model generates a response, it normally produces text. Function calling is the mechanism that lets it produce something else: a structured request to invoke an external capability.
During inference, a model that has been provided with a set of function definitions (their names, parameters, and descriptions) can choose to emit a structured object instead of natural language. That object specifies which function to call and what arguments to pass. The model doesn't execute anything. It generates a token sequence that the calling application interprets as an invocation request. The application executes the actual function, captures the result, and injects that result back into the model's context. The model then continues generating with the new information available.
The model's role is to decide whether to call a function and what to pass. Everything after that decision happens outside the model entirely.
How It Works in Sequence
Say an agent is helping a contracting officer look up the status of a vendor's SAM.gov registration. The agent runtime has provided the model with a function definition: check_sam_registration(vendor_name: string, uei: string). The model, mid-reasoning, determines it needs current registration data. It emits a structured call — something like {"function": "check_sam_registration", "arguments": {"vendor_name": "Acme Federal LLC", "uei": "AB3K7..."}}. The runtime receives that, makes the actual API call to SAM.gov, gets a response, and returns it to the model as a new context entry. The model reads the result and continues.
From the user's perspective, the agent "looked up" the vendor. From the architecture's perspective, the model expressed intent, and the runtime acted on it.
From Text to Action
Before function calling, a model's knowledge was frozen at training time and its outputs were text. You could ask it to summarize a contract; you couldn't ask it to check whether a vendor's clearances were current. The gap between "generate prose about a topic" and "take action in a live system" was unbridgeable.
Function calling bridged it. Retrieval-augmented generation, code execution, calendar scheduling, CRM lookup, database queries — the entire current generation of AI applications runs on this mechanism. The agent loop your buyers are describing, where an AI system reasons, acts, observes, and reasons again, is only possible because the model can express structured intent rather than just generate prose. Function calling is the hinge.
Okta Concept Mapping: OAuth Scopes + Resource Server
The closest IDAM analogy is a resource server that exposes capabilities rather than data, with the model acting as a client that requests specific operations by name. The function definitions the model receives are like a scope manifest — here's what's available, here's what each thing does.
Where it breaks: OAuth has an authorization server that issues tokens with explicit scope grants, and the resource server validates those tokens against a defined trust anchor. Function calling has no equivalent enforcement point. The model decides which function to invoke based on its training and the prompt — there's no external policy engine in that decision loop by default. More precisely: the model can request any function it's been shown. Whether that request should be honored, by whom, on whose behalf, is a question the application layer has to answer. OAuth gives you primitives for that answer. Function calling assumes you've already built them.
MCP: When the Tooling Layer Gets a Standard
Every enterprise software vendor that wanted their product usable by AI agents faced the same problem: they needed to expose their capabilities as functions a model could call. For a while, every vendor solved this differently — custom schemas, proprietary SDKs, one-off integrations. The integration tax was real. An agent that worked with Salesforce didn't automatically work with ServiceNow.
Anthropic introduced the Model Context Protocol in late 2024 as a standard for this layer. By early 2026, it had achieved something unusual in AI tooling: genuine cross-vendor adoption. The Linux Foundation took stewardship of the specification. OpenAI, Microsoft, and Google all announced MCP support in their agent runtimes. Enterprise software vendors started shipping MCP servers alongside their REST APIs, the same way they once started shipping SAML metadata alongside their login pages.
MCP is a client-server protocol. An MCP server exposes three things: tools (functions the agent can invoke), resources (data the agent can read), and prompts (pre-built interaction templates). An MCP client — typically the agent runtime — connects to one or more MCP servers and makes their capabilities available to the model as function definitions. The model sees a unified tool list regardless of how many underlying systems are involved.
The value proposition is the same one SAML delivered for SSO: one standard, many implementations, dramatically lower integration overhead. If your enterprise software speaks MCP, any MCP-compatible agent can use it without a custom integration.
"Does It Speak MCP?" Is a Real Question Now
When a CAIO or a CTO asks whether a vendor's product speaks MCP, they're asking whether it ships an MCP server — whether its capabilities are exposed in a form that agent runtimes can discover and invoke without custom glue code. It's a procurement question the same way "does it support SAML?" became a procurement question once SAML adoption hit critical mass.
The follow-on question, which most buyers haven't gotten to yet, is the identity question: when an agent calls an MCP server, who is it acting as? The MCP specification supports authentication but doesn't mandate a specific mechanism, and the principal model — whether the agent is acting as itself, as the user who initiated the session, or as the application that deployed it — is something each organization is currently working out on their own.
That gap is where the conversation gets interesting. If a buyer mentions MCP and you ask "have you thought through the principal model for your MCP servers," you've demonstrated fluency and surfaced a problem they haven't solved. That's a better opening than explaining what MCP stands for.
Enterprise tools now ship MCP servers the way SaaS once shipped REST APIs. The identity infrastructure question underneath that shift is still being written.