Function Calling vs MCP

For years, developers integrated AI agents using function calling—a pattern where the model predicts a JSON schema and the developer executes the code. The Model Context Protocol (MCP) shifts this paradigm by decoupling the tool definition from the model and the client, creating a standardized interface for data and tool discovery.

The Core Difference

Function calling is a model capability. It is the ability of an LLM to output structured data (usually JSON) that matches a schema provided in the system prompt. The execution logic resides entirely within the application code. If you switch from OpenAI to Anthropic, you often have to rewrite your tool definitions to match a different API schema.

MCP (Model Context Protocol) is a transport standard. It defines how a client (like an AI agent) communicates with a server (a tool provider) over stdio or HTTP. Instead of the developer hard-coding functions into every API call, the agent queries an MCP server to discover what tools are available and how to use them. This makes tools portable across different models and agents.

Function Calling: The Legacy Approach

In a standard function calling workflow, the sequence is as follows:

1. The developer defines a JSON schema for a function (e.g., get_weather).
2. The schema is sent to the LLM with every request.
3. The LLM returns a tool_use call.
4. The application parses the JSON, executes the local function, and sends the result back to the LLM.

This approach works for simple scripts but fails at scale. It creates tight coupling between the model's expected format and the backend implementation. When using tools like Aider or Continue, you often see this pattern where the extension manages a specific set of hard-coded capabilities for the current model.

MCP: The Decoupled Future

MCP introduces a server-client architecture. An MCP server can be a small binary or a Node.js script that exposes a set of resources, prompts, and tools. The agent client connects to this server and asks, "What can you do?"

Key advantages of MCP include:

• Interoperability: A single MCP server for a Postgres database can be used by any MCP-compliant agent, regardless of whether the underlying model is Claude 3.5, GPT-4o, or a local Llama 3 instance via Ollama.
• Dynamic Discovery: Tools are not hard-coded into the prompt. They are discovered at runtime, reducing token overhead for large toolsets.
• Standardized Transport: By using stdio or HTTP, MCP allows tools to run in isolated environments, separate from the main agent process.

For developers building sovereign agents, this means you no longer need to write glue code for every new model provider. You write an MCP server once, and any compatible client can utilize it.

Comparison Matrix

The following table summarizes the technical trade-offs:

Feature | Function Calling | MCP
--------------------------------------------------
Definition | Model-specific / API-driven | Protocol-based / Server-driven
Coupling | Tight (Model <-> Code) | Loose (Client <-> Server)
Discovery | Static (Sent in prompt) | Dynamic (Queryable)
Portability | Low (Requires rewrite per API) | High (Universal standard)
Transport | REST API request/response | stdio / HTTP / SSE

Where it Fits in the Ecosystem

Most modern AI IDEs and agents are transitioning. Cursor and Windsurf have integrated deep tool-use, but the industry is moving toward the MCP standard to avoid vendor lock-in. While GitHub Copilot and Tabnine rely heavily on proprietary internal function calling, the open-source community is coalescing around MCP to enable a plug-and-play ecosystem of tools.

AZMX AI implements MCP over both stdio and HTTP. This allows users to connect local scripts or remote enterprise services without modifying the core binary. Because AZMX AI is a native Rust app rather than an Electron wrapper, it handles the stdio overhead of multiple MCP servers with significantly lower latency and memory consumption than web-based agents.

Implementation Considerations

If you are deciding which to use for a new project in 2026, consider your scale:

• Use Function Calling if you are building a single-purpose bot using one specific model provider and have fewer than five tools. It is faster to prototype.
• Use MCP if you are building a professional agentic workflow, using multiple models (BYOK), or want to share your tools across different clients.

When implementing MCP, focus on the server's stability. Since the agent relies on dynamic discovery, a crashing MCP server can lead to "hallucinated" tool calls where the model attempts to use a tool that is no longer available in the current session.

Security Implications

Function calling is inherently more controlled because the developer explicitly defines what the model can request. MCP, by design, allows for more dynamic capabilities, which increases the attack surface. This is why approval gates are critical. An agent with MCP access to a shell can theoretically execute any command if the MCP server provides a run_command tool.

To mitigate this, we implement a strict deny-list in AZMX AI that refuses access to .env, .ssh, and other credential files by default, regardless of what the MCP server claims it can access. You can review our approach to agent permissions at /security.

Conclusion

Function calling was the necessary first step, but MCP is the architectural correction. By moving tool definitions out of the prompt and into a standardized protocol, we move closer to a world where AI agents are truly modular. For those seeking a lightweight, non-telemetry client to run these protocols, the AZMX AI download provides a native environment that supports the full MCP spec without the bloat of a browser engine.