MCP vs Function Calling: Protocol and Runtime Roles

Function calling and MCP can appear in the same agent trace, but they describe different relationships. A model returns a structured request for an application function. An MCP host maintains client connections to servers that advertise tools and resources, plus prompts. The application may expose an MCP-discovered tool to the model through function calling, then execute the resulting request through MCP.

I treat them as adjacent layers. That framing produces cleaner authorization decisions than forcing a winner between two mechanisms that often compose.

TL;DR

• Function calling is a model API pattern: the application supplies tool definitions, the model requests one, and application code executes it.
• MCP is a JSON-RPC client-host-server protocol with capability negotiation, discovery and sessions, plus standard transports.
• MCP can supply tools that an application presents through a model's function-calling interface.
• Authorize model selection and MCP execution separately. DeepInspect covers the routed HTTP LLM call, not the MCP action itself.

Function calling is part of the model conversation

OpenAI's function-calling guide defines a function as a tool described with JSON Schema. The application sends available definitions with a model request. The model may return a tool call containing a function name and arguments. Application code parses that output, executes the function, and sends the tool result back for another model response.

The official flow begins when the application sends definitions and receives a structured request. Application code performs the requested operation, returns its output, and asks the model for a final answer or another call. The model proposes an action through structured output. The application retains execution authority.

That division gives developers direct control over a small, known tool set. A service with three internal functions can define them near the model call and keep orchestration inside its application code. The schema travels with the request, so its content and size become part of the inference payload.

MCP is part of the host-server relationship

The MCP architecture specification defines a client-host-server design built on JSON-RPC. A host creates clients, controls connection permissions, handles authorization decisions, and coordinates model integration. Each client maintains an isolated one-to-one server connection. Servers expose focused capabilities.

MCP adds protocol behavior around those capabilities. Clients and servers negotiate features during initialization. A server can expose tools and resources, plus prompts. A host can connect to several servers while keeping each connection isolated. The protocol also supports notifications and stateful sessions.

The visual difference fits on a whiteboard. Function calling is an arrow between application and model. MCP adds another arrow between host and tool server, with a session and capability exchange before invocation. Combining those arrows into "the agent called a tool" erases who approved each transition.

Discovery separates MCP from a fixed function list

A function-calling request commonly includes function definitions chosen by application code. That set may be static or generated, with selection completed before the model call. The model sees what the application places in that request.

MCP defines discovery at the host-server boundary. The official MCP tools specification uses tools/list to retrieve available tools and tools/call to invoke one. Servers can announce that the list changed, allowing clients to refresh capabilities during a session.

Dynamic discovery helps a host integrate servers without embedding every tool contract into its own source tree. It also creates a trust decision. Tool names and descriptions, plus schemas and annotations, come from a server and can influence later model selection. The MCP specification tells clients to treat tool annotations as untrusted unless the server is trusted. The MCP security versus API security guide examines that boundary in detail.

Execution remains application or server code

Neither mechanism turns a model-generated argument into a safe action by itself. Under function calling, application code receives the model's requested name and arguments. Under MCP, the client sends a JSON-RPC tools/call message to a server. The receiving component performs the work.

The authorization check belongs immediately before the action. Validate the principal, delegated scope, selected tool, arguments, target resource, and current policy. A JSON Schema can constrain shape and types. Business authorization still has to decide that this caller may refund this order or read this repository, and whether it may query this customer record.

My unfashionable opinion is that a confirmation dialog is often a receipt masquerading as a control. A user staring at a modal that says "Run update_record" lacks the policy context needed to assess the arguments. High-impact actions need server-side authorization even when the UI also asks for consent.

Transport changes the available control points

Function calling travels inside the model provider's request and response format. The application then executes the selected function through whatever local or remote mechanism its design uses.

MCP standardizes stdio and Streamable HTTP transports. The MCP transport specification describes stdio as a client launching a server subprocess and exchanging newline-delimited JSON-RPC through standard input and output. Streamable HTTP uses a single endpoint for POST and GET, with optional server-sent events. It also calls for origin validation and authentication, plus localhost binding for local servers.

These paths need different controls. Host controls cover a local stdio process. An MCP-aware policy point can govern remote tools/call messages. The LLM request needs its own identity and content policy. The MCP versus A2A comparison applies the same boundary discipline to remote agent delegation.

Audit records need two decisions

A composed workflow should preserve at least two linked records. The LLM record shows the authenticated caller context, model route, tool definitions exposed, policy version, and the model's returned tool call. The MCP record shows the host, server, negotiated capability, requested tool, arguments, authorization result, execution outcome, and returned content.

One correlation identifier can join them. The correlation key should never collapse them into one event. The model can request a legitimate tool with disallowed arguments, or the MCP server can return content that changes the next model request. Those are separate events with different owners.

The MCP policy enforcement guide goes deeper on tool-boundary controls. For function calling, record the exact schema version as well. A changed description or required field can alter model behavior even when the function name stays constant.

Selection follows the integration boundary

Choose direct function calling when one application owns a compact tool set and already controls discovery and execution, plus lifecycle. It keeps the integration close to the model request and avoids introducing a server protocol for a local concern.

Choose MCP when a host needs a standard connection to independently developed servers, runtime capability discovery, resources, prompts, notifications, or reusable sessions. The protocol gives different clients a shared contract for those interactions.

Use both when MCP supplies capabilities and the model provider uses function calling to request one. Keep authorization at the MCP execution boundary and treat the model output as a request. This composition is common enough that architecture reviews should draw both arrows by default.

DeepInspect

DeepInspect governs authenticated HTTP traffic between a user or agent and an LLM when that traffic is deliberately routed through its proxy. It can evaluate supplied identity context, classify the model request, enforce route and data policy, inspect the response carrying a function call, and write a per-decision audit record.

DeepInspect leaves MCP discovery, local stdio, remote tools/call authorization, and tool execution to MCP-aware host and server controls. If a remote MCP server later makes its own routed HTTP request to an LLM, that separate model call can cross the DeepInspect boundary and receive its own decision record.

The right architecture links the model record to the MCP execution record without pretending one control owns both transitions. Book a demo today.