Diagram showing model function calling producing a proposal, the host applying control, and MCP connecting to an external provider.
|

MCP vs Function Calling: What Actually Changes?

Function calling helps a model express a structured operation. MCP helps an application discover and communicate with external capability providers.

The two are frequently compared because both involve tools. They are not interchangeable. They sit on opposite sides of the host: function calling is part of the host-model interaction, while MCP is part of the host-server interaction.

TL;DR

  • Function calling is a model interface for producing structured tool requests.
  • MCP is a client-server protocol for discovering and invoking external providers.
  • The host translates between the two and remains responsible for authorization.
  • You can use function calling without MCP, MCP without model-controlled tools, or both together.
  • MCP adds a reusable provider boundary; it does not make model proposals trustworthy.

What function calling does

A host gives a model a set of tool or function definitions. Each definition describes a name, purpose, and input schema. Instead of answering only with prose, the model can return a structured request such as get_order_status({"order_id":"4812"}).

The model does not execute the function. The host receives the proposal, validates it, runs an implementation if allowed, and returns the result to the model. Provider APIs differ in message formats, tool-choice controls, result encoding, and lifecycle.

What MCP does

An MCP client connects to an MCP server and discovers the tools, resources, prompts, and capabilities that server exposes. The protocol defines common request, response, lifecycle, and transport behavior between compatible implementations.

MCP does not require the capability to be selected by a model. A user can choose a prompt, the application can read a resource, or deterministic host logic can call a tool. MCP standardizes the provider boundary, not the reasoning strategy.

The combined request flow

  1. The host’s MCP client discovers tools from an order server.
  2. The host filters them by user, tenant, task, and risk.
  3. The host converts selected definitions into its model provider’s function-calling format.
  4. The model proposes get_order_status with arguments.
  5. The host validates and authorizes the proposal.
  6. The host maps it to an MCP tools/call request.
  7. The server performs the work and returns structured content.
  8. The host converts that result into the model provider’s tool-result message.

The host is the bridge. If its mapping, authorization, or result handling is weak, neither MCP nor function calling repairs it automatically.

Side-by-side comparison

Dimension Function calling MCP
Boundary Host to model Host client to capability server
Main purpose Produce structured operation proposals Discover and communicate with providers
Execution owner The host or its integration code The MCP server behind an authorized client request
Discovery Definitions supplied by the host Definitions can be requested from servers
Portability Often provider-specific message format Shared protocol across compatible hosts and servers
Non-tool context Usually handled through model messages Resources and prompts are explicit primitives

Example without MCP

A small weather chatbot defines get_weather directly in its code. When the model proposes the function, the host calls one weather API. There is one application, one integration, and no need for runtime provider discovery. Function calling alone is sufficient.

Example without model function calling

A desktop research application lets the user select an MCP resource from a connected document server. The host reads that resource and attaches selected content to a deterministic report workflow. No model chooses a tool, yet MCP still provides a useful server connection and resource contract.

Example using both

An enterprise assistant connects to order, customer, and ticket servers. The host discovers their capabilities and exposes a small task-relevant subset to the model. Function calling gives the model a structured way to propose operations; MCP routes authorized calls to independently maintained providers.

What changes when MCP is added?

  • Tool definitions can come from reusable servers instead of being copied into each host.
  • Provider lifecycle and discovery use a common protocol.
  • Local and remote capability providers can follow related interaction patterns.
  • Resources and prompts join tools as first-class primitives.
  • The host gains more connections to govern, observe, and secure.

Security boundaries

Function-calling output is untrusted model output. MCP server descriptions and results are also untrusted external input unless the server is fully controlled and reviewed. The host must validate both sides, enforce least privilege, limit context, and ask for confirmation before consequential actions.

Do not let a model select an arbitrary server or forward credentials. Do not assume a valid schema means a safe operation. Schema validation answers “Is this shaped correctly?” Authorization answers “May this user do this now?”

Who owns what?

  • Model provider interface: structured proposal and tool-result message formats.
  • MCP server: capability contract, server-side validation, and downstream integration.
  • Host: tool exposure, argument validation, authorization, consent, routing, and audit history.
  • Backend service: domain rules, data integrity, and system-of-record behavior.

Keeping these responsibilities explicit prevents protocol mechanics from being mistaken for product policy or security.

Common mistakes

  • Saying the model directly calls an MCP server.
  • Treating a model-generated function request as authorization.
  • Assuming MCP removes provider-specific model formatting.
  • Adding MCP to a one-function integration with no reuse benefit.
  • Sending every discovered tool to the model at once.

My Take

Function calling and MCP are complementary when the host is treated as a real control plane. Function calling structures the model’s intent; MCP structures the provider connection. The host must make the final decision about whether those two sides are allowed to meet.

Knowledge check

  1. Which boundary does function calling standardize?
  2. Can MCP be useful when a model does not select tools?
  3. Where should authorization happen in the combined architecture?

Continue learning

Review Tool Use in AI Agents for the wider agent loop and MCP Security and Permissions for production controls.

Sources

Similar Posts