MCP vs Function Calling: How They Fit Together

MCP and function calling are not rivals. Function calling is how a model asks for a tool call. The Model Context Protocol (MCP) is how an application finds, connects to and runs tools that live outside it. They operate at different layers and are often used together. The real question is not which one to pick. It is whether you need a protocol between the model and your tools at all.

Gyrence

Give Agents Structured Web Tools

Gyrence exposes web search, page extraction, and site mapping through a hosted MCP endpoint, with typed responses that include failure cases.

Explore Gyrence

TL;DR

Function calling is a model-API feature. You send tool schemas with the request, the model returns a structured call, and your code executes it.
MCP is an open protocol. A server owns the tool schema and the execution, and clients discover tools at runtime.
Use plain function calling for a few tools inside one app. Use MCP when tools must be reused across hosts or change without a redeploy.
Most production agents use both: the model emits a function call, and the tool behind it is served over MCP.
MCP adds a trust boundary. Treat every server like third-party code.

What function calling actually does
What MCP adds
Side by side
When to choose which
Using both in one agent
Where MCP stops: security and governance
Our view
Try the web primitives over MCP
FAQ
Sources

What function calling actually does

Function calling (also called tool calling) is implemented directly through parameters such as tools in the model API request. The loop looks like this:

Your app sends the prompt plus a list of tool definitions (name, description, JSON Schema for inputs).
The model replies with a structured request: tool name and arguments.
Your code runs the function and sends the result back.
The model writes the final answer or asks for another call.

The model never executes anything. It only produces a well-formed request. Schema, execution, auth and retries are all yours. That is a feature when you have three tools and want full control, and a chore when you have thirty.

It is also model-specific. Each provider has its own request shape, so a tool set written for one API needs adapter code for another. For the runtime side of this loop, see our agent tool calling production checklist.

What MCP adds

MCP is a JSON-RPC 2.0 protocol that defines how AI hosts such as Claude, Cursor and VS Code talk to tool servers. Its architecture has three parts:

Hosts: the LLM application, such as a desktop assistant or an IDE.
Clients: connectors inside the host, one per server.
Servers: external services that provide tools, resources and prompts.

A tool on an MCP server has a name, a JSON Schema describing its inputs, and optional annotations such as read-only or destructive hints. Clients send a tools/list request to discover what exists, then tools/call to run one. The spec's tools page also defines a listChanged notification, so a server can tell clients its tool list moved.

MCP does not replace function calling. It does not dictate how an application uses the LLM or manages context. The host still hands the discovered tool schemas to the model through the model's own tool-calling interface.

Side by side

Criterion	Function calling	MCP
Layer	Model API feature	Application-layer protocol
Tool discovery	Manual: you hard-code definitions	Runtime: `tools/list`
Who executes	Your app, in process	The MCP server, often remote
Reuse across hosts	Rewrite per app or provider	One server, many hosts
Latency	One API round trip plus your code	Adds a hop to the server
Best for	Few, stable, app-specific tools	Shared, evolving tool catalogs

The discovery, integration and deployment split is the same one developer guidance uses: native discovery versus manual, native integration versus wrappers, and a remote service versus in-process code.

When to choose which

Stay with function calling when:

The tools are internal to one application.
The task is deterministic or needs high-volume system-to-system throughput. Guidance for those cases points to direct calls or plain REST.
You are on a latency-sensitive path. Function calling happens within a single API call, with no extra server hop.

Build or use an MCP server when:

Several hosts need the same tools (an IDE, a chat client, your own agent).
Tools should be discoverable at runtime rather than compiled in.
The integration is I/O-bound: web access, databases, SaaS APIs.

A common misreading is that MCP replaces REST. It usually wraps existing REST or GraphQL services: the server is the AI-facing boundary for discovery, auth and state, and the underlying service still moves the data.

Using both in one agent

The robust pattern is layered. The host connects to MCP servers and lists their tools. It passes those schemas to the model as function definitions. The model emits a function call, the host routes it through the MCP client, and the server runs it. Practitioners describe the two as complementary, with native function calling as the trigger and MCP as the connective tissue.

Flow from model function call to MCP server

There is also a bidirectional variant: an agent that is a client of its own tools and a server other agents can call.

Transport is getting simpler too. The 2026-07-28 specification removed the initialize handshake and the Mcp-Session-Id header, so MCP can scale statelessly over ordinary HTTP infrastructure. Check the spec version your client and server target before you deploy, because older implementations expect sessions.

Where MCP stops: security and governance

MCP gives you a standard door, not a lock. It has no built-in context encryption or mandatory tool-use integrity verification, so a server can become a channel for prompt injection if the host trusts whatever comes back. Treat MCP servers like untrusted third-party binaries: pin versions, scope credentials, and never let tool output act as instructions.

For enterprise needs, Google engineers note that MCP does not cover advanced observability, complex access control or deep API management. Those usually come from an API gateway layered on top. If you are formalizing policy for agents, a framework for AI agent governance is a reasonable starting reference. Our own MCP security checklist turns the spec requirements into tasks.

Where MCP stops: security and governance — overview diagram

Our view

We build a web data API, so we see this from the tool side. Web access is the clearest case where the protocol question matters. Search, fetch, extract and crawl are I/O-bound, shared across agents, and they fail in ways a model must understand.

That last point matters more than the transport. Whether a call arrives through function calling or MCP, the agent is only as reliable as the response it gets back. A tool that returns an empty string on a blocked page teaches the model to guess. So every Gyrence call returns a typed, discriminated-union response, failure cases included: blocked, empty, timed out, or succeeded. The agent can branch on status instead of hallucinating around a silent gap.

Our rule of thumb: if the tool is one function in one app, write the function. If you will use the same web tools from an IDE, a chat client and a custom agent, serve them over MCP and keep the schemas in one place. Either way, demand honest failure modes from the tool, and cap what it can spend.

— Glen

Try the web primitives over MCP

Gyrence exposes Search, Traverse, Fetch, Extract and Map through a hosted MCP endpoint, so any MCP client can use them without glue code. Start with connecting an AI agent to Gyrence, or follow the five-minute MCP server setup. Billing is credit-based with spending caps, and LLM extraction carries no separate charge. Plans on the pricing page run from Free through Standard at $75 per month, Growth at $299 per month and Scale at $549 per month, plus Pay-As-You-Go.

FAQ

What is the difference between tool calling and function calling?

In practice they mean the same thing. Providers moved from the term function calling to tool calling as the feature grew beyond single functions. Both describe the model returning a structured request that your code executes.

Does MCP replace function calling?

No. MCP standardizes how tools are discovered and run. The model still needs a tool-calling interface to decide to use them, so the host translates MCP tool schemas into function definitions.

How is MCP different from a REST API?

A REST API exposes resources to any HTTP client. An MCP server is an AI-facing layer, often wrapping a REST service, that adds runtime discovery, schemas and state handling for LLM hosts. Most MCP servers still call REST underneath.

What is the difference between an MCP host and an MCP server?

The host is the LLM application, such as an IDE or desktop assistant. It runs one client per server connection. The server is the external service that provides tools, resources and prompts.