MCP vs Function Calling: Protocol or App Interface?

Choose from the integration boundary

Function calling and MCP solve different layers

Function calling connects a model response to application code

OpenAI's official function calling guide describes tools supplied by the application, model-produced tool calls, application-produced tool outputs, and continuation of the model conversation. JSON schemas describe function arguments, but the application decides what to expose, validates the call, performs the action, and returns output.

MCP standardizes a host-client-server conversation

The MCP architecture specification defines a host that coordinates clients, with each client maintaining an isolated server connection. Servers expose focused capabilities; clients and servers negotiate supported features. The host controls connection permissions, context aggregation, security policy, consent, and model integration.

MCP therefore covers more than calling one function. It defines protocol messages, lifecycle, transports, capability negotiation, notifications, and server primitives. That broader surface creates interoperability, but it also creates more contracts to test and version.

A common design uses both

An MCP host can discover a server's tools, translate their schemas into the format expected by a model API, receive a proposed function call, invoke the corresponding MCP tool, validate the result, and continue generation. In that design, MCP is the server integration boundary and function calling is the model interaction boundary.

The adapter must preserve names, descriptions, required fields, types, structured outputs, errors, and call identity. It also needs a collision policy when servers expose similar names. Never treat a model-produced call as authority to execute; pass it through the host's permission, confirmation, and business-rule checks.

Protocol support does not supply authorization or safety

Capability negotiation says what features an endpoint supports, not what a user is allowed to do. Tool metadata describes behavior, but descriptions and annotations from an untrusted server are not proof. The host must authenticate remote endpoints, authorize each action against the current user and resource, minimize credentials, constrain network and file reach, and require approval for consequential effects.

The same principle applies to direct function calling. A valid schema-shaped argument can still request a forbidden refund, the wrong tenant record, or a destructive file path. Validate both structure and semantics, show meaningful confirmations, and read back the resulting state before telling the user the action succeeded.

Failure cases that expose a confused architecture

• “MCP replaces tool calling”: the host still needs a model-facing decision and execution loop. Name both boundaries.
• “Schema valid means authorized”: correct JSON crosses a tenant or role boundary. Evaluate identity and resource policy separately.
• Blind schema translation: optional values, unions, or output contracts change meaning between interfaces. Add adapter contract fixtures.
• Untrusted descriptions: malicious tool text influences model behavior or hides side effects. Curate exposure and treat server metadata as data.
• Tool-name collision: two servers expose ambiguous names and the wrong action runs. Namespace tools and preserve server identity.
• Success without state: the protocol call returns normally but the external action failed or partially completed. Verify the end state.

A boundary-first implementation sequence

1. Write the tool contract. Define user goal, inputs, outputs, side effects, permission checks, idempotency, failure classes, and verification.
2. Build a direct application loop. Expose the minimum function schema, validate model arguments, execute in isolation, and read back state.
3. Identify the interoperability need. Name the hosts, servers, primitives, lifecycle, and transport that justify MCP.
4. Add an explicit adapter. Translate schemas and errors without losing server identity, call identity, structured content, or policy context.
5. Enforce host policy before invocation. Authenticate endpoints, authorize users, scope credentials, require approvals, and bound timeouts.
6. Test both seams. Cover model-to-function behavior and host-to-MCP behavior independently, then run end-to-end failure paths.
7. Trace and review. Record discovery, server, tool, arguments with secrets redacted, policy decision, output validation, state change, and stop reason.

Decision summary

Choose function calling for an application-owned model-to-tool interface and MCP for interoperable client-server discovery and invocation. Many systems use both: function calling selects an action while an MCP client connects to a governed server boundary.