Logistics Route Optimization: Guide in 2026
April 29, 2025
- BLOG
MCP vs Function Calling: Understanding Two Ways AI Uses External Tools
Published: November 2, 2026
Table of Contents
If you are building an AI agent that needs to look things up, run calculations, or take action in the real world, you will hit the same question sooner or later: should you wire tools in with function calling, or use the Model Context Protocol?
The question is becoming more relevant as businesses move AI agents toward wider deployment. According to McKinsey’s 2026 State of AI report, 40% of respondents at organizations with more than $1 billion in annual revenue said their companies were scaling AI agents, up from 27% in 2025. As these systems take on more tasks, how they connect to external tools and services becomes an important architectural decision.
The MCP vs function calling debate is confusing because the two are often described as competitors, when they actually operate at different layers of the same stack.
This guide explains what each approach does, how they differ in architecture, reusability, security and maintenance, and when to choose one over the other. We also walk through a concrete example using location tools such as geocoding and routing, the kind of capability that NextBillion.ai exposes through its own MCP server.
The Short Answer: MCP vs Function Calling
Function calling is a model capability. You describe a set of functions to the model using a schema, and the model responds with a structured request to call one of them. Your application code then runs the function and returns the result.
The Model Context Protocol (MCP) is a connection standard. It defines how an AI application discovers and calls tools that live in an external server, so the same tool can be used by many different clients and models without being rewritten each time.
The most useful way to think about model context protocol vs function calling is this: function calling is how the model asks for a tool to be used, and MCP is how tools are packaged, discovered and delivered to the model. In most MCP setups, function calling is still happening under the hood. MCP sits one layer above it.
Aspects | Function calling | MCP |
What it is | A model feature for requesting tool execution | An open protocol for connecting AI apps to tools and data |
Where tools live | Inside your application code | In a separate MCP server |
Tool definitions | Written by you, per app and per provider | Published by the server and discovered at runtime |
Reuse across apps | Low; copy and adapt | High; connect any compatible client |
Provider portability | Schemas differ by model provider | Provider-agnostic at the protocol level |
Auth and secrets | Handled in each app | Can be centralized at the server |
Best for | Simple, single-app integrations and prototypes | Shared tools, multiple agents, multiple teams |
What Is Function Calling?
Function calling lets an AI model ask for a specific function or external tool to be run. The model doesn’t run anything itself. It names the tool it wants and the inputs to use, and your application does the actual work, whether that’s fetching data, running a calculation or calling an API.
Most major LLM APIs support it. You describe your tools with a schema, usually JSON, and send it along with the conversation. If the model decides a tool would help, it replies with the tool name and the arguments. Your code runs it and sends the result back.
OpenAI added function calling to its API on June 13, 2023. Anthropic made tool use generally available on May 30, 2024, and other providers have since added their own versions.
Example of Function Calling
Language models often get stuck on questions that need live data. A model knows where Belize City and Belmopan are, but it can’t tell you the current driving route or how long the trip takes. That informa
To answer, the agent needs a routing service. A developer can define a function like get_directions(origin, destination, mode) and connect it to a location API, such as NextBillion.ai’s Directions API.
Now a user asks how long it takes to drive from Belize City to Belmopan. The model asks for get_directions with those two places and a driving mode. The application takes those arguments, calls the routing API, and hands the route and estimated travel time back to the model. The model uses that to answer the question.
Where Does Function Calling Fall Short?
Function calling lets the model ask for a tool, but everything after the ask is the developer’s job. For each tool, you have to:
- Define the tool and its input schema
- Write the code that calls the API
- Manage API keys, authentication and permissions
- Handle errors, retries and rate limits
- Turn the API response into something the model can use
- Manage the back-and-forth between the model, the tool and the results
These tasks become harder to maintain when multiple applications need the same capabilities or when teams support several model providers.
The resulting challenges can include:
- Duplicated integration work: Different teams may build their own implementations of the same geocoding or routing functionality, even when they rely on the same API.
- Provider-specific adaptations: Tool definitions and calling conventions can differ across model providers, requiring additional compatibility work when supporting multiple platforms.
- Maintenance overhead: When an API or its supported parameters change, developers may need to update the relevant tool definitions and application code. Some implementations also require redeployment.
- Inconsistent tool selection: Models rely partly on tool descriptions and schemas to decide which functions to request. Poorly defined tools can lead to incorrect selections or arguments.
- Distributed security responsibilities: Each integration must handle credentials and permissions appropriately, increasing the number of places developers need to secure and maintain.
What Does It Mean for Teams Building Location Reasoning AI Agents?
Location-aware agents raise a practical question: how do you expose mapping capabilities without rebuilding the same integrations for every application?
A team might need geocoding to resolve what a user typed, a distance matrix to compare journeys, and directions to calculate routes. With plain function calling, developers choose which capabilities to expose, wire each function to an API endpoint, and maintain the code that handles requests and responses.
If the tools belong to one application, that works fine. But when several agents or AI clients need the same location capabilities, keeping separate integrations running is wasted effort.
MCP is built for that problem. An MCP server exposes its tools through a standard protocol, so each client doesn’t need its own custom connection to every external tool. Teams can reuse the same integration across compatible AI applications, within the limits of the server’s configuration, permissions and supported tools.
What Is MCP?
The Model Context Protocol (MCP) is an open standard that Anthropic introduced in November 2024. It gives AI applications a common way to connect to external tools and data sources. Instead of building a custom integration for each application, developers expose capabilities through an MCP server, and compatible clients connect to it.
A client can see which tools the server offers and use them through a standard interface, so an integration built once can be reused across compatible apps. What a client can actually do still depends on its own capabilities, the server’s configuration and the permissions it has been given.
Why MCP Exists: The M×N Problem
Without a shared protocol, connecting M applications to N tools needs up to M×N custom integrations. With five agents and ten tools, that is fifty point-to-point connections. With a shared protocol, each agent implements the client side once and each tool implements the server side once, so the work drops to roughly M+N, or fifteen in this example.
That reduction is the heart of the argument for MCP, and it is why tool vendors have started shipping their own MCP servers rather than leaving every customer to write their own wrappers.
Example of MCP
If we take the same example, the same question works differently when the routing tool is delivered through an MCP server. The language model still cannot reliably calculate the current driving route or travel time between Belize City and Belmopan on its own, so the agent needs a routing service.
Instead of defining the tool in application code, the developer connects the agent to an MCP server that already exposes it, such as NextBillion.ai’s MCP server, which provides location tools built on APIs like the Directions API. The server holds the tool definition, the execution logic and the API connection, and the developer only configures it with an API key. When the agent connects, it discovers the available tools at runtime, including their descriptions and input requirements.
When a user asks how long it takes to drive from Belize City to Belmopan, the model requests the routing tool with the appropriate locations and travel mode. The MCP client forwards the request to the server, which calls the routing API and returns the route details and estimated travel time. The agent uses that information to answer the user’s question. The developer wrote no handler for the API call, and any other compatible client can use the same tool without extra integration work.
What It Means for Teams Building Location Reasoning AI Agents
For a team building an agent on top of a location API, MCP moves most of the integration work to the server side.
The developer adds the MCP server to the client configuration with an API key, and the client discovers the available tools, along with their descriptions and input schemas, at runtime.
The team no longer has to map endpoints into tools, write schemas, build handlers for the API calls, or shape responses for the model, because the server already handles all of it.
Engineering effort goes into the agent itself: the prompts, the orchestration logic, and testing how reliably the model picks the right tool for real questions. A new agent or client reuses the same server without repeating the integration, and when the server adds or updates a tool, connected clients can see the change without a code rewrite.
MCP does not remove all of the work, though. Teams still have to decide which servers to trust, scope credentials and permissions, expose only the tools an agent needs so tool definitions don’t crowd the context window, and test the agent end to end.
What is the Difference Between Function Calling and MCP?
The MCP vs. function calling debate often comes down to one question: if both help AI agents work with external tools, why do we need both?
Think of it this way:
- Function calling is like a waiter taking your order. You ask for a burger, and the waiter writes down the details in a structured ticket, such as make_burger(meat=”beef”, cheese=true). The waiter doesn’t cook the burger. Similarly, the AI model generates a structured request to call a function. Your application then executes it, gets the result, and passes that result back to the model.
- MCP is like a standardized ordering system that connects the waiter to the kitchen. Instead of building a separate integration for every tool, an application can connect to an MCP server through a common protocol. It can discover which tools are available, understand what information they need, and request their use through a standardized interface.
This can make them seem like competing approaches, but they solve different problems and can work together. That’s why the most practical architecture would use both. Function calling can handle those application-specific tools that cannot be shared, and MCP can handle the shared infrastructure tools that multiple clients and agents can access.
For example, you are building an AI agent that helps an IT team respond to incidents. Now, it might need to pull incident details from PagerDuty for investigation and retrieve the relevant troubleshooting steps from the company’s internal runbooks.
Since other agents and applications could need the same information, exposing these capabilities through MCP servers would let them reuse the integrations rather than build their own.
The agent also needs to turn its findings into a Slack update that follows a particular team’s conventions or record execution details so developers can investigate a failure later. These tasks can stay within the agent’s application and be handled through ordinary function calling.
The difference comes down to reuse. When a capability needs to serve multiple applications, MCP offers a standardized way to make it available. When a function exists to support one agent’s specific workflow, keeping it inside the application may be simpler. The right choice depends on how the tool will be maintained, shared, and used, rather than on a strict rule that one approach is always better than the other.
A Worked Example: Location Tools With NextBillion
Location intelligence makes a good test case, because geocoding, directions and distance calculations are standard building blocks that many agents need. Consider a logistics assistant that has to answer, “Which of our three depots can reach this customer’s address fastest?
The function calling approach
With function calling, you would define tools such as geocode, directions and distance_matrix in your application. For each one you write the schema, write the handler that calls the location API, store the API key, handle errors and rate limits, and then repeat the schemas in the other format if you also support a second model provider.
For one agent, that is manageable. If a second team builds a dispatch bot, a third builds a customer-facing ETA assistant, and a fourth uses an AI coding tool to prototype routing logic, each of them repeats the work.
The MCP approach
NextBillion.ai launched an MCP server on September 9, 2025, to make AI agents location-aware. The server exposes tools for geocoding and reverse geocoding, place search and details, distance matrices, directions and navigation. A newer listing of the server also describes isochrones, static maps and a search-along-route tool.
With MCP, the tools are published once. Any MCP-compatible client can connect to the server, discover the tools and use them.
What’s Best: Function Calling or MCP?
Neither approach is wrong. If you are building a single prototype that only needs one geocoding call, function calling is simpler.
If location tools will be shared across agents, teams or model providers, an MCP server saves repeated work and gives you one place to manage keys and permissions.
This pattern also helps when several location providers exist, since an agent can connect to whichever server fits the job. For more on building with this pattern, see our guides on how AI agents use MCP and what you can build with MCP.
When to Use MCP vs Function Calling
Choosing between MCP and function calling depends on your application’s architecture, how your tools are managed, and how you expect your system to develop over time. Before settling on an approach, consider how much control your team needs over tool execution, whether integrations will be shared across applications, and the operational effort your team can support.
Choose Function Calling When:
- You are prototyping or validating an idea quickly.
- You have one agent, one model provider and a small number of tools.
- The tool is tightly bound to your app’s internal logic and will not be reused.
- You need maximum control over execution, validation and latency.
- Your team is small and a separate server adds operational overhead you do not need.
Choose MCP When:
- Two or more agents, products or teams need the same tools.
- You support multiple model providers or expect to switch.
- You want vendor-maintained integrations instead of writing wrappers yourself.
- You need centralized authentication, permissions and audit logging.
- Your tool set changes often, and clients should pick up updates automatically.
- You want your own API to be usable by AI assistants and IDEs you do not control.
Use Both When:
Most mature systems end up with a mix. Simple, app-specific logic stays as native functions, while shared and third-party capabilities arrive through MCP servers. Since MCP clients rely on function calling under the hood, the two coexist naturally in one agent.
The Bottom Line
The MCP vs function calling question is less a contest than a layering decision. Function calling is how a model asks for a tool. MCP is how tools are shared, discovered and delivered to many models and applications. If you have one agent and a few tools, function calling is simple and sufficient. If tools need to be reused across agents, teams or providers, MCP removes duplicated work and gives you a central place to manage access.
Start with the smallest approach that fits, and move shared tools behind MCP servers as your agent count grows. Location services are a clear example: once several agents need geocoding and routing, publishing those capabilities through an MCP server is easier to maintain than copying function definitions into every codebase.
Ready to go deeper? Read how AI agents use MCP, review the MCP security best practices, and explore what you can build with MCP.
Frequently Asked Questions
No. Function calling is a model capability for requesting tool use. MCP is a protocol for packaging, discovering and serving those tools. MCP clients typically use function calling underneath.
An MCP server usually wraps one or more existing APIs. The API still does the real work. MCP adds a layer designed for AI clients, with discovery, descriptions written for models, and a standard way to call them. Most production systems use both.
No. MCP sits above function calling. The model still expresses tool use through its native mechanism; MCP standardizes where tools come from and how they are executed.
It adds a hop, so a direct call can be marginally faster. In practice, model inference time usually dominates, and local servers add very little. Remote servers add network latency, so measure for your use case.
Use function calling for prototypes, single-agent apps, and tools that are specific to your application and will not be shared.
MCP provides a place to centralize authentication and logging, but it does not make tools safe by itself. Risks include malicious tool descriptions, prompt injection and excessive permissions. Vet servers and apply least privilege.
