MCP vs Plain Function Calling

By Michael Samuel Naeem · July 12, 2025 · 5 min read

Our agent had fourteen @tool decorators in one Python file. Marketing wanted the same Salesforce lookup in Claude Desktop, the support bot, and a GitHub Action — so we copied the function schemas three times and watched them drift within a month. Model Context Protocol (MCP) didn't replace the LLM's function-calling API; it replaced the copy-paste layer between hosts and tool implementations. Understanding where each layer stops saves you from bolting MCP onto problems a simple tools array already solves.

Two layers, not two competitors

┌─────────────┐     tool schemas / tool_calls     ┌──────────────┐
│  LLM API    │ ◄──────────────────────────────► │  Agent host  │
│ (OpenAI,    │                                   │ (your app)   │
│  Anthropic) │                                   └──────┬───────┘
└─────────────┘                                          │
                                                         MCP (optional)
                                                          │
                              ┌───────────────────────────┼───────────────────────────┐
                              ▼                           ▼                           ▼
                        MCP server                  MCP server                   MCP server
                        (git tools)                 (database)                   (browser)

Function calling is the contract between model and host: JSON Schema definitions, tool_calls in the response, results fed back as messages.

MCP is the contract between host and tool providers: list tools, call tools, optional resources and prompts — over stdio, HTTP, or SSE.

The model never speaks MCP directly. Your host translates MCP tool listings into whatever schema format the provider expects.

Plain function calling: when it's enough

For a single backend service with five stable tools, inline definitions win on simplicity:

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_order_status",
            "description": "Look up order by ID",
            "parameters": {
                "type": "object",
                "properties": {"order_id": {"type": "string"}},
                "required": ["order_id"]
            }
        }
    }
]

response = client.chat.completions.create(
    model="gpt-4o",
    messages=messages,
    tools=tools,
)

Advantages:

• One process, one log stream, one deploy unit
• No subprocess lifecycle or MCP handshake latency
• Full control over schema versioning tied to app releases

Stick with this until you feel pain from duplication or isolation requirements.

What MCP adds

MCP servers expose capabilities through a standard protocol:

{
  "jsonrpc": "2.0",
  "method": "tools/list",
  "id": 1
}

Returns tool names, descriptions, and input schemas. The host merges these into the LLM's tools array at session start or on reconnect.

Portability. Write one postgres-mcp-server; Cursor, Claude Desktop, and your internal agent runner connect without reimplementing queries.

Process isolation. A crashing browser automation server doesn't take down your API. Sandboxing untrusted tools (shell, SQL) in separate processes is an security win.

Dynamic discovery. Add tools to the server without redeploying the host — useful for plugin ecosystems and internal platforms where teams ship their own MCP servers.

Resources and prompts. MCP also standardizes read-only context (files, docs) and reusable prompt templates — function calling alone doesn't cover these.

Transport trade-offs.

We run database MCP servers over stdio in dev and HTTP behind OAuth in staging. Latency added ~40ms per tool call vs inline — acceptable for human-in-the-loop agents, painful for tight autocompletion loops.

Hybrid architecture.

1. Core business tools stay inline — order lookup, user auth, billing. Tightly coupled to domain models, versioned with the API.
2. Shared infrastructure tools are MCP — GitHub, Jira, Datadog. One server per integration, maintained by platform team.
3. User-supplied tools (enterprise customers connecting their CRM) run as isolated MCP servers with scoped credentials.

The agent host normalizes both sources into a single tools array before each LLM call. Tool routing middleware deduplicates names and enforces allowlists per tenant.

Schema mapping pitfalls.

MCP tool schemas use JSON Schema; providers have subtle differences (strict mode, additionalProperties, nullable unions). Your adapter layer should:

• Validate schemas at server startup
• Strip unsupported keywords per provider
• Prefix MCP tool names to avoid collisions (github_create_pr vs inline create_pr)

We lost an afternoon to duplicate tool names when Git and Jira MCP servers both exported search.

Security comparison.

Function calling in-process inherits your app's trust boundary. MCP expands it:

• stdio servers inherit OS user permissions — don't run as root
• Remote MCP needs OAuth 2.1, mTLS, or API keys with least privilege
• Tool injection — validate tools/list responses; compromised servers can exfiltrate via tool descriptions (prompt injection vector)

Treat MCP servers like microservices: authenticate, authorize, audit, rate-limit.

Decision checklist.

Choose inline function calling when:

• One app, one team, <10 tools
• Sub-100ms tool latency matters
• Tools need direct access to in-memory app state

Choose MCP when:

• Multiple hosts consume the same tools
• Tools run in different languages or need sandboxing
• Platform team ships integrations consumed by many agents
• You want third-party or plugin-style extensibility

Operational maturity matters as much as protocol choice. For MCP, version servers independently from hosts, publish changelogs when tool schemas change, and run contract tests that call tools/list and validate every schema against JSON Schema draft 2020-12. For inline tools, keep definitions in a single module with unit tests that snapshot schema shape — drift shows up in CI, not in production when the model starts calling renamed parameters. Hybrid setups should expose metrics: tool latency p95 by source (inline vs MCP), error rate by server, and cache hit rate if you memoize tools/list. When onboarding a new team, default them to MCP for shared integrations but require architecture review before adding inline tools that duplicate an existing server — namespace collisions are painful at scale.

Use MCP when tools span multiple hosts and teams — function calling suffices for single-service agents with stable tool surface.

Resources

• Model Context Protocol specification
• OpenAI function calling guide
• Anthropic tool use documentation
• MCP servers repository (official examples)
• Cursor MCP documentation