MCP vs Function Calling: Architecture, Differences, and When to Use Each

Direct answer

MCP and function calling are not competing names for the same mechanism. They operate at different layers and are often used together.

Function calling—also called tool calling—is the model-facing mechanism by which an application tells a model what actions are available and the model returns a structured request to use one. In the classic custom-function flow, the application supplies a function name, description, and input schema; the model returns the selected function and arguments; application code executes it; and the result is sent back to the model. OpenAI, Anthropic, and Google expose different native representations of this pattern. Provider-hosted tools complicate the simple story because the provider may execute the tool, but the defining feature remains the model’s structured selection of a capability. (OpenAI function calling [S169]; Anthropic tool use [S011]; Gemini function calling [S177])

The Model Context Protocol, or MCP, is an application-level client–server protocol. An MCP server publishes tools and may also publish resources, prompts, and extensions. An MCP client can discover those capabilities and invoke them through JSON-RPC over a supported transport. The MCP host—the user-facing AI application—decides which server tools become available to a model, how they are translated into the model provider’s tool format, when approval is required, and what happens with the results. (MCP tools, 2026-07-28 [S123]; MCP base protocol [S130])

A common production flow is therefore:

MCP server publishes a tool
        ↓
MCP client lists and filters it
        ↓
Host translates it into the model provider’s tool format
        ↓
Model returns a function/tool call
        ↓
Host invokes tools/call through MCP
        ↓
MCP server calls the underlying API, database, CLI, SDK, or local code
        ↓
Host returns the result to the model

MCP does not replace native function calling, REST APIs, an agent loop, permissions, or application logic. It standardizes the boundary between capability providers and compatible clients. Direct function calling remains the simpler choice when one application owns a small, stable tool set. MCP becomes more valuable when capabilities must be reused across hosts, discovered at runtime, operated independently, secured as remote services, or distributed as integrations.

---

Executive summary

The most accurate comparison is not “MCP versus function calling” but served capabilities versus model-facing invocation.

Function calling answers:

What structured action does the model want the application to perform?

MCP answers:

What capabilities does this server expose, and how does a compatible client list, call, authorize, transport, and interpret them?

An agent loop answers a third question:

Who repeatedly calls the model, executes or routes requested actions, returns results, applies policy, handles errors, and decides when work is finished?

The underlying API answers a fourth:

How does the external system itself expose data or operations?

These layers can be combined without being collapsed. A model may select an MCP-published tool through native function calling; the MCP server may then invoke a REST API; an agent loop may continue for several rounds.

The strongest arguments for direct function calling are simplicity, low architectural overhead, tight control, and suitability for internal functions owned by one application. The strongest arguments for MCP are reusable server implementations, runtime discovery, separation of provider and consumer, local and remote transports, protocol-level authorization for remote deployments, additional primitives beyond tools, and the possibility of serving several compatible hosts from one implementation.

Neither approach supplies a security guarantee. A function declaration does not make application code safe. An MCP tool annotation is an untrusted hint unless the server is trusted. MCP adds new trust boundaries—packages, server implementations, transports, OAuth, and deployment—but it can also create a consistent point for filtering, approvals, gateways, tracing, and policy. Security depends on the host, server, SDK, credentials, model behavior, external content, and underlying service permissions.

Several popular comparisons are now historically outdated. MCP revisions through 2025-11-25 used an initialization handshake and protocol sessions. The current 2026-07-28 revision removed initialize, notifications/initialized, and Mcp-Session-Id; requests are self-describing, server/discover is optional, and list responses can be cached. Accordingly, current MCP should not be described categorically as a persistent, stateful session protocol. Applications may still maintain state through databases, authorization records, Tasks, or explicit handles, but that is not hidden protocol-session state. (MCP 2026-07-28 release [S058])

The practical recommendation is:

• Use direct function calling for a small, application-owned tool set with no meaningful reuse requirement.
• Use MCP for capabilities intended to be consumed by multiple hosts, supplied by another team or vendor, discovered dynamically, or operated behind a protocol boundary.
• Use both when a host discovers MCP tools and exposes the selected subset to a model through native function calling—which is already an explicit pattern in official SDKs. (OpenAI Agents SDK MCP integration [S090])

---

1. The four layers people commonly confuse

A useful comparison begins by separating four architectural layers.

The four layers people commonly confuse comparison table

Layer	Principal question	Typical artifact
Model tool/function calling	What action is the model requesting?	Function declaration and structured tool call
Host or agent orchestration	Should the action run, and what happens next?	Agent loop, approvals, retries, context management
MCP	Where does the capability come from, and how is it invoked interoperably?	Host, MCP client, MCP server, JSON-RPC methods
Underlying system interface	How does the external system expose its actual operation?	REST, GraphQL, database protocol, SDK, CLI, local function

The layers are separable even when a product hides them. An API provider may host the MCP connection and execute the entire round trip. An agent framework may normalize several model providers’ function-call formats. An MCP server may run in the same process as its client. None of those implementation choices makes the concepts identical.

A compact mental model

Natural-language request
        ↓
MODEL LAYER
Select a structured action
        ↓
HOST / AGENT LAYER
Filter, approve, route, retry, observe
        ↓
MCP LAYER (optional)
Discover and call an independently supplied capability
        ↓
SYSTEM LAYER
REST / GraphQL / database / SDK / CLI / local code

The central historical significance of MCP is the optional third layer. AI applications used tools before MCP. MCP attempted to make the capability boundary reusable across compatible applications rather than rebuilding each connector inside each host. Anthropic’s launch announcement described the pre-MCP problem as a proliferation of custom implementations and introduced MCP as a standard connection model. (Anthropic MCP launch, November 25, 2024 [S021])

---

2. What function calling actually is

Function calling is a model API convention for structured action selection. An application gives the model one or more tool definitions. A definition typically includes a name, a description, and a schema for the expected arguments. The model can answer normally or return a structured tool request. The application—or, for some provider-hosted tools, the provider—executes the operation and returns a result.

OpenAI publicly introduced function calling in its API on June 13, 2023. The original announcement described functions to GPT models and receiving a JSON object with arguments matching a function signature. It also warned that untrusted tool output could manipulate the model and recommended user confirmation for consequential actions. (OpenAI, “Function calling and other API updates” [S010])

The classic custom-function loop

1. Application defines tools.
2. Application sends tools and user input to the model.
3. Model returns ordinary text or a structured tool call.
4. Application validates and executes the requested function.
5. Application returns the tool result.
6. Model produces a final answer or requests another tool.

OpenAI’s current guide describes functions in a tools parameter with name, description, JSON Schema parameters, and a strict option. Anthropic describes client tools using name, description, and input_schema, returning tool_use blocks that application code executes. Google’s Gemini documentation similarly states that the model does not execute a custom function: the developer extracts the requested name and arguments, runs the function, and returns its result. (OpenAI function definitions [S169]; Anthropic tool use [S011]; Gemini function calling [S177])

Function calling is not ordinary function execution

A model returning:

{
  "name": "create_issue",
  "arguments": {
    "repository": "org/project",
    "title": "Fix OAuth redirect validation"
  }
}

has not itself created an issue. It has emitted structured data representing a requested action. The application still owns validation, authorization, execution, error handling, and the decision to return the result to the model.

This distinction matters because “the model called a function” is convenient shorthand, not a complete security or systems description.

Custom tools and provider-hosted tools

The traditional account—“your application executes the function”—is correct for custom client tools but no longer exhaustive.

• Anthropic distinguishes client tools, which the application executes, from server tools, which Anthropic executes.
• OpenAI exposes application functions, built-in hosted tools, hosted MCP tools, and tool search through one broader tools interface.
• Google SDKs can automate portions of the function-calling loop even though the external operation still occurs outside the model itself.

Therefore, function calling is best defined by the model-facing structured choice, not by a universal claim about which machine runs the code. (Anthropic tool execution distinction [S011]; OpenAI Agents SDK tools [S171])

---

3. What MCP actually is

For protocol definitions, roles, and examples, start with what MCP is and what an MCP server is.

MCP is a protocol through which clients communicate with servers that expose protocol-defined capabilities. It uses JSON-RPC 2.0 message structures but is not synonymous with JSON-RPC. JSON-RPC supplies generic request, response, notification, and error envelopes; MCP defines methods, types, transports, capabilities, authorization rules, version behavior, and extensions specific to the protocol. (JSON-RPC 2.0 [S001]; MCP base protocol [S130])

Host, client, and server

Historically and conceptually:

• The host is the coordinating AI application. It owns the user experience, model integration, permissions, and orchestration.
• The client implements the client side of MCP for a particular server relationship.
• The server implements the server side and exposes focused capabilities.

One product may contain both the host and client. A server is not the host, and the model is not the MCP client. Earlier specifications explicitly described one client–server session per connection; the 2026 revision changed the lifecycle and state model but not the usefulness of separating roles. (MCP launch-era architecture, 2024-11-05 [S025]; MCP 2026-07-28 release [S058])

MCP tools

In the current specification, a server may declare the tools capability and return tools through tools/list. A tool definition can include:

• name
• title
• description
• icons
• inputSchema
• optional outputSchema
• annotations

The current default schema dialect is JSON Schema 2020-12 when $schema is absent. Tool annotations are explicitly untrusted unless they come from a trusted server. Tools can return text, images, audio, resource links, embedded resources, and structured content. (MCP tools, 2026-07-28 [S123])

MCP is broader than tools

MCP servers may also expose:

• Resources: URI-identified context or data that clients can list or read.
• Prompts: server-provided prompt templates intended to be surfaced or selected by users or applications.
• Extensions: independently versioned capabilities such as MCP Apps or Tasks.
• Other version-specific server and client capabilities.

Native function calling does not, by itself, define equivalent resource, prompt, transport, discovery, authorization, extension, or server-identity semantics. An application can build any of those around function calling, but they are not inherent in the function-call object. (MCP resources [S124]; MCP prompts [S125]; MCP extensions overview [S164])

---

4. The central difference: model interface versus capability interface

The cleanest distinction is:

Function calling is usually the interface between the model and its host application. MCP is the interface between the host application and an external or modular capability provider.

Function calling communicates model intent. MCP communicates with a server.

What function calling standardizes

Within one provider’s API, function calling typically standardizes:

• how tools are described to that model;
• how the model identifies the selected tool;
• how arguments are represented;
• how a tool result is associated with the call;
• how tool choice, strictness, and parallel calls are controlled.

What MCP standardizes

MCP standardizes a different set of concerns:

• how a client discovers server capabilities;
• how tools, resources, and prompts are listed;
• how a client invokes a tool;
• how results and errors are represented;
• how local or remote transports carry messages;
• how protocol revisions are identified;
• how remote authorization works;
• how optional capabilities and extensions are represented;
• how server implementations remain independent of one model API.

These sets overlap around schemas and tool invocation, which creates the confusion. But overlap is not equivalence.

---

5. How MCP and function calling work together

The lifecycle-focused companion explains how MCP works from request to result, while the role guide shows where the model and MCP client sit.

A host that connects to an MCP server generally needs to make the server’s tools useful to its model. The usual pattern is a translation layer:

1. Call tools/list on the MCP server.
2. Apply server allowlists, user permissions, product restrictions, and context-sensitive filtering.
3. Convert selected MCP tool definitions into the model provider’s tool representation.
4. Send those definitions to the model, or make them available through provider-side tool search.
5. Receive the model’s structured tool request.
6. Resolve the translated name back to the original server and tool.
7. Invoke tools/call.
8. Convert the MCP result into the provider’s tool-result representation.
9. Continue the model or agent loop.

Official implementation evidence makes this more than an architectural inference. OpenAI’s Agents SDK has options to convert MCP tool schemas to strict JSON Schema on a best-effort basis, prefix tool names with a server identifier to prevent collisions, and still invoke the original MCP tool on the original server. It also supports provider-hosted remote MCP, where OpenAI’s infrastructure performs the listing and invocation rather than requiring a callback to the developer’s Python process. (OpenAI Agents SDK MCP [S090])

One issue-creation operation, end to end

Suppose the user says:

Create an issue in acme/payments titled “Reject OAuth tokens with the wrong audience.”

Stage 1: the server publishes the capability

The repository MCP server returns a tool conceptually like:

{
  "name": "create_issue",
  "description": "Create an issue in a repository",
  "inputSchema": {
    "type": "object",
    "properties": {
      "repository": { "type": "string" },
      "title": { "type": "string" },
      "body": { "type": "string" }
    },
    "required": ["repository", "title"],
    "additionalProperties": false
  }
}

Stage 2: the host prepares the model-facing definition

The host may rename it to avoid a collision:

{
  "type": "function",
  "name": "github__create_issue",
  "description": "Create an issue in a repository",
  "parameters": {
    "type": "object",
    "properties": {
      "repository": { "type": "string" },
      "title": { "type": "string" },
      "body": { "type": "string" }
    },
    "required": ["repository", "title"],
    "additionalProperties": false
  },
  "strict": true
}

That representation is illustrative. The exact shape depends on the provider, SDK, and schema conversion rules.

Stage 3: the model requests the action

The model returns a structured call to github__create_issue with arguments.

Stage 4: the host evaluates the request

The host may:

• confirm the target repository;
• require user approval because this is a write operation;
• reject a disallowed organization;
• add tenant metadata;
• log the request;
• map the translated name to the original server and tool.

Stage 5: the client invokes MCP

Conceptually:

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "create_issue",
    "arguments": {
      "repository": "acme/payments",
      "title": "Reject OAuth tokens with the wrong audience"
    }
  }
}

Current MCP requests carry required protocol-version and client-capability metadata in _meta; clientInfo is recommended but optional. The shortened example omits those fields for readability. (MCP tools [S123])

Stage 6: the server calls the underlying platform

The MCP server may invoke a REST or GraphQL endpoint, use a vendor SDK, or run local source-control code.

Stage 7: the result moves back up the stack

The server returns an MCP result. The host converts that result into the provider’s expected tool-result object and sends it to the model. The model then reports success, requests another action, or asks for missing information.

No layer replaces another:

Function calling selected the action.
The host authorized and routed it.
MCP carried the interoperable capability invocation.
The repository API performed the underlying business operation.
The agent loop continued the workflow.

---

6. Detailed comparison matrix

MCP vs function calling: 29-dimension comparison matrix

Property	Native function calling	MCP
Primary concern	Model-facing structured action selection	Client–server capability interoperability
Core actors	Model provider API and application	Host, MCP client, MCP server
Capability definition owner	Usually the application or provider	MCP server
Discovery	Application supplies definitions; provider tool search may defer or retrieve them	Client lists or discovers server capabilities
Model required	Normally yes for the model-facing mechanism	No; a program can call MCP methods directly
Server required	No	A server-side implementation is required, though it may be in-process
Transport	Provider API protocol	stdio, Streamable HTTP, or conforming/custom transport
Wire basis	Provider-specific API objects	JSON-RPC 2.0 plus MCP semantics
Invocation object	Provider-specific tool/function call	tools/call request
Execution	Application, provider, or framework, depending on tool type	MCP server implementation
Underlying system	May call local code or external systems directly	Often wraps API, database, SDK, CLI, or local code
Input schemas	Provider-supported JSON Schema subset or custom format	Current MCP uses valid JSON Schema; default 2020-12
Output schemas	Provider-specific structured output mechanisms	Optional MCP outputSchema and structuredContent
Resources	Not inherent	Native protocol primitive
Prompts	Not inherent	Native protocol primitive
Authorization	Application- or provider-specific	Defined framework for HTTP-based remote MCP
Versioning	Provider API/model/SDK versioning	Date-based MCP protocol revisions and extensions
Reuse across hosts	Requires shared library or adapter strategy	A principal design objective
Portability	Provider-native representation varies	Server can be reused by compatible clients, subject to capability differences
Tool naming scope	Provider/application scope	Unique within one server; aggregators must resolve collisions
Human approval	Application/provider feature	Host responsibility; protocol guidance and SDK support
State	Conversation or application may be stateful	Current protocol core is sessionless; applications can use explicit state
Long-running work	Application orchestration or provider feature	May use ordinary calls or Tasks extension
Parallelism	Provider-specific controls	Clients can issue concurrent calls; JSON-RPC batching is not part of current MCP
Error handling	Provider- and application-specific	JSON-RPC errors plus tool-result error semantics
Latency	Usually shortest path for in-process application tools	Adds client/server boundary; may be in-process, IPC, or network
Best fit	Small, tightly coupled, application-owned tool sets	Shared, independently operated, discoverable integrations
Security guarantee	None from the schema alone	None from protocol compliance alone

---

7. Tool schemas: similar shape, different contract

Both systems commonly use JSON Schema, but “both use JSON Schema” does not mean their contracts are identical.

MCP’s current tool schema

Current MCP tool definitions support a valid JSON Schema object for inputSchema, defaulting to dialect 2020-12 when $schema is absent. They may also include outputSchema, icons, annotations, and MCP-specific metadata. (MCP tools [S123])

Provider function schemas

Provider APIs usually support a subset or interpretation of JSON Schema. Strict modes can impose additional requirements. OpenAI’s strict function mode, for example, requires particular schema constraints; its docs also note that not every JSON Schema feature is supported. Google likewise documents a supported subset for function declarations. Anthropic offers strict tool use but has its own request and response envelopes. (OpenAI function calling [S169]; Gemini function calling [S177]; Anthropic tool use [S011])

Translation can be lossy

When a host converts an MCP tool to a provider-native function, it may need to:

• remove unsupported schema keywords;
• rewrite optional properties;
• add additionalProperties: false;
• shorten or sanitize names;
• flatten references;
• convert defaults or nullable values;
• omit MCP-only icons, annotations, or metadata;
• decide how to represent MCP content blocks;
• map errors into provider-visible text.

OpenAI’s Agents SDK calls strict conversion best effort, which is a useful warning against claiming automatic equivalence. (OpenAI Agents SDK MCP [S090])

Structured tool output is not model structured output

MCP structuredContent is structured data returned by an MCP tool. A model provider’s “structured output” feature constrains model-generated output to a schema. Those features may be composed, but they are not the same mechanism. Current MCP documentation explicitly treats tool result structure as part of the server result contract. (MCP tool results [S123]; OpenAI structured outputs [S172])

---

8. Discovery: MCP has it, but direct tools are no longer always static

A common comparison says:

Function calling is static; MCP is dynamic.

That was a useful first approximation, but it is no longer universally accurate.

MCP discovery

An MCP client can list a server’s tools. In the current protocol, the effective tool set can vary with authorization context, and list results can include cache hints. Clients may listen for list-change notifications when supported. The 2026 revision also introduced server/discover for learning supported versions and capabilities without the former initialization handshake. (MCP tools [S123]; MCP discovery [S127])

Provider tool search

Modern provider APIs can also defer or search large tool catalogs:

• OpenAI supports tool search for deferred functions, namespaces, and hosted MCP servers.
• Anthropic’s tool search can search a large submitted catalog and load selected definitions on demand.
• Hosts can implement their own semantic or policy-based tool selection before sending any definitions to a model.

Thus the stronger distinction is:

MCP defines discovery across an independent server boundary. Provider tool search defines model-facing selection or loading within a provider’s tool system.

They can work together: a host can discover hundreds of MCP tools, index them, and expose only a small provider-native subset for a particular request.

(OpenAI Agents SDK tools [S171]; Anthropic tool search [S174])

---

9. Execution responsibility and control

In direct custom function calling

The application normally:

• decides which functions to expose;
• validates model-generated arguments;
• executes application code;
• catches exceptions;
• returns results;
• controls retries and timeouts;
• applies business authorization.

This gives the application maximum control and the fewest independently deployed components.

In MCP

The responsibility is divided:

• The server implements and executes the capability.
• The client speaks MCP and manages the server relationship.
• The host decides whether and how to expose the tool to the model.
• The model proposes a structured invocation.
• The underlying service enforces its own permissions and business rules.

This separation can improve reuse, but it does not remove host responsibility. The MCP tools specification recommends clear UI, visible invocation indicators, and the ability for a human to deny calls. It does not mandate one universal user interface. (MCP tools [S123])

An MCP server can be used without a model

MCP tools are designed to be model-controlled, but the specification explicitly permits other interface patterns. A test program, workflow engine, CLI, or deterministic application can list and call tools directly. This helps separate protocol semantics from AI product behavior. (MCP tools [S123])

---

10. MCP is not an agent loop

For the neighboring agent-to-agent layer, see MCP vs A2A.

Function calling is not an agent. MCP is not an agent. An MCP server is not automatically an agent.

An agent loop typically performs some combination of:

1. collect state and user input;
2. call a model;
3. inspect requested tools;
4. apply policy or obtain approval;
5. execute or route tools;
6. return results;
7. update memory or context;
8. repeat until completion, failure, or a limit.

MCP can supply capabilities to that loop. Function calling can express the model’s requested step. The loop remains responsible for repetition, stopping conditions, budgets, retries, delegation, and state management.

A server may itself perform agentic work behind one tool call, or expose a Tasks extension for long-running work. That does not convert the protocol as a whole into an “agent operating system.”

---

11. State: the most frequently outdated comparison

See the dedicated stateful-to-stateless migration guide and the 2026-07-28 release analysis.

Many pages published during 2025 describe:

State: the most frequently outdated comparison comparison table

Function calling	MCP
Stateless	Stateful persistent session

That comparison is no longer safe.

MCP through November 2025

Versions 2024-11-05, 2025-03-26, 2025-06-18, and 2025-11-25 used an initialization exchange. The client proposed a protocol version and capabilities; the server responded; the client sent notifications/initialized. Streamable HTTP could use Mcp-Session-Id. (MCP lifecycle, 2025-11-25 [S160])

MCP from July 28, 2026

The current revision removed:

• initialize;
• notifications/initialized;
• protocol-level sessions;
• Mcp-Session-Id.

Each request carries required protocol-version and client-capability metadata; clientInfo remains optional. A client may call server/discover, but discovery is not a prerequisite to every useful request. The stated infrastructure goal is that requests can reach any server instance without sticky routing or shared session storage. (MCP 2026-07-28 release [S058])

Stateless protocol does not mean stateless application

A current MCP server can maintain a shopping cart, browser context, external job, or database transaction using an explicit handle. The specification advises returning the handle and requiring it in later calls rather than relying on implicit connection state. (MCP stateful tools guidance [S123])

Function-calling applications can also maintain conversation state, agent memory, server records, and provider response state. “Function calling is stateless” usually means the custom function interface does not itself establish an independent persistent tool session—not that the surrounding application lacks state.

---

12. Transport and deployment

Our MCP transport guide separates stdio, Streamable HTTP, and retired HTTP+SSE behavior.

Direct function calling

For a custom application function, the only remote request may be the model API call. The actual tool can execute in the same process:

Application process
├── model API client
├── function schema
└── function implementation

This is operationally simple.

Local MCP

A host may spawn a server subprocess and exchange messages over stdio:

Host process
   │ stdin/stdout
   ▼
Local MCP server process
   ▼
Filesystem / CLI / SDK / local service

This adds process startup, package trust, environment variables, and IPC, but not necessarily a network hop.

Remote MCP

A host can communicate with a network service through Streamable HTTP:

Host / client
   │ HTTPS + OAuth where required
   ▼
Remote MCP service
   ▼
Vendor APIs / enterprise systems

This adds network latency, availability, multi-tenancy, OAuth, routing, and operational concerns. It also lets the capability provider deploy and update the server independently.

In-process MCP

The protocol roles do not logically require separate machines or even separate operating-system processes. Some SDKs permit an in-process server relationship. Therefore, “MCP always adds a network hop” and “MCP always requires a separate process” are false as universal claims. (MCP Python SDK client documentation [S167])

---

13. Authorization and permissions

Function calling has no single cross-provider authorization protocol for arbitrary custom functions. The application normally determines whether the current user may invoke the function, and the underlying service validates its own credentials.

MCP added an authorization framework as remote servers became important. The March 2025 revision introduced OAuth-oriented authorization for HTTP transports. June 2025 hardened resource-server behavior and token audience binding. Later revisions added further discovery and security rules. The current protocol continues to distinguish local stdio from remote HTTP authorization. (MCP 2025-03-26 changelog [S036]; MCP 2025-06-18 authorization [S044]; MCP 2026-07-28 changelog [S055]; current MCP security guidance [S134])

OAuth does not make a tool safe

OAuth can help answer:

• Which client is requesting access?
• On whose behalf?
• For which resource?
• Under which scopes?
• With which token audience?

It does not prove that:

• the server package is benign;
• a write operation is intended;
• tool descriptions are honest;
• external content is free from prompt injection;
• the server correctly preserves upstream permissions;
• the model selected the correct tool.

Authorization is necessary for many remote deployments, but it is one layer.

Permission inheritance is an implementation question

An MCP server may use:

• delegated per-user OAuth;
• a service account;
• server-owned credentials;
• user-supplied API keys;
• local environment credentials.

The protocol label alone does not reveal which upstream identity is used. A host must not assume that connecting as one user automatically preserves every permission boundary in the underlying service.

---

14. Security: neither side wins automatically

The MCP security guide maps the protocol, host, package, and upstream-system threat boundaries.

A two-column claim such as “MCP is more secure” or “direct functions are safer” is too broad.

Direct function-calling risks

• prompt injection from tool output;
• incorrect or malicious arguments;
• missing application authorization;
• dangerous local code;
• insufficient validation;
• overbroad service credentials;
• excessive automatic execution;
• business-logic abuse;
• provider or framework vulnerabilities.

OpenAI’s original 2023 announcement already warned that untrusted tool output could direct a model toward unintended actions and recommended confirmation for real-world impact. (OpenAI function-calling launch [S010])

Additional MCP risks

MCP can add:

• untrusted server packages;
• dependency and typosquatting risk;
• local code execution;
• malicious or misleading tool metadata;
• remote server compromise;
• OAuth and token-handling mistakes;
• cross-server tool-name collisions;
• multi-server prompt-injection paths;
• gateway and proxy misconfiguration;
• stale cached tool definitions.

Additional MCP controls

MCP can also create consistent places for:

• server allowlists;
• tool filters;
• approval policies;
• OAuth resource binding;
• gateways;
• audit and traces;
• schema validation;
• transport policy;
• per-server isolation;
• enterprise catalogs.

These benefits depend on implementation. Tool annotations are explicitly hints, not enforcement. A malicious server can lie about readOnlyHint; hard guarantees require authorization, sandboxing, network policy, or runtime controls. (MCP tool annotations analysis [S163])

A useful security decomposition

A useful security decomposition comparison table

Layer	Example responsibility
Model	Resist malicious instructions and select appropriate tools
Host	Filter tools, request approval, separate server context
Function-calling adapter	Validate translated schema and arguments
MCP client	Enforce protocol and transport behavior
MCP server	Implement tools safely and validate callers
Package/deployment	Maintain provenance, isolation, patches, secrets
Authorization	Bind identities, scopes, resources, and tokens
Underlying service	Enforce business permissions and data access

---

15. Latency, cost, and operational overhead

No protocol-level benchmark can establish that MCP is always slower or that direct function calling is always cheaper. The topology matters.

Direct function calling may minimize overhead when

• the tool is an in-process function;
• the schema is already known;
• one application owns the tool;
• there is no discovery request;
• there is no extra process or network boundary.

MCP may add

• local process startup;
• tools/list or discovery work;
• schema translation;
• IPC or network round trips;
• remote TLS and authorization;
• server cold starts;
• gateway processing.

Official OpenAI Agents SDK documentation notes that remote server listing can add noticeable latency and supports tool-list caching. The current MCP specification adds deterministic list order and cache hints to reduce repeated fetching. (OpenAI Agents SDK MCP caching [S090]; MCP 2026-07-28 release [S058])

But MCP overhead may be immaterial when

• the underlying API call dominates latency;
• the server is in-process;
• tool catalogs are cached;
• connections are reused;
• server-side execution eliminates application callbacks;
• one maintained server replaces several duplicated adapters.

The correct engineering approach is to benchmark the actual topology, including model latency, schema tokens, discovery, authorization, tool execution, and retries.

Do not import arbitrary web benchmarks

A comparison based on one application, one provider, one tool catalog, and one host does not establish general protocol performance. The article therefore makes no universal millisecond claim.

---

16. Context-window and tool-catalog cost

Both direct and MCP-derived tools can consume model context because the model needs enough metadata to select them. MCP does not force a host to inject every server tool into every request, but a naive host may do so.

Sources of cost

• tool names and descriptions;
• input schemas;
• output instructions;
• provider wrappers;
• duplicate tools from several servers;
• examples and annotations;
• repeated transmission without caching.

Anthropic documents tool search specifically to avoid loading every definition into model context, and cites large multiserver catalogs as a motivating case. OpenAI similarly supports deferred functions and hosted MCP servers through tool search. (Anthropic tool search [S174]; OpenAI Agents SDK tools [S171])

Scalable strategies

• connect only relevant servers;
• filter tools by user, task, or agent;
• namespace tools;
• search catalog metadata before loading full schemas;
• cache stable tools/list responses;
• keep frequently used tools immediate;
• load rarely used tools on demand;
• evaluate tool-selection accuracy as catalogs grow.

The context problem is therefore not “caused by MCP.” It arises whenever many tool definitions are presented to a model, but MCP can make large catalogs easier to assemble and thus easier to mishandle.

---

17. Portability and interoperability

The maintained host compatibility matrix shows why one server can behave differently across products.

What MCP can port

A server implementation can, in principle, be reused by several compatible hosts without rewriting its underlying integration for each model provider. That is real architectural value.

What MCP does not guarantee

It does not guarantee:

• every host supports the same protocol revision;
• every host supports resources, prompts, Apps, Tasks, or elicitation;
• identical authorization flows;
• identical tool filtering;
• identical model behavior;
• identical result rendering;
• zero schema conversion loss;
• identical confirmation UX;
• identical limits on names or schemas.

Interoperability means that implementations share protocol semantics. It does not mean user experiences or model outcomes are identical.

Direct functions can also be portable

A function implementation can be shared through:

• an internal library;
• a service API;
• a framework abstraction;
• generated provider adapters;
• an OpenAPI description;
• a common domain layer.

MCP is not the only route to reuse. Its value is a standardized live capability boundary, not a monopoly on modular software design.

---

18. When direct function calling is the better choice

Choose direct function calling when most of these are true:

1. One application owns the entire stack

The same team owns the model loop, schemas, implementation, deployment, and user experience.

2. The tool set is small and stable

Two internal functions do not necessarily justify a protocol server.

3. The function is an implementation detail

A private calculate_discount or classify_ticket function may have no value outside one application.

4. Minimum moving parts matter

There is no need for a separate package, process, transport, server identity, OAuth flow, or discovery step.

5. Lowest possible local latency matters

An in-process function can avoid IPC and network overhead.

6. The application needs tight custom control

The code can tailor schemas, validation, retries, and error messages directly to one model and workflow.

7. Cross-host distribution is not a goal

No other AI application is expected to consume the capability.

Direct function calling is not a primitive or inferior stage that every serious system must outgrow. It is often the correct final architecture.

---

19. When MCP is the better choice

Choose MCP when several of these are true:

1. Multiple hosts need the same capability

An IDE, desktop assistant, support agent, and internal workflow may all need the same integration.

2. The capability provider and consumer are independent

A SaaS vendor or platform team can operate the server while several applications consume it.

3. Runtime discovery matters

The server controls which tools are available for a user, tenant, plan, or authorization state.

4. Local and remote deployments need a common abstraction

The same conceptual capability may run as a local subprocess for development and a remote service in production.

5. Capabilities extend beyond tool calls

Resources, prompts, Apps, Tasks, or other extensions are relevant.

6. A protocol boundary improves governance

The organization wants server catalogs, gateways, allowlists, authorization, audit, or centralized policy around capabilities.

7. Integration code should evolve independently

The server can update the underlying API logic without embedding that implementation in every host.

8. Vendor distribution matters

An API or SaaS provider wants to publish one official model-facing capability service rather than documentation for every host’s custom adapter.

MCP is most persuasive when the integration itself is a reusable product or infrastructure boundary.

---

20. When to use both

The hybrid pattern is likely to be the default for sophisticated systems.

Pattern A: MCP tools translated into native function calls

MCP tools/list
   ↓
Host filter and schema adapter
   ↓
Native model tools
   ↓
Model tool call
   ↓
MCP tools/call

Pattern B: direct internal tools plus MCP integrations

Agent
├── direct function: calculate internal score
├── direct function: update local state
├── MCP server: source control
├── MCP server: ticketing
└── MCP server: enterprise search

Pattern C: provider-hosted remote MCP

The application supplies a remote MCP server definition to a model API. The provider lists and invokes the server’s tools on the application’s behalf. The conceptual distinction remains, but the provider hides the client and translation plumbing. OpenAI and Anthropic both document remote MCP connector patterns. (OpenAI MCP and connectors [S170]; Anthropic MCP connector [S175])

Pattern D: MCP gateway plus several model providers

A gateway or host lists tools from several servers, applies policy, and translates the permitted subset into OpenAI, Anthropic, Google, or another provider’s native tool format. This maximizes reuse but puts substantial responsibility in the adapter and policy layer.

---

21. Provider comparison

Provider comparison comparison table

Feature	OpenAI	Anthropic	Google Gemini	MCP
Common term	Function calling / tool calling	Tool use	Function calling	Tools
Input schema field	parameters	input_schema	parameters	inputSchema
Custom execution	Application	Application for client tools	Application	Server
Provider-hosted tools	Yes	Yes	Yes, product-dependent	Not a provider concept
Structured call object	Provider response item	tool_use block	functionCall or function_call, depending on API surface	JSON-RPC tools/call
Strict schema option	Yes	Yes	Provider/model dependent	Server schema; host conversion may be required
Tool search	Yes for supported models	Yes for supported models	Product-dependent	Server discovery/listing; host search is separate
Remote MCP support	Responses/Agents integrations	MCP connector	Gemini remote MCP support documented	Native protocol
Full cross-provider portability	No	No	No	Server-side objective, with host differences

The table should not be read as a feature contest. Provider tool APIs and MCP solve adjacent problems.

---

22. MCP versus APIs and OpenAPI

The focused MCP vs API guide expands the underlying-interface distinction.

MCP versus REST or GraphQL

MCP commonly sits above or alongside an application API:

Model tool request
   ↓
MCP client
   ↓
MCP server
   ↓
REST / GraphQL / database / SDK

REST and GraphQL remain general interfaces for websites, mobile apps, backend services, partners, and automation. MCP does not replace them.

MCP versus OpenAPI

OpenAPI is a machine-readable description of HTTP APIs. It can describe paths, operations, parameters, schemas, responses, and security. MCP is a live client–server protocol with capability discovery, invocation methods, transports, version rules, and additional primitives.

An OpenAPI document can be used to generate MCP tools, and an MCP server can wrap an OpenAPI-described service. Automatic conversion still requires choices about operation grouping, descriptions, authentication, schema compatibility, side effects, and model-facing semantics. (What is OpenAPI? [S179]; OpenAPI Specification [S180])

Function calling versus APIs

Function calling is not an alternative network API. It is how the model asks the application to perform an action. The application may satisfy that request with an in-process function or by calling an API.

---

23. MCP versus plugins

“Plugin” is a product or application-extension category, not one protocol.

• A ChatGPT plugin may use an MCP server in its modern implementation.
• An IDE plugin may implement an MCP host or server.
• A browser extension may connect to a local MCP server.
• An application connector may wrap MCP or use a proprietary interface.

A plugin is not automatically an MCP server, and an MCP server is not necessarily packaged as a plugin.

---

24. Historical evolution and why old comparisons conflict

Use the primary-source MCP history when reconciling claims from different protocol eras.

Historical evolution and why old comparisons conflict comparison table

Date/revision	Relevant comparison change
June 13, 2023	OpenAI publicly launches API function calling
November 25, 2024	Anthropic publicly introduces MCP
2024-11-05	Initial MCP revision: tools, resources, prompts, stdio, HTTP+SSE, initialization/session model
2025-03-26	OAuth framework, Streamable HTTP, annotations, batching
2025-06-18	Batching removed, structured tool output, auth hardening, elicitation
2025-11-25	Richer elicitation and sampling, experimental Tasks, governance additions
2026-07-28	Stateless core, no handshake/session, MRTR, routing headers, cacheable lists, extensions, Tasks moved out of core

The rapid changes explain several contradictory articles:

• “MCP uses SSE” may describe the launch transport, not current architecture.
• “MCP requires a persistent session” was correct for earlier revisions, not the current one.
• “MCP has JSON-RPC batching” was true in March 2025 and false by June.
• “Tasks are part of core MCP” describes the experimental November 2025 form, not their current extension status.

Version dates are therefore not decorative details. They determine the architecture being compared. (March 2025 changelog [S036]; June 2025 changelog [S043]; current MCP changelog [S055])

---

25. Common myths and corrections

Myth 1: MCP replaces function calling

Correction: MCP tools are often exposed to the model through native function calling. They are complementary layers.

Myth 2: MCP is function calling over HTTP

Correction: MCP also defines discovery, JSON-RPC methods, transports, resources, prompts, authorization, revisions, server metadata, and extensions.

Myth 3: Function calling always executes code in the application

Correction: Custom client tools usually do, but providers also expose hosted/server tools.

Myth 4: Function calling is always static

Correction: Provider tool search and deferred loading can dynamically narrow large catalogs.

Myth 5: MCP always requires a remote server

Correction: Servers can run locally over stdio or in-process through SDK facilities.

Myth 6: MCP always adds a network hop

Correction: Local and in-process topologies need not use a network.

Myth 7: MCP is stateful; function calling is stateless

Correction: That comparison describes older MCP revisions. Current MCP has a stateless protocol core, while both surrounding applications can maintain state.

Myth 8: An MCP server is an agent

Correction: It is a server-side protocol implementation. It may expose agentic work, but need not reason or plan.

Myth 9: MCP tools are automatically safe

Correction: Tool annotations are untrusted hints; safety depends on every layer.

Myth 10: OAuth makes an MCP server secure

Correction: OAuth addresses delegated access and token handling, not package trust, prompt injection, business logic, or model behavior.

Myth 11: One MCP server behaves identically in every host

Correction: Hosts differ in supported revisions, capabilities, models, approvals, filters, and rendering.

Myth 12: MCP eliminates all N × M integration work

Correction: It can reduce repeated protocol adapters, but hosts still need compatibility, policy, UX, and schema translation.

Myth 13: MCP replaces REST APIs

Correction: MCP servers frequently call REST APIs.

Myth 14: MCP structured output is the same as model structured output

Correction: One structures a server tool result; the other constrains model-generated output.

Myth 15: Native function calling is obsolete

Correction: It remains the model-facing mechanism in many MCP hosts and is often the simplest choice for internal tools.

---

26. Production architecture patterns

Pattern 1 — Inline application tools

Model API ↔ Host application ↔ Internal function/service

Use when: one team owns the stack, the catalog is small, and reuse is low.
Advantages: fewest moving parts, direct debugging, low overhead.
Risks: provider/tool coupling, duplicated integrations across products, capability deployment tied to host releases.

Pattern 2 — Local stdio MCP server

Model API ↔ Host/MCP client ↔ local subprocess ↔ filesystem/CLI/local SDK

Use when: a desktop or developer tool needs a focused local capability.
Advantages: reusable server package, process boundary, no internet service required.
Risks: arbitrary package execution, environment-variable secrets, broad filesystem access, startup latency, upgrade provenance.

Pattern 3 — In-process MCP adapter

Model API ↔ Host/MCP client ↔ in-process MCP server ↔ internal library

Use when: the protocol abstraction is valuable but an extra process or network hop is not.
Advantages: testable protocol boundary with low physical overhead.
Risks: SDK-specific arrangement, weaker isolation, no automatic operational independence.

Pattern 4 — Remote vendor MCP server

Model API ↔ Host/MCP client ↔ Streamable HTTP ↔ vendor MCP service ↔ SaaS API

Use when: a vendor publishes and operates its own reusable integration.
Advantages: independent updates, delegated authorization, multi-host distribution.
Risks: remote availability, OAuth complexity, tenant isolation, rate limits, data handling, support burden.

Pattern 5 — Enterprise MCP gateway

Several hosts ↔ enterprise gateway/policy layer ↔ approved local and remote servers

Use when: an organization needs centralized allowlists, authentication, routing, audit, and server governance.
Advantages: common policy point and observability.
Risks: gateway becomes a high-value trust and availability boundary; protocol compatibility still does not guarantee semantic compatibility.

Pattern 6 — Hybrid internal and MCP tools

Model
 ├─ direct internal functions
 └─ MCP tools from approved servers

Use when: internal implementation details should remain direct while distributable integrations use MCP.
Advantages: avoids forcing every tool behind a server.
Risks: two tool lifecycles and permission models must be presented coherently.

Pattern 7 — Multi-model MCP platform

OpenAI / Claude / Gemini adapters
              ↕
      shared host policy layer
              ↕
         MCP clients/servers

Use when: the same integrations support several model providers.
Advantages: capability providers can remain model-independent.
Risks: schema and result conversion may be lossy; models select tools differently; provider-specific features still require adapters.

Pattern-selection table

Pattern-selection table comparison table

Requirement	Inline tools	Local MCP	In-process MCP	Remote MCP	Gateway
Lowest architectural overhead	Strong	Medium	Strong	Weak	Weak
Reuse across hosts	Weak	Medium	Medium	Strong	Strong
Independent vendor operation	Weak	Weak	Weak	Strong	Strong
Local system access	Medium	Strong	Strong	Weak	Medium
Remote delegated authorization	Weak	Weak	Weak	Strong	Strong
Central enterprise policy	Weak	Medium	Medium	Medium	Strong
Process isolation	Weak	Medium	Weak	Strong boundary	Variable
Multi-tenant scaling	Application-specific	Weak	Weak	Strong potential	Strong potential

Productionization controls shared by all patterns

• Least-privilege credentials and upstream permissions.
• Schema validation plus semantic validation.
• Explicit policy for destructive or open-world actions.
• Tool catalog filtering and name-collision handling.
• Prompt-injection and untrusted-output handling.
• Idempotency, retries, cancellation, timeouts, and rate limits.
• Audit records that identify user, host, server, tool, arguments, authorization context, and outcome without leaking secrets.
• Version and deprecation strategy.
• Incident response and ownership.

27. Decision framework

Answer these questions in order.

Question 1: Will more than one host consume the capability?

• No: direct function calling remains attractive.
• Yes: MCP gains value.

Question 2: Is the capability owned by the same team as the host?

• Yes: direct integration may be simpler.
• No: an MCP boundary can clarify ownership and deployment.

Question 3: Must the capability be discovered or changed independently?

• No: inline schemas may be enough.
• Yes: MCP listing and server ownership help.

Question 4: Is the tool an internal implementation detail?

• Yes: keep it direct unless there is another reason to externalize it.
• No, it is an integration product: consider MCP.

Question 5: Is an additional runtime boundary acceptable?

• No: direct in-process functions.
• Yes: local or remote MCP may be appropriate.

Question 6: Do resources, prompts, Apps, Tasks, or protocol authorization matter?

• No: function calling may cover the need.
• Yes: MCP supplies a broader foundation.

Question 7: Does the organization need centralized server approval or gateways?

• No: either approach.
• Yes: MCP offers a more standard policy boundary, though platform features remain implementation-specific.

Question 8: Can the team operate the server securely?

A prototype wrapper may be easy to build. Production authorization, secrets, rate limits, retries, auditing, tenant isolation, schema evolution, and support are not automatic.

Decision shorthand

One app + a few internal tools
    → Direct function calling

Several apps + reusable integration
    → MCP

MCP integration selected by a model
    → MCP + native function calling

Deterministic workflow with no model decision
    → Programmatic code; MCP only if the capability boundary is useful

---

28. Frequently asked questions

The answers below cover the core comparison and the implementation questions that follow from it. They are reader-facing guidance, not a promise of search-result enhancements.

29. Recommended implementation principles

1. Name the layer in design documents. Say “model tool call,” “MCP tool,” “underlying API operation,” or “agent step,” not merely “tool.”
2. Pin the protocol revision. Do not document current MCP using a 2025 lifecycle diagram.
3. Treat schema conversion as an adapter. Test it across providers.
4. Filter before exposing. The server’s complete catalog need not become the model’s complete catalog.
5. Require approval based on real risk. Do not rely solely on annotations.
6. Preserve upstream identity intentionally. Document whether the server uses delegated users or service credentials.
7. Measure actual topology. Include tool listing, model calls, server calls, and downstream APIs.
8. Keep direct functions direct when appropriate. Standardization is not free.
9. Use explicit state handles. Do not assume current MCP supplies protocol sessions.
10. Test more than connection success. Verify auth, schemas, errors, content types, optional features, and host behavior.

---

Conclusion

MCP and function calling belong in the same architecture more often than they belong on opposite sides of a technology choice.

Function calling gives a model a structured way to request an action. MCP gives an application a standardized way to obtain and invoke capabilities from independently implemented servers. An agent loop coordinates repeated model and tool interactions. REST, GraphQL, databases, SDKs, CLIs, and local functions remain the systems that actually implement much of the work.

Direct function calling is the right answer when one application owns a few internal tools and values simplicity. MCP is compelling when capabilities must be shared, discovered, distributed, operated independently, authorized remotely, or represented with primitives beyond functions. A hybrid host can use direct functions for internal logic and MCP for reusable integrations while presenting both through one model-native tool interface.

The most important correction to current search results is historical: modern MCP is not the same session-oriented protocol launched in 2024. The 2026-07-28 revision removed the handshake and protocol sessions, formalized a stateless core, added routable and cacheable HTTP behavior, and moved major capabilities into extensions. Comparisons that ignore the protocol version are likely to misstate architecture, performance, and state.

The durable conclusion is simpler:

Function calling communicates the model’s requested action. MCP standardizes the capability boundary that can fulfill it.

---

Update log

• August 25, 2026: Initial publication against MCP 2026-07-28; normalized two unmanifested link targets, narrowed the request-metadata statement to match the current specification, and retained the original package claims in the public correction record.

Sources and methodology

Browse the unified evidence library and the editorial and update policy for source, durability, correction, and review rules.

This article prioritizes current and versioned MCP specifications, official MCP project material, current provider documentation, official SDK documentation, and primary standards sources. Current-product behavior was verified on August 25, 2026. No proprietary keyword-volume estimate or universal performance benchmark is presented.

Core sources:

• MCP tools, 2026-07-28 [S123]
• MCP base protocol, 2026-07-28 [S130]
• MCP transports, 2026-07-28 [S057]
• MCP discovery, 2026-07-28 [S127]
• MCP 2026-07-28 release [S058]
• OpenAI function calling [S169]
• OpenAI Agents SDK MCP [S090]
• Anthropic tool use [S011]
• Anthropic tool search [S174]
• Gemini function calling [S177]
• JSON-RPC 2.0 [S001]
• OpenAPI Specification [S180]