Function Calling vs. MCP Tool Calling: What Nobody Tells You Before You Choose

From someone who's had to explain both approaches to a risk committee — and a compliance team — in the same week. \ I work on AI products for banking and insurance. That context matters for everything I'm about to say. \ When we started building AI-assisted workflows — loan pre-assessment, claims triage, policy document analysis — the function calling vs. MCP question came up fast. Not as an abstract technical debate, but as a very concrete "how are we going to answer the auditor when they ask how this decision was made?" kind of question. \ I've seen both approaches up close, in production, with real consequences. Here's what I actually think — including the parts that don't fit neatly into a comparison table. They're Not Really Competing — Until They Are Let's clear something up first: function calling and MCP are not two solutions to the same problem. They operate at different layers of your stack, and you can use both in the same architecture. \ Function calling is a mechanism. It's how you let an LLM request execution of a specific operation during inference. You define a JSON schema, the model emits a call when it decides it needs that function, your application intercepts it, and decides whether to actually run it. Crucial part: the model doesn't execute anything. You do. \ { "name": "get_customer_credit_score", "description": "Retrieves current credit score for a customer", "parameters": { "type": "object", "properties": { "customer_id": { "type": "string" }, "consent_verified": { "type": "boolean" } }, "required": ["customer_id", "consent_verified"] } } \ MCP (Model Context Protocol) is a protocol. Released by Anthropic in late 2024, it standardizes how AI hosts communicate with external tool servers. Tools live in dedicated, separate processes. Your host application discovers them dynamically at runtime and brokers the calls. The tool logic doesn't live in your main application at all. ┌─────────────────────────────────────┐ │ MCP Architecture │ │ │ │ ┌──────────┐ ┌──────────────┐ │ │ │ AI Host │◄────►│ MCP Client │ │ │ │ (Claude, │ └──────┬───────┘ │ │ │ app, etc)│ │ │ │ └──────────┘ ┌───────▼──────┐ │ │ │ MCP Server │ │ │ │ (tools, │ │ │ │ resources, │ │ │ │ prompts) │ │ │ └──────────────┘ │ └─────────────────────────────────────┘ \ They only end up in competition because both can be used to "give an LLM access to tools." Once you're building enterprise-grade workflows, the structural differences start to matter a lot. The Control Problem Nobody Warned Me About This took me months of production headaches to articulate clearly: MCP gives the LLM significantly more autonomy over tool execution. In a regulated environment, that's not a feature — it's a risk you need to consciously accept. \ With MCP, you connect the model to a server, and the model decides which tools to call, in what order, and how many times. MCP's architecture gives you solid post-facto observability — you can see exactly what happened. But you're not in the loop while it's happening. The agent reasons, decides, and acts. You watch. \ For a coding assistant or a research tool, that's exactly what you want. In banking and insurance, it's a different story. \ When an AI workflow touches a loan assessment, the sequence of operations is a compliance artifact — not just a technical detail. Did we verify customer consent before accessing personal data? Did we validate the input before hitting the core banking system? The order matters legally. And if a downstream call fails mid-transaction — say, an account was debited but a subsequent step errors out — who handles the rollback? Where does the compensating transaction logic live? \ 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. \ With MCP, you're trusting the model to reason correctly about sequencing and error states. Sometimes it does. "Sometimes" isn't a compliance posture. Where MCP Actually Wins I'm not arguing against MCP — we use it, and it solves real problems that function calling handles badly at scale. \ The maintenance economics are genuinely different once you have multiple AI applications across an organization. We have several products — different teams, different codebases — but many of them need access to the same core systems: customer records, policy data, transaction history. With function calling, each application owns its own integration logic. When a core API changes (and in banking, it changes), you update in multiple places. When you need to add rate limiting to protect a legacy system, you add it in multiple places. When a bug surfaces in the integration layer, you fix it in multiple places. \ Building one well-instrumented MCP server for each core system — and letting every application connect to it — is cleaner infrastructure. The connector has its own deployment lifecycle, its own test suite, and its own operational runbook. The data team owns the customer data server. The AI team builds workflows without needing to understand the database connection details. That's just good software design. \ MCP also buys you something important in terms of model optionality. Function calling schemas are fragmented across providers — OpenAI, Anthropic, and Google each do it differently. If you're deeply invested in one provider's format, switching models is painful. MCP is provider-agnostic by design. Your tool servers don't care which LLM is behind the host. The Technical Differences Worth Knowing Cut through the positioning, and the real architectural differences come down to a few things: Where logic lives. Function calling keeps execution logic inside your application — same process, same deployment. MCP pushes it to independent servers. Neither is inherently better; it depends on whether you want that logic co-located with your application or independently operated. \ Tool discovery. Function calling requires you to explicitly register every tool in every request. With 40 tools, you're either bloating your context window or writing complex routing logic to decide which tools to include per call. MCP discovers available tools dynamically at runtime — your application doesn't maintain a registry. \ State across calls. Function calling is stateless at the tool level. Any state persisting between calls lives in your application. MCP servers can maintain session state, which is useful for multi-step workflows where context needs to accumulate progressively. \ Security perimeter. In function calling, all tools run with your application's permissions. MCP servers run with minimal required permissions per server — a customer data server doesn't need access to payment systems. Smaller blast radius when something goes wrong. Six Questions to Ask Before You Decide The right answer almost always comes from your operational reality, not technical preference. \ How many applications will share these tools? One application — function calling is perfectly fine. Three or more applications needing the same Salesforce connector or the same legacy ERP integration — you're duplicating maintenance burden every time you add one. Build an MCP server once. \ Who builds the AI, and who owns the underlying systems? Same team end-to-end, function calling's coupling is manageable. Different teams — which is common in larger organizations — and you need a hard interface boundary. MCP provides that explicitly. Without it, you're coordinating through shared application code, which is slow and fragile. \ Does execution order matter for correctness? If changing the sequence of operations breaks business rules, legal compliance, or transaction integrity — keep orchestration control in your application layer. Function calling lets you do that. MCP delegates sequencing decisions to the model. \ Are your integrations single-use or shared infrastructure? A legacy ERP connector that only one AI workflow uses is a reasonable function. The same connector that five workflows depend on is infrastructure, and infrastructure deserves to be built and operated like infrastructure. \ What's your realistic tool count in 18 months? Most teams underestimate this. A pilot with 4 tools becomes a production system with 25. Each new tool in a function-calling architecture adds complexity to your application. Each new tool in MCP is just another server — your application stays thin. \ How much does model flexibility matter? If you want to evaluate or switch between providers without rewriting integration schemas, MCP protects you. If you're committed to one provider long-term, it matters less. A Framework for Deciding Choose function calling when: You're prototyping or validating whether the AI approach works at all. Optimize for iteration speed now, architecture later. \ You have a small, stable toolset that won't grow significantly. The operational overhead of MCP isn't justified for three functions that haven't changed in a year. \ Execution sequence, error handling, or transaction integrity is part of your correctness requirements. Keep control in your application layer. \ One team owns the full stack, and the toolset is application-specific. \ Choose MCP when: Multiple applications or agents need access to the same tools. The maintenance math changes as soon as you have more than one consumer. \ Different teams own the AI layer and the underlying systems. Let each team expose its capabilities via MCP and keep the interface boundary explicit. \ You're building shared internal infrastructure that other teams will build on top of. \ Security isolation between tool categories matters — especially in regulated environments where minimizing credential scope is a compliance requirement. \ You expect to evaluate or switch models over time and don't want your tool implementations coupled to a specific provider's schema. You'll Probably End Up Using Both 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 the execution sequence has legal or operational meaning, where rollback needs to be deterministic, where an auditor might ask "show me exactly what happened and why." They use MCP for shared enterprise infrastructure — the connectors to core systems that multiple teams and workflows depend on, where independent operability and centralized maintenance actually pay off. \ The migration path doesn't have to be disruptive either. If you've built function-calling integrations that are working, wrapping them in MCP servers incrementally is a reasonable path. You don't have to choose all at once. \ What I'd push back on is the framing that MCP is simply the more "modern" or "mature" 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. \ The teams that navigate this well are the ones who know which approach to reach for and why, rather than defaulting to whichever one they encountered first. Building AI systems in banking, insurance, or any environment where execution order and auditability matter? I'd genuinely like to hear how others are handling the control vs. autonomy tradeoff — leave a comment or reach out. \