is
All posts
MCPMCPfunction callingengineering

MCP vs function calling: when to switch (and when not to)

Function calling is the in-app pattern of declaring tools inside a single LLM SDK conversation; MCP (Model Context Protocol) is the cross-app pattern of running tools as a separate JSON-RPC service that any MCP-aware client (Claude Desktop, Code, SDKs, agents) can discover and call.

inite2 min read

Use function calling when you have a single SDK app, your tools are simple, and you control both client and server. Use MCP when you want the same toolchain to work across Claude Desktop, Claude Code, agents, and CI without rewriting the integration; when tools have side effects you want centralised; or when you're building a product whose users will plug it into their own LLM client. The decision tree is 90% client-count: 1 client = function calling, 2+ = MCP.

Key facts

  • Function calling shipped in OpenAI's API in June 2023; Anthropic added it in May 2024.
  • MCP shipped to general availability in Claude Desktop in November 2024.
  • Pre-built MCP servers for filesystem, GitHub, Slack, Postgres, and 50+ surfaces (April 2026).
  • Migrating an SDK app to MCP averages 80-200 LOC for a 5-tool surface (real-world ports we measured).

Function calling and MCP solve the same root problem (let LLMs call your code) at different scopes. Picking the wrong one costs you weeks; picking the right one is mostly a matter of counting clients.

The simple rule

One LLM client → function calling. Two or more clients → MCP.

That's 90% of the decision. The remaining 10% is edge cases.

Where function calling still wins

Three scenarios:

  1. Single-app SDK builds. You're shipping a chatbot inside a Next.js app. The tools live next to the route handlers. The user never sees the LLM directly — they talk to your UI. MCP adds setup overhead without payoff.
  2. Tools with sub-millisecond latency requirements. Function calling is in-process. MCP adds JSON-RPC overhead — usually invisible, but if you're optimising for tail latency on token-streaming, in-process wins.
  3. Tools tightly coupled to your auth/session. If the tool needs the user's logged-in session to do anything, MCP makes the auth handoff awkward. Function calling stays inside the request context.

Where MCP wins

Five scenarios, in order of how much they lean on MCP's strengths:

  1. You want the same tool from multiple clients. Claude Desktop, Claude Code, the SDK, a CI script, a teammate's agent — all hit the same MCP server. Write once, plug everywhere.
  2. The user picks the LLM client. You ship a product (like ideaudit). Users have Claude Desktop, Claude Code, or some other MCP-aware client. MCP is how you reach all of them.
  3. You want centralised auditing of tool calls. MCP servers can log every call in one place. Function calling scatters logs across each consuming app.
  4. Tools have side effects on shared infra. Database writes, API rate limits, billing meters. Centralising those in an MCP server gives you one chokepoint instead of N.
  5. You want pre-built tools. Filesystem, GitHub, Slack, Postgres — the MCP ecosystem ships dozens. Function calling means re-writing each integration per app.

Migration pattern

If you have an existing SDK app and want to expose its tools to Claude Desktop too:

  1. Pull tool definitions out of the SDK call into a stand-alone module.
  2. Wrap that module in an MCP server (TypeScript or Python — boilerplate is ~50 LOC).
  3. Keep the SDK app calling the same module locally for in-app tools.
  4. Register the MCP server in Claude Desktop config.

The same code now serves both clients. Migration cost in real ports we measured: 80-200 LOC for a 5-tool surface.

What ideaudit chose

MCP, end to end. Reasoning: users have Claude Desktop, Claude Code, and SDK apps. We wanted one server, one auth model, one rate limiter. Function calling per client would have meant re-implementing 42 tools three ways and praying they stayed in sync.

curl -fsSL https://inite.studio/install.sh | sh

The 42 tools are the same whether you talk to ideaudit from Claude Desktop, Claude Code, or the SDK. That's the MCP win, in one sentence.

FAQ

Frequently asked questions

  1. Can I use both?

    Yes — and many apps do. Use function calling for in-app tools the user never sees (auth, internal lookups). Use MCP for tools the user wants to access from other clients too. The two coexist in the same Claude session.

  2. Is MCP slower than function calling?

    Marginally. Function calling is in-process; MCP is JSON-RPC over stdio or HTTP-SSE. The added latency is single-digit milliseconds for stdio transport, ~50-100ms for HTTP. For LLM-bound workflows the cost is invisible — the model takes 2-30s anyway.

  3. Does MCP work with non-Anthropic models?

    Yes. MCP is model-agnostic — the protocol doesn't care which LLM you use. Goose, Continue, and OpenAI's MCP-compat layer all run MCP servers against non-Claude models. Anthropic shipped MCP first because they invested early; the protocol itself is open.

  4. Should I migrate my existing function-calling app to MCP?

    Only if you want the tools available outside the app — to a CI pipeline, to Claude Desktop, to a colleague's agent. If your tools are app-internal forever, function calling is fine.

Read next