I've spent months explaining to a risk committee and a compliance team why an LLM decided to call get_customer_credit_score before verifying consent. That conversation alone tells you more about the function calling vs. MCP tradeoff than any architecture diagram.
The Control Problem No One Warns You About
Function calling and MCP (Model Context Protocol, released by Anthropic in late 2024) are not two solutions to the same problem. Function calling is a mechanism: you define a JSON schema, the model emits a call, and your application intercepts it and decides whether to actually run it. The model never executes anything - you do. MCP is a protocol: tools live in separate processes, the host discovers them dynamically, and the model reasons, decides, and acts while you watch.
With MCP, the LLM decides which tools to call, in what order, and how many times. For a coding assistant, that's a feature. For a loan pre-assessment workflow, it's a compliance time bomb. When an AI workflow touches a loan assessment, the sequence of operations is a compliance artifact - not a technical detail. Did we verify customer consent before accessing personal data? Did we validate input before hitting the core banking system? The order matters legally. If a downstream call fails mid-transaction, who handles the rollback? With MCP, you're trusting the model to reason correctly about sequencing and error states. "Sometimes" isn't a compliance posture.
With function calling, your application layer sits between the model's intent and actual execution. The model says, "I think we should call get_credit_score now." Your application decides: has consent been verified? Is this the right stage of the workflow? Should this call happen at all right now? If something fails, you have explicit error handling in code you fully control, test, and can explain to an auditor.
Where MCP Actually Saves Your Sanity
I'm not anti-MCP - we use it. The maintenance economics flip once you have multiple AI applications across an organization. With function calling, each application owns its own integration logic. When a core API changes, you update in multiple places. When you need to add rate limiting, you add it in multiple places. When a bug surfaces, you fix it in multiple places.
Building one well-instrumented MCP server for each core system - customer records, policy data, transaction history - and letting every application connect to it is cleaner infrastructure. The connector has its own deployment lifecycle, test suite, and runbook. The data team owns the customer data server. The AI team builds workflows without needing to understand the database connection details.
MCP also buys you model optionality. Function calling schemas are fragmented across providers - OpenAI, Anthropic, and Google each do it differently. MCP is provider-agnostic by design. Your tool servers don't care which LLM is behind the host.
Six Questions That Decide Your Architecture
The teams doing this well don't treat it as a binary choice. They use function calling for application-specific workflows where orchestration logic is tightly coupled to business rules - places where execution sequence has legal or operational meaning, where rollback needs to be deterministic. They use MCP for shared enterprise infrastructure - connectors to core systems that multiple teams and workflows depend on, where independent operability and centralized maintenance actually pay off.
How many applications will share these tools? One application - function calling is fine. Three or more needing the same Salesforce connector - build an MCP server once. Who builds the AI, and who owns the underlying systems? Different teams need a hard interface boundary - MCP provides that explicitly. Does execution order matter for correctness? If changing the sequence breaks business rules, keep orchestration control in your application layer. What's your realistic tool count in 18 months? A pilot with 4 tools becomes a production system with 25. Each new tool in function calling adds complexity to your application; each new tool in MCP is just another server.
Migration doesn't have to be disruptive. If you've built function-calling integrations that work, wrapping them in MCP servers incrementally is a reasonable path. What I'd push back on is the framing that MCP is simply the more "modern" approach and function calling is legacy. MCP's model autonomy is genuinely the right design for many contexts. For mission-critical workflows in regulated industries, keeping your application layer in control of execution isn't conservatism - it's accountability.
Source: Function Calling vs. MCP Tool Calling: What Nobody Tells You Before You Choose
Domain: hackernoon.com
Comments load interactively on the live page.