Combining tools and functions transforms a language model into a versatile tool that can interact with databases, APIs, and messaging platforms. This landscape includes function calling, the Model Context Protocol, and the strategic decision-making process when building an agent.
Tool and function integration is the way an AI agent links to external sources like databases, APIs, files, and other services in order to take action, not just produce text. function calling model outputs a structured request for tool use, which is then executed by your application code to return a result. Model Context Protocol (MCP)Introduced by Anthropic in November 2024, the standardization of connections through MCP allows for building a tool integration only once, enabling any MCP-aware agent to utilize it. This eliminates the need for each application to maintain its own custom glue code. While function calling remains preferable for a few tools within a single application, MCP proves its value when managing numerous tools, providers, or teams that share the same integrations.
All tools connected to a model, no matter the framework or provider, consist of only three components: a name the model uses to pick it, a description that tells the model when to call it, and an input schema defining what arguments it needs.
The importance of a thorough tool description cannot be underestimated - a lackluster description can result in confusion and improper tool usage. It is crucial that tool descriptions are detailed and informative, akin to documentation for a novice engineer rather than a mere label.
Function calling, referred to as 'function calling' by OpenAI and as 'tool use' by Anthropic, operates in a similar manner across different providers. The process involves sending a message to the model along with a list of available tool schemas. The model then determines if a tool is required, creates a structured JSON object specifying the tool and its arguments, and the application code carries out the function and returns the outcome to the conversation.
The model always requests the tool but never runs it. Your code remains the sole point of execution, where validation and access control should be implemented.
Prior to the establishment of a common standard, linking an AI model to a tool required a tailored integration for each pairing, resulting in what was known as the 'N×M problem' in the industry. Having ten models and a hundred tools could lead to a thousand distinct connectors, each with their own schema peculiarities and maintenance obligations.
The problem of format fragmentation exacerbated the situation: OpenAI's tool-calling structure, Anthropic's tool-utilization format, and Gemini's function declarations all convey the same purpose through varying JSON formats, necessitating a complete rewrite of the integration layer when switching providers rather than just adjusting a configuration setting.
Frequently referred to as the 'USB-C for AI,' the MCP standardizes the process by which an agent discovers, connects, and invokes tools, regardless of the model making the request.
MCP acts as a middleman between the tool and the application, with the server containing the tool logic, schema, and security constraints. Any MCP-compliant client, such as an agent framework, IDE, or desktop app, can easily connect to the server at runtime without the need for custom pairing code.
Create a single MCP server that integrates with Slack or Salesforce, allowing all agents in an organization to use it. Make schema updates in one location for instant changes across all clients without the need for redeployment or syncing definitions across multiple codebases.
One common misunderstanding is that MCP serves as a replacement for function calling. In reality, function calling acts as the engine that allows a model to request a tool, while MCP serves as the universal transmission that links this engine to any set of tools without requiring a unique connection for each one.
The function embeds tool schemas within each request to the model, while MCP relocates the schema and execution logic to a separate server that the agent connects to via a standard transport, dynamically discovering available resources instead of relying on hardcoded application configurations.
| Dimension | Function calling | MCP |
|---|---|---|
| Where the schema lives | Inside your application code | On a shared server, discovered at runtime |
| Best for | 2–5 tools, single provider | 5–50+ tools, multi-provider |
| Cross-provider portability | Requires rewriting per provider | Same server works across providers |
| Upfront investment | Low : a schema and a handler | Higher : a server, a transport, a running process |
| Long-term maintenance | Grows linearly with tool count | Update once, every client benefits |
| Auth model | Credentials live in your application | Centralized : OAuth 2.1, gateway-managed |
The correct solution evolves with the project's development, starting from a simple prototype to a finalized product with established tools, and eventually expanding into an enterprise platform supporting multiple teams.
Implementing MCP infrastructure before determining the necessary tools is premature. It is essential to observe which tools are actually needed and prioritize function calling for faster progress. Analyze the usage of tools during this phase to inform the architecture moving forward.
Speed is essential, not infrastructure. Rapidly implement direct schemas and handlers to go from concept to functional integration in minutes.
With a reliable set of tools and endpoints under your control, this is the ideal starting point for setting up your first MCP server.
Centralize authentication, RBAC, and auditing behind an MCP Gateway to meet compliance requirements for multiple teams and providers.
Using a shared protocol may simplify adding tools, but it does not automatically ensure the safety of an agent's actions. Whether an agent is writing data, approving a transaction, or accessing a sensitive system, the same precautions must be taken regardless of whether it is connected through function calling or MCP.
When an agent is linked to multiple MCP servers, loading all tool definitions at the beginning leads to excessive context consumption, resulting in slower responses and higher costs before any tool is used. The solution being considered is on-demand loading: a. search_tools The agent's capability allows it to access only the necessary tool definitions for its current step, while code execution enables it to efficiently call multiple tools in a single composed step instead of making individual trips through the model.
Another important pattern to understand is that an agent, complete with its own set of tools, memory, and planning loop, can also function as a callable tool for a coordinator agent. This recursive structure allows for the creation of hierarchical, multi-agent systems where the coordinator can delegate tasks using the same tool-calling interface as for other functions.
Function calling and MCP are not in competition; rather, they are two distinct solutions addressing different issues on varying levels. Opt for function calling for quick performance with a limited toolset, and consider using MCP when managing numerous custom integrations becomes more cumbersome than establishing a shared infrastructure.
No matter what you decide, the protocol remains the same: provide concise tool descriptions, verify all input, and involve a human in any irreversible actions. You are still in control of determining what an agent can access.
Function calling is the process by which a model indicates its desire to utilize a tool. The MCP establishes a standard method for discovering, connecting to, and providing the tool to the model, serving as the transport and discovery layer without replacing the underlying capability. Numerous production systems employ both in conjunction.
If you only have a few tools - usually less than five - from one LLM provider within a single application, the initial cost of an MCP server and running process may not be justified until you have more tools, multiple providers, or multiple teams needing shared integrations.
Prior to a shared protocol, linking N various models to M different tools required creating and managing N*M individual integrations due to variations in function-calling formats. MCP simplifies this process by implementing the protocol once, allowing any MCP-compatible model or tool to connect seamlessly without a custom connector.
While MCP now includes OAuth 2.1 with PKCE for standardized authentication, it's important to note that simply implementing the protocol is not enough to ensure security. Production deployments should also include scoped permissions, input validation, human approval for irreversible actions, and, on a larger scale, a governance layer such as an MCP Gateway to centralize authentication, auditing, and access control across all connected servers.
Instead of loading all tool definitions at the beginning, agents can now search for and load only the necessary tool definitions for the current step. They can also utilize code execution to combine multiple tool calls into a single step, eliminating the need to repeatedly access the model. These approaches help minimize token cost and response time as the number of tools increases.
Indeed, this recursive pattern involves a complete agent with its own tools, memory, and planning loop being encapsulated within the same tool-calling interface utilized by a coordinator agent. This forms the foundation for hierarchical, multi-agent structures in which the coordinator assigns specific tasks to sub-agents.
Begin by using the most basic tools necessary to complete the task, determine whether to use function calling or MCP based on your current stage, and establish governance before expanding, rather than waiting until later.