What Function Calling Is, Precisely
A language model, left to its own devices, can only do one thing: predict the next token given everything that came before it. Function calling is the mechanism that lets a model escape that constraint by signaling — in structured, machine-readable form — that it wants to invoke an external capability and receive the result.
The signal is not a natural language request. It's a structured output object: a tool name, a set of arguments conforming to a schema the developer registered in advance, and nothing else. The model doesn't execute anything. It produces a declaration of intent, and the runtime around it does the actual work.
The tool schema — name, description, parameter types, required fields — lives in the model's context window alongside the conversation. The model learns what tools are available the same way it learns anything else: by reading them. When it determines a tool is appropriate, it emits the structured call instead of prose. The runtime intercepts that output, executes the underlying function, and injects the result back into context as a new message. The model then continues from there, incorporating the result into whatever it generates next.
How the Mechanism Works in Practice
Consider a concrete sequence. A federal agency deploys an agent to help analysts query a document repository. The developer registers a tool called search_documents with parameters: query (string), classification_level (enum), date_range (object). That schema goes into the model's system context.
An analyst asks: "What guidance did CISA issue on zero trust architecture between 2023 and 2025?" The model recognizes this as a retrieval task, emits a structured call to search_documents with the appropriate arguments, and stops generating prose. The runtime executes the actual search against the repository, returns a JSON payload with matching documents. The model reads that payload as context and synthesizes a response.
Nothing in that loop required the model to know how the repository works. It only needed to know the tool's schema — what it accepts and what it returns. The implementation is invisible to the model.
MCP enters at the integration layer, and the reason it matters is a combinatorial problem. Before the Model Context Protocol, every model provider had a proprietary format for tool schemas and invocation. Anthropic's function calling spec looked different from OpenAI's, which looked different from whatever a fine-tuned open-source model expected. Tool vendors who wanted to be callable by agents had to implement separate integrations for each runtime. Ten model providers times fifty enterprise tools equals five hundred integration projects, each slightly different, none of them reusable.
MCP, published by Anthropic in late 2024 and now stewarded under the Linux Foundation's AI and Data Foundation, defines a standard wire protocol for this layer. A tool vendor ships an MCP server that exposes callable interfaces according to the spec. A model runtime ships an MCP client that speaks the same protocol. One integration, any compliant model. The REST API analogy is structural, not decorative: REST didn't simplify API construction so much as it made APIs composable across vendors who'd never coordinated. MCP is doing the same thing for the tool layer of the agent stack.
Enterprise software vendors have moved quickly. ServiceNow, Salesforce, and a growing list of federal-adjacent data platforms have shipped or announced MCP servers. The pattern is consolidating faster than most integration standards do, partly because the alternative — proprietary integrations per model — is visibly untenable.
Okta Concept Mapping
Function calling resembles OAuth 2.0 scopes in one useful way: both represent a declared, inspectable statement of what a principal intends to do before it does it. The model emits a tool call with specific arguments; the OAuth client requests specific scopes. Both create an auditable record of intent.
The analogy breaks at persistence. An OAuth client is a registered principal with a durable identity, and its scope grants survive across sessions. A model's tool invocation is ephemeral — it exists for one inference cycle, carries no identity the access control layer can natively recognize, and disappears when the context window closes. The model is not a principal. It's a process that produces structured outputs that something else acts on. Treating function calls as equivalent to OAuth-scoped requests will get you to a comfortable approximation that breaks the first time you try to audit who authorized what.
The Procurement Question
Enterprise tools now ship MCP servers the way SaaS once shipped REST APIs. A platform that doesn't expose an MCP interface requires custom integration work every time someone wants to connect it to an agent runtime. That's not a dealbreaker, but it's a cost, and it compounds as the agency's agent footprint grows.
"Does it speak MCP?" is a legitimate procurement question now — not a forward-looking aspiration, but a present-tense capability check. The answer tells you whether the tool is designed to participate in an agent ecosystem or whether it's treating that ecosystem as someone else's problem.
The model doesn't call anything. It declares intent. What happens next depends entirely on what the runtime is connected to, and whether those connections follow a standard anyone else can audit.