Function Calling vs Tool Calling vs MCP: What AI Agents Need to Understand
A layered architecture guide for AI agents — explaining execution, abstraction, and protocol systems, and how QVeris connects them through capability routing.
Execution · Abstraction · Protocol · Routing
What is Function Calling?
Function Calling is a model-level execution mechanism where the LLM outputs structured JSON arguments instead of natural language text. It answers: "What function should I call and with what parameters?" — defining how the model communicates its intent to invoke a specific function.
Function calling is provided directly by the model API. OpenAI, Anthropic, and Google all implement it — the model receives a list of available function definitions and can respond with a structured JSON object naming the function and providing parsed arguments. The model does not execute the function. It outputs which function to call and what parameters to use. The developer's code is responsible for actually running the function.
Scope: Single call. The model decides to call get_stock_price(symbol="AAPL") and outputs {"name":"get_stock_price","arguments":{"symbol":"AAPL"}}. That is function calling. It does not select between multiple stock price APIs, manage API keys, handle retries, or validate schemas — those are higher-layer concerns.
What is Tool Calling?
Tool Calling is an agent-level abstraction layer that handles tool selection, tool invocation, multi-tool coordination, and execution flow. It answers: "Which tool should the agent use for this task?" — operating one layer above function calling.
Tool calling sits between the LLM and the actual tool implementation. When an agent has access to 10 different market data tools, tool calling determines which one to invoke — not just the function name and parameters, but which provider, which API, and which execution path. It manages the lifecycle: select → execute → validate → retry → fallback.
Scope: Multi-tool. Tool calling orchestrates across multiple tools, providers, and execution attempts. It is the layer that prevents an agent from calling the wrong tool just because its name sounds right.
What is MCP?
MCP (Model Context Protocol) is a standardized tool protocol layer. It defines how tools are described, exposed, and connected to AI models and agents — tool schema format, server definition, capability metadata, and execution interface. It answers: "How are tools exposed to AI agents?"
MCP, created by Anthropic, provides a common specification for MCP servers to declare their available tools, resources, and prompts. An MCP server publishes a manifest that any MCP-compatible client can read. This standardization makes tool connectivity predictable — instead of every tool having a custom integration format, MCP-compliant tools share a common language.
Scope: Ecosystem. MCP standardizes tool exposure across the industry. It does not select which tool to use, manage retries, or route across providers. MCP makes tools easier to connect. Higher layers make them easier to select and execute reliably.
Layered Architecture Model
Layer 1 Function Calling — Execution
The model outputs structured JSON naming a function and its parameters. Answers: "What function should I call and with what arguments?" Operates at the model level. Provided by OpenAI, Anthropic, Google.
Layer 2 Tool Calling — Abstraction
The agent layer handles tool selection, invocation, multi-tool coordination, retries, and execution flow. Answers: "Which tool should the agent use for this task?" Operates at the agent level.
Layer 3 MCP — Protocol
A standardized specification for how tools are described, exposed, and connected. Answers: "How are tools exposed to AI agents?" Operates at the ecosystem level. Created by Anthropic.
Layer 4 QVeris — Routing
A capability routing layer that helps agents discover tools by task intent, inspect schemas before calling, and route across multiple providers. Answers: "Which capability is best for this task?" Operates across the stack.
Key Differences Table
| Concept | Level | Purpose | Key Question | Scope |
|---|---|---|---|---|
| Function Calling | Model | Structured execution format | How does the model call a function? | Single call |
| Tool Calling | Agent | Tool selection & execution | Which tool should the agent use? | Multi-tool |
| MCP | Protocol | Tool standardization | How are tools exposed? | Ecosystem |
| QVeris Routing | Routing | Capability selection across providers | Which capability is best? | Cross-tool intelligence |
Why All Layers Are Needed
AI agents fail when layers are collapsed into one. Each layer solves a distinct problem that the layer below cannot address:
Function Calling Alone
Cannot choose between tools. The model can output get_price("AAPL") but cannot decide which of 10 price APIs to use, which has the right schema, or which is currently available.
Tool Calling Alone
Without MCP, every tool has a custom integration format. Without a routing layer, tool selection is hardcoded and brittle — change one provider and the agent breaks.
MCP Alone
Standardizes connectivity but does not select tools, manage retries, handle fallback, or route by task intent. MCP answers "what tools exist?" — not "which tool should I use?"
No Routing Layer
Without QVeris or equivalent routing, agents hardcode provider dependencies. When a provider changes its API, introduces rate limiting, or goes down, the agent has no recovery path.
Execution Flow in Real AI Systems
MCP vs Tool Calling in Practice
| Dimension | MCP | Tool Calling | Function Calling |
|---|---|---|---|
| Defines | Tool exposure format | Tool execution logic | Model output format |
| Answers | How are tools described? | Which tool to use? | How to invoke a function? |
| Operates at | Protocol/ecosystem level | Agent level | Model level |
| Standardized by | Anthropic MCP spec | Agent framework | Model API (OpenAI, Anthropic, Google) |
| Handles selection? | No | Yes | No |
| Handles fallback? | No | Yes (with routing) | No |
Common Misconceptions
✔ Reality: MCP standardizes tool exposure. Tool routing (function calling + tool calling + QVeris) handles selection, execution, and fallback. Different layers.
✔ Reality: Function calling outputs which function to invoke with what parameters. It does not select between 10 different providers offering the same capability. That is tool calling and routing.
✔ Reality: Tool calling is execution logic. MCP is a protocol specification. Execution and standardization are separate concerns.
✔ Reality: Production AI agents need all four layers. Collapsing layers creates fragile systems that work in demos but fail under real conditions.
QVeris Capability Routing Layer
QVeris operates as a capability routing layer above MCP and tool calling systems. It does not replace function calling, tool calling, or MCP — it provides the routing intelligence that connects them into a production-grade agent architecture.
Discover
Find relevant tools across MCP servers, external APIs, and capability catalogs — by task intent, not by hardcoded tool name.
Inspect
Validate schemas, check auth, review cost and latency, read provider notes — before calling. Catch mismatches early.
Call & Route
Execute selected tool safely. On failure, route to ranked fallback. Never return "I couldn't complete the task" while fallbacks remain.
Validate & Report
Check output structure, timestamps, source metadata. Return structured result with full traceability across all four layers.
QVeris is a capability routing layer. It does not replace function calling, tool calling, or MCP. It provides the routing intelligence on top — helping agents discover, inspect, and route across tools and MCP systems. Read the docs → or view pricing →.
Production Architecture Pattern
Getting Started Checklist
Build Production AI Agent Systems with Clear Architecture
QVeris provides the capability routing layer that connects function calling, tool calling, and MCP into a production-grade agent architecture. Discover and Inspect are free forever.
Build AI Agent Systems →Explore QVeris Docs