What Function Calling Actually Is
When a model is configured with tools, the model provider exposes a structured way for the model to signal that it needs external action taken. At inference time, instead of generating a natural-language response, the model outputs a structured object — typically JSON — that names a specific tool and provides the arguments that tool requires. The model doesn't execute anything. It produces a request, formatted to a schema the runtime understands, and stops.
The runtime — the orchestration layer sitting between the model and the outside world — reads that structured output, validates it against the tool's schema, executes the actual call against the external system using whatever credentials the runtime holds, and returns the result back to the model as a new input. The model then continues generating, now with the tool result in its context. This loop can repeat: the model calls another tool, the runtime executes, results return, the model continues.
That loop is the entire mechanism. The model reasons about what to do. The runtime does it.
Take a concrete pass through: a user asks an agent to check whether a contractor's system authorization is current. The model outputs a structured tool call — check_ato_status, with arguments {"system_id": "GSS-114", "agency": "DHS"}. The runtime receives that, calls the relevant compliance API with its service account credentials, gets back a JSON payload indicating the ATO expires in 47 days, and injects that result into the model's context. The model reads the result and generates a response. The user sees plain English. Underneath, a structured request-execute-return cycle ran as many times as the task required.
Okta Concept Mapping
Closest IDAM analog: OAuth 2.0 delegation. The model resembles a client application requesting that an action be taken on its behalf; the runtime holds the credentials and executes against the resource server. The separation of "who requests" from "who executes" maps cleanly.
Where it breaks: In OAuth, the delegation chain starts with a human principal who grants consent — the client acts on behalf of an authenticated, identified user. In function calling, there's no human in the chain at inference time. The model issues tool calls autonomously, and the only identity the external system sees is the runtime's service account. The model itself has no identity the external system can verify. The authorization model IDAM practitioners expect — a chain of principals, each traceable — doesn't exist here. One service account, covering everything the model decided to do.
Where MCP Comes In
Until late 2024, every agent framework had its own tool-calling format. LangChain did it one way. OpenAI's function calling spec did it another. Anthropic's tool use had its own schema. If you wanted to connect an enterprise system to an agent, you wrote an integration for each framework you cared about — the same integration problem the industry spent a decade solving for REST APIs, replaying itself in a new layer.
The Model Context Protocol (MCP), introduced by Anthropic and now stewarded under the Linux Foundation, standardized this integration layer. MCP defines a client-server protocol: an MCP server exposes tools, resources, and prompts through a standard interface; an MCP client (the agent runtime) discovers and invokes those tools through the same standard interface regardless of which model or framework is underneath. The protocol handles tool discovery, invocation, result formatting, and error handling in a way that any compliant client can consume.
The REST API parallel is intentional and close. Before REST normalized HTTP-based APIs, enterprise integration was a bespoke negotiation — SOAP envelopes, WSDL contracts, proprietary SDKs for every vendor. REST gave vendors a common surface to build to and gave buyers a common expectation to procure against. MCP does the same thing for AI tool integration, one layer up the stack.
Enterprise software vendors noticed. Salesforce, ServiceNow, Atlassian, and GitHub have all shipped or announced MCP servers for their platforms. A vendor that previously shipped a REST API for programmatic access now ships an MCP server so that AI agents can discover and invoke that same functionality without custom integration work. Instead of building a connector for each framework, a vendor ships one MCP server and works with any compliant runtime.
What "Speaks MCP" Actually Means in a Procurement Conversation
When a CAIO or enterprise architect asks whether a tool "speaks MCP," they're asking a specific architectural question: does this tool expose an MCP server that a compliant agent runtime can discover and invoke without custom integration? Procurement teams learned to ask the same thing about REST APIs in the 2010s — not "can you integrate with us" (everyone says yes) but "do you speak the standard?"
A yes/no answer doesn't tell you much. More useful: which version of the MCP specification, and does the server support the full capability surface — tools, resources, and prompts — or just tool invocation? MCP is young enough that "we support MCP" can mean anything from a complete implementation to a thin wrapper around one endpoint. The spec is versioned; implementations vary.
For federal buyers specifically, MCP compliance is starting to appear in AI platform requirements the same way SAML support appeared in identity platform requirements fifteen years ago — first as a differentiator, then as table stakes. An agency building an agentic workflow that needs to reach into procurement systems, case management platforms, and document repositories doesn't want to maintain three custom integrations. They want MCP servers from each vendor and one compliant runtime that talks to all of them.
The question worth asking back: "Which systems in your environment would the agent need to reach, and do those vendors have MCP servers in production or on roadmap?" That surfaces the integration gap that's almost always present — because most enterprise environments have at least one critical system whose vendor hasn't shipped an MCP server yet, which is where the real procurement conversation begins.