Skip to content
    All posts

    AI

    MCP vs Function Calling: What's the Difference (and When to Use Each)

    Model Context Protocol and function calling both give LLMs access to tools, but solve different problems — a clear comparison and guidance on when to use each.

    By Published 4 min read

    Share

    Sign up for a free account to read this article in full.

    Sign up to unlockAlready enrolled?

    "MCP" and "function calling" get used almost interchangeably, and that causes real confusion when you're designing a system. They're related — but they operate at different layers. Function calling is how a model invokes a tool. MCP is how tools are exposed and shared across applications. Getting the distinction right changes how you architect your AI features.

    Quick definitions

    Function calling (a.k.a. tool calling) is a model capability: you describe some functions to the model, and when a user's request needs one, the model responds with a structured request to call it. Your code executes the function and feeds the result back. The tools live inside your application, in that provider's format.

    Model Context Protocol (MCP) is an open protocol that standardises how AI applications connect to tools and data. Tools live in an MCP server — a separate process — and any MCP-compatible client (Claude Desktop, an IDE assistant, your own agent) can discover and call them over a standard interface.

    The key difference

    Function calling is in-process and per-app: each application wires each tool in by hand, in each provider's schema. If three apps need the same "look up order status" tool, you implement it three times.

    MCP is out-of-process and reusable: you build one server that exposes "look up order status," and every MCP client can use it — no per-app rewiring, no provider-specific glue.

    Function calling versus MCP: where the tools liveApp A to Tools coded in App A; App B to Tools coded in App B; App A / IDE to One MCP server; App B to One MCP server; One MCP server to Your systemsFUNCTION CALLINGMODEL CONTEXT PROTOCOLApp AApp ATools coded in App ATools coded inApp AApp BApp BTools coded in App BTools coded inApp BApp A / IDE: Claude DesktopApp A / IDEClaude DesktopApp BApp BOne MCP serverOne MCP serverYour systemsYour systems

    Side by side

    Function calling MCP
    Where tools live Inside each app In a standalone server
    Reuse across apps Reimplement per app Build once, any client uses it
    Coupling Tight (app ↔ tool ↔ provider) Loose (client ↔ protocol ↔ server)
    Provider format Provider-specific schema Standardised by the protocol
    Transport In-process function call stdio / HTTP between client & server
    Discovery Hardcoded per app Client discovers server's tools at runtime
    Best for One app, a few bespoke tools Shared capabilities across many clients

    How they relate

    Here's the part that resolves the confusion: MCP is built on top of tool calling, not instead of it. Under the hood, an MCP client still uses the model's function-calling ability to decide which tool to invoke. MCP standardises the layer around that — how tools are described, discovered, and executed across process boundaries. So it's not "MCP or function calling"; it's "function calling alone, or function calling plus MCP for reuse and decoupling."

    When to use plain function calling

    • You have one application with a handful of tools specific to it.
    • The tools are simple and won't be reused elsewhere.
    • You want the least moving parts — no extra server to run.

    This is the right default for most single-app features. Don't add MCP just because it's new.

    When to use MCP

    • Multiple clients need the same tools (a web app, an internal agent, IDE assistants).
    • You want to decouple tool implementations from the apps that use them, so teams can evolve them independently.
    • You're building on an ecosystem of MCP clients and want your capabilities available to all of them.
    • You have existing services (especially in Java/enterprise) you want to expose to AI assistants once — see building an MCP server with Spring AI.

    A pragmatic hybrid

    Many real systems use both: bespoke, app-specific tools via plain function calling, plus shared enterprise capabilities (search, ticketing, data lookups) behind an MCP server that every internal AI client can reuse. Start with function calling; graduate a tool to MCP when a second consumer appears.

    FAQ

    Is MCP replacing function calling? No. MCP uses function calling underneath. It standardises how tools are shared across apps — it doesn't remove the model's tool-calling step.

    Do I need MCP for a single chatbot? Usually not. For one app with a few tools, plain function calling is simpler. Add MCP when tools need to be reused by other clients.

    Can I expose my existing Java services via MCP? Yes — with Spring AI you can wrap existing services as MCP tools. See building an MCP server with Spring AI.

    Is MCP tied to one provider? No — it's an open protocol with multiple client and server implementations across the ecosystem.

    Function calling is how a model uses a tool; MCP is how tools are shared across your organisation. Use function calling by default, and reach for MCP when reuse and decoupling justify the extra server.

    More: building enterprise AI agents, tool calling with Spring AI, and the MCP introduction.

    Designing an agent or MCP architecture and want it reviewed? Let's talk.

    Keep reading — it's free

    Model Context Protocol and function calling both give LLMs access to tools, but solve different problems — a clear comparison and guidance on when to use each.

    In the rest of this article

    • Side by side
    • How they relate
    • When to use plain function calling
    • When to use MCP
    • A pragmatic hybrid
    • FAQ

    A free account unlocks the rest of this article, the full prompt library, quiz answer reviews and completion certificates. The newsletter is optional.

    Sign upSign in

    Ask about this article

    Get answers grounded in this post. AI-generated — based on this article, and may be imperfect.

    Was this helpful?
    NewerBuilding an AI Gateway with Apigee (LLM Proxy)Older Building a RAG Chatbot with Spring AI and PGVector

    Read next

    Article

    Building AI Skills: GitHub Copilot Extensions, Claude Tools, and Reusable Agent Capabilities

    One skill, three platforms. Building a custom capability for GitHub Copilot, Claude, and your own AI agents — with real code and a decision framework.

    Article

    Building Enterprise AI Agents

    Architecture patterns and best practices for building production-grade AI agents that scale — from orchestration to observability.

    Article

    Building an MCP Server with Spring AI

    Most MCP content is Python/TypeScript. Here's how to build an MCP server in Java with Spring AI — expose your services as tools any MCP client can use.

    Scaled AI Weekly

    Enjoyed this? Get more like it every Monday.

    Real architecture decisions, LLMOps patterns that survive production, and engineering leadership advice — from 12+ years of building at enterprise scale. Free. No spam. Unsubscribe anytime.

    Get new articles by email

    Free. We email a confirmation link first, and you can unsubscribe from any email.

    Join engineers building production AI systems

    Free: LLM Production Readiness Checklist (PDF)

    50 checks across observability, rate limiting, cost optimization, failure handling, and security — for teams shipping AI features to production.

    No spam. Unsubscribe any time.

    Comments

    Back to all posts