If you’ve browsed agent engineering discussions recently, you’ve seen the same hype everywhere: MCP (Model Context Protocol) is the new standard for AI agents. Every new framework, model release and demo is rushing to add MCP server support. It promises a universal way for LLMs to discover and connect to APIs, databases, git, local files and SaaS services without writing custom function definitions for every single tool.
But as someone building production agent stacks, I think many teams are adopting MCP for the wrong reasons. MCP and traditional function calling solve different problems. Picking the wrong one adds unnecessary operational overhead, complexity, and failure modes.
What’s the core difference?
Traditional function calling (OpenAI function call / Anthropic tool use) is tightly coupled to your LLM prompt. You hand the model a static list of available functions, their JSON schemas, descriptions and parameters at the start of the prompt. The model picks from this fixed set and outputs structured JSON to invoke them.
This works great when:
- Your toolset is small and fixed
- The agent only needs 2–5 tools for a defined workflow
- Tool permissions and schemas rarely change
- You need low latency for simple automation tasks
The downside: every new tool requires you to manually update your system prompt and schema definitions. Adding dozens of tools bloats your context window. Cross-model portability is poor. Your function schemas are written for one provider’s tool parser and often break when switching LLMs.
MCP flips this model. Instead of baking all tool definitions into the prompt, MCP servers expose tools, resources and prompts dynamically. The agent can discover available tools at runtime, read their schemas, and invoke them via a standardized JSON-RPC interface. The model does not need all tool definitions loaded upfront.
MCP shines when:
- You have a large, growing ecosystem of tools
- You want to swap LLMs without rewriting all your tool definitions
- Multiple agents share the same set of backend services
- You need dynamic tool discovery at runtime, like browsing file systems or repositories
But MCP has real engineering costs most tutorials skip.
The hidden operational overhead of MCP
An MCP agent stack requires running and maintaining MCP servers alongside your LLM service. Every server needs deployment, health checks, authentication, permission controls, logging and failure handling.
For simple use cases like “call one REST API to fetch user data”, MCP is overkill. Function calling is lighter, simpler to debug, and easier to monitor. Adding an MCP layer here only adds extra moving parts, more points of failure and latency.
Another practical pain point: debugging. When a function call fails, you inspect the prompt, model output and API response directly. When an MCP agent fails, you need to trace across three layers: the LLM planner, the MCP client, and the remote MCP server. Troubleshooting becomes significantly slower, especially in production.
Decision framework for your agent stack
Here is the practical rule I use when designing agent workflows:
- Small fixed toolset (< 6 tools) → stick with native function calling. Keep your stack simple. No need to introduce MCP complexity.
- Dynamic, multi-tool environment with many services → MCP is worth considering. Especially when tools are added/removed frequently or reused by multiple agents.
- Low-latency, high-volume automation jobs → avoid MCP. The extra round trips and server orchestration add latency.
- Multi-agent systems with shared backend resources → MCP’s standardization pays off. Agents can reuse the same MCP servers for database access, file reading and external APIs.
The common mistake: Treating MCP as a magic fix
MCP standardizes the transport and discovery layer for tools. It does not improve the model’s reasoning, reduce hallucinations, or make the LLM better at choosing when to call a tool.
If your agent fails because the LLM picks the wrong tool or passes invalid parameters, switching from function calling to MCP will not fix that problem. MCP only changes how the agent invokes tools, not the model’s judgment. That’s a critical distinction lost in much of the marketing.
Closing thoughts
MCP is a meaningful step toward interoperable agent infrastructure, and it will become foundational for complex multi-tool agent systems. But it is not a universal upgrade to replace function calling everywhere.
Good agent engineering is about matching architecture to problem scope. Before adding MCP to your stack, ask yourself: do I need dynamic tool discovery and cross-model portability? If not, native function calling will remain simpler, cheaper and easier to maintain.
Top comments (0)