Function calling is a model API mechanism: your application gives the model tool schemas, receives a structured call, executes code, and returns the result. MCP is a client-server protocol for discovering and using tools, resources, and prompts across compatible hosts. Use direct function calling for a small, application-owned tool set. Use MCP when tools need reusable discovery, remote access, or compatibility across clients. Many systems use both.
Tech
Function calling is a model API mechanism: your application gives the model tool schemas, receives a structured call, executes code, and returns the result. MCP is a client-server protocol for discovering and using tools, resources, and prompts across compatible hosts. Use direct function calling for a small, application-owned tool set. Use MCP when tools need reusable discovery, remote access, or compatibility across clients. Many systems use both.
Reviewed July 30, 2026: The official MCP release list marks 2026-07-28 as the latest stable release. The earlier 2026-07-28 RC remains listed separately as a prerelease, and SDK adoption can lag the specification.
At a glance
• Function calling describes how a model requests one of the tools supplied in a model call.
• MCP describes how an AI host or client discovers and invokes capabilities exposed by a server.
• Neither mechanism automatically makes a tool safe, authorized, idempotent, or reliable.
• Direct function calling has fewer moving parts for a small, private integration.
• MCP can reduce custom adapters when several hosts need the same tool surface.
• An MCP client commonly converts discovered MCP tools into model-visible tool definitions.
Architecture and mechanics
With direct function calling, the application owns the entire loop:
1. Define a function or tool with a name, description, and input schema.
2. Include those definitions in a model request.
3. The model returns a structured request to call a tool.
4. Application code validates the arguments and checks policy.
5. The application invokes local code or a downstream API.
6. The tool result is returned to the model for another turn.
7. The application stops, retries, asks for approval, or continues.
Google’s function calling documentation makes the execution boundary explicit: the model suggests a function and arguments, while the application executes it. Anthropic’s tool use documentation similarly describes client tools whose execution is controlled by the application. The model does not gain direct API access merely because a schema exists.
MCP inserts a standardized capability boundary. The MCP introduction defines a host that coordinates one or more clients, with each client maintaining a connection to a server. Servers can expose:
• tools, which the model or application can invoke;
• resources, which provide contextual data;
• prompts, which provide reusable interaction templates.
The MCP client discovers or negotiates protocol capabilities, lists available objects, and sends protocol requests. The 2026 core is stateless and uses server/discover; older 2025 integrations use initialization and may retain sessions. The host decides which tools become visible to the model. A model can request an MCP-backed tool through the provider’s ordinary tool-calling mechanism, and the client returns the server result to the host.
This is why “function calling versus MCP” is not always an either-or choice. Function calling can be the model-facing layer while MCP standardizes the application-to-tool-server layer.
Discovery, ownership, and portability
Direct function definitions usually live in application code. That is useful when the application team owns the implementation and release cycle. Names, schemas, credentials, retries, and result formatting can be tailored to one product.
MCP servers advertise their capabilities after connection. A compatible client can consume the same server without copying every tool schema into each host. Discovery reduces integration duplication, but it creates a dynamic dependency: tool descriptions or schemas may change independently from the client.
Portability also has limits. Two MCP hosts can support different transports, authorization flows, extensions, or user-interface features. A tool that is technically discoverable may be hidden by policy or rendered differently. Protocol compatibility is not identical to product compatibility.
Decision table
Situation: Three internal tools in one service; Prefer: Direct function calling; Reason: Smallest architecture and one owner; Watch for: Provider-specific schema differences
Situation: Same tool suite used by several AI hosts; Prefer: MCP; Reason: Reusable discovery and invocation contract; Watch for: Client capability and auth variance
Situation: Very low-latency in-process computation; Prefer: Direct function calling; Reason: Avoids another protocol and network boundary; Watch for: Keep execution sandboxed
Situation: Third-party capability marketplace; Prefer: MCP; Reason: Separates host from independently operated servers; Watch for: Trust, versioning, and supply-chain risk
Situation: Strict deterministic workflow; Prefer: Ordinary code, optionally with tools; Reason: Model should not choose fixed control flow; Watch for: Do not add an agent unnecessarily
Situation: Existing model loop plus shared remote tools; Prefer: Both; Reason: Function calling faces the model; MCP faces servers; Watch for: Correlate traces across both layers
Tool quality matters more than the interface
Whichever mechanism you choose, define narrow tools with clear business meaning. create_refund_request is easier to authorize than a generic call_api tool. Keep required arguments explicit, constrain enums and formats, reject unknown fields, and return concise structured output.
Do not expose every endpoint of a SaaS API. The model needs the minimum capability for the workflow, not a copy of the provider’s entire developer surface. Hide tenant identifiers, account IDs, approval thresholds, and policy values from model-controlled arguments when they can be fixed by trusted code.
Plan for schema evolution. Additive optional fields are usually less disruptive than renaming required fields. Keep a compatibility period, test saved prompts and agents, and version destructive semantic changes even if the JSON remains valid.
Security and governance
Tool descriptions and tool results are untrusted inputs to the model. A compromised MCP server can alter a description; a compromised downstream system can place prompt injection in a returned document; and a direct function can return excessive sensitive data. The interface does not remove those risks.
Enforce controls outside the model:
• authenticate the user, host, and remote server;
• authorize every call against user, tenant, resource, and action;
• filter the tool inventory before it enters model context;
• allowlist network destinations and downstream operations;
• attach credentials only in the execution layer;
• require confirmation for financial, destructive, or external actions;
• cap iterations, tool calls, time, output size, and cost;
• validate arguments against schema plus business rules;
• use idempotency keys for retryable writes;
• log tool version, arguments, policy, approval, outcome, and correlation ID.
For remote protected MCP servers, follow the dated MCP authorization specification. Do not forward an MCP access token to a downstream API. Obtain a token intended for that downstream audience.
Direct functions also need credential isolation. Environment variables or secrets attached to application code are not safe if arbitrary tool arguments can redirect requests or interpolate commands.
Implementation checklist
• [ ] List the exact tools the workflow needs.
• [ ] Remove operations that deterministic application code can perform directly.
• [ ] Decide whether each tool is application-owned, shared internally, or third-party.
• [ ] Use direct calling for a small private surface unless reuse justifies MCP.
• [ ] Pin and record the MCP protocol and SDK versions if MCP is selected.
• [ ] Define strict input and output schemas.
• [ ] Keep policy-controlled values out of model-provided arguments.
• [ ] Authenticate identities and enforce tenant and record permissions.
• [ ] Store credentials outside prompts and model-visible results.
• [ ] Add approval for high-consequence calls.
• [ ] Make write tools idempotent and define retry behavior.
• [ ] Bound loops, latency, payload size, and spend.
• [ ] Sanitize or isolate untrusted tool content.
• [ ] Trace the model request, dispatch, server call, downstream call, and outcome.
• [ ] Test malformed arguments, unavailable tools, changed schemas, timeouts, and revoked access.
Limitations and change risk
Function-calling formats differ by model provider, SDK, and model family. Parallel calls, strict schema behavior, streaming events, and tool-choice controls should be confirmed in the selected provider’s current documentation.
MCP is evolving and clients implement different subsets. The 2026 specification is stable, but that does not establish SDK or host conformance. Verify the negotiated wire version and maintain an explicit compatibility plan.
Neither approach provides workflow durability by itself. Long-running tasks may need queues, checkpoints, compensation, scheduled execution, and human work items. A protocol can standardize messages without guaranteeing business completion.
For a broader comparison with deterministic automation platforms, read AI agents vs RPA vs Zapier.
FAQs
Does MCP replace function calling?
No. MCP standardizes connections to capability servers. A host may still present MCP tools to a model through that provider’s function- or tool-calling interface.
Is direct function calling more secure than MCP?
It has fewer boundaries, which can simplify review, but security depends on implementation. Direct tools can still leak credentials, accept unsafe arguments, or expose excessive permissions.
When is MCP unnecessary?
It may be unnecessary when one application owns a small, stable tool set and no other host needs discovery or reuse. Ordinary functions are often simpler in that case.
Can MCP expose an entire API?
It can, but doing so is usually a poor security design. Expose narrow business capabilities and keep sensitive or administrative parameters under trusted code.
Which option is better for deterministic processes?
Use deterministic code or a workflow engine for known control flow. Add a model only where interpretation or judgment is required, then restrict its tool choices.
Get a 20-Minute AI Workflow Audit
AI Operator can map one workflow’s model loop, tool ownership, permissions, failure handling, and evidence to determine whether direct calling, MCP, or both are justified.