What is the difference between MCP and Function Calling? Real-world project selection, API Gateway, and compositional architecture.

The Bottom Line: They Are Not Mutually Exclusive, But Operate at Different Levels

The core difference between MCP and Function Calling is this: Function Calling addresses “how the model makes a single structured tool call,” while MCP addresses “how AI applications use a unified protocol to connect, discover, and reuse external capabilities.”

30 Quick Selection Guide

只有一个应用 + 少量固定 API
→ Function Calling

同一组工具要被多个 AI Host 复用，或需要连接文件、数据库与代码仓库
→ MCP + Function Calling

后端还涉及企业鉴权、限流、租户与审计
→ MCP Server 后面继续保留 API Gateway

Don’t migrate to MCP just because the number of tools has increased from 5 to 10. The true dividing line is whether capabilities need to be reused across clients, whether there are independent resource boundaries, and whether connection lifecycles require protocol-level management. On the model side, structured Function Calling can still be used; the Host then routes the selected actions to the MCP Client.

When you only need a single weather query, order lookup, or internal API call, Function Calling is sufficient. You provide the model with the function name, description, and JSON Schema; the model generates the invocation parameters; the application executes the function; and the result is sent back to the model.

MCP begins to demonstrate its value when your project starts requiring the following:

• The same set of tools needs to be reused by IDEs, desktop clients, internal agents, and automation systems.
• Tools are not just a set of HTTP APIs but also include local files, code repositories, SQLite, NAS, or enterprise knowledge bases.
• Different tools are maintained by different processes, teams, or services.
• Clients need to discover tools, resources, and prompts, and negotiate supported capabilities on both sides.
• Connection lifecycle management, notifications, subscriptions, and remote authentication need to be integrated into a unified protocol.

However, three boundaries must be clarified first:

1. MCP is not a sandbox by default. Servers can run as local processes or remote services, but true process isolation, file permissions, and network isolation still rely on the operating system, containers, and deployment strategies.
2. MCP does not automatically handle authorization and human confirmation. The specification requires the Host to manage permissions, consent, and authorization decisions, and recommends providing a confirmation interface for sensitive tool calls, but specific capabilities must be implemented by the product.
3. MCP does not guarantee automatic token savings. It provides mechanisms for tool and resource discovery, but how much schema and context is ultimately loaded into the model depends on the Host’s routing and context strategies.

A Table to Understand Function Calling, MCP, and API Gateway

Comparison Item	Function Calling	MCP	API Gateway
Primary Problem Solved	How models output structured tool calls	How AI Hosts connect to and discover Tools, Resources, and Prompts	How backend APIs unify authentication, rate limiting, routing, and auditing
Core Participants	Model, Application, Business Functions	Host, Client, Server	Caller, Gateway, Backend Services
Common Description Format	JSON Schema / Custom Tool	MCP Schema + JSON-RPC Messages	OpenAPI, HTTP, RPC, Gateway Policies
Tool Discovery	Provided by the application during requests or tool search phases	Client queries the Server via tools/list	Does not handle model tool discovery
Resource Model	Typically wraps data as function results	Natively distinguishes between Tools, Resources, and Prompts	Exposes only APIs, without defining model context semantics
Session & Connection	Managed by the model API and application	Client establishes stateful sessions with specific Servers	Usually handles stateless or business-layer sessions
Permission Responsibility	Implemented by the application	Layered implementation by Host, Client, and Server	Implemented by the gateway and backend services
Deployment Cost	Lowest	Moderate; requires maintaining Host/Client/Server	Medium-High; focused on service governance
Most Suitable Scenarios	Few fixed tools, single application, rapid deployment	Multi-client reuse, local resources, multi-capability servers	Enterprise services, external APIs, quota and access governance

Selection Rules: Look at Complexity First, Not Concept Hype

When to Prioritize Function Calling

When most of the following conditions are met, there is no need to build out MCP just for the sake of “architectural advancement”:

• Only one application uses these tools.
• The number of tools is small, and the interfaces are stable.
• Tools are primarily existing HTTP APIs or business functions.
• There is no need to share tools with other AI Hosts.
• The team prioritizes rapid deployment over protocol reuse.

Typical examples:

• In-app queries for weather, logistics, and orders.
• A customer service assistant calling three to five fixed business interfaces.
• Content tools invoking search, summarization, and publishing interfaces.
• A backend system prompting the model to generate structured filtering criteria.

When to Prioritize MCP

Introducing MCP yields significant benefits only when two or more of the following conditions apply:

• The same tool needs to be integrated into multiple AI clients simultaneously.
• Tools are implemented in different languages or as independent processes.
• Integration with Resources such as files, codebases, and database schemas is required.
• The list of tools changes frequently, requiring dynamic discovery by clients.
• Both local stdio and remote HTTP access modes are needed.
• Unified handling of capability negotiation, notifications, and connection lifecycles is required.

Typical examples:

• Cursor, a desktop assistant, and an internal Agent sharing the same code review tool.
• An AI Host needing to read project files within a restricted directory and NAS documents.
• Multiple departments maintaining separate financial reports, contracts, knowledge bases, and ticketing MCP Servers.
• A single Host connecting to both a local Server and remote enterprise services.

When an API Gateway Remains Indispensable

As long as the MCP Server connects to production business services, an API Gateway remains valuable for:

• OAuth or enterprise identity authentication.
• Rate limiting, quotas, and billing.
• Multi-tenant isolation.
• WAF, auditing, and request tracing.
• Backend service routing and version governance.

MCP should not bypass existing service governance. A more robust approach is to let the MCP Server act as a controlled adaptation layer, while backend APIs continue to pass through the gateway.

The Actual Call Chain of Function Calling

Taking OpenAI Function Calling as an example, the basic flow is:

1. The application provides the model with callable tools and their parameter schemas.
2. The model returns the tool call name and parameters.
3. The application validates the parameters and executes the corresponding code.
4. The application returns the tool results to the model.
5. The model generates a final response based on the results, or continues to call other tools.

用户请求
   ↓
模型判断是否调用工具
   ↓
返回 tool call + arguments
   ↓
应用校验并执行函数
   ↓
把结果返回模型
   ↓
生成答案或继续调用

The advantage of Function Calling lies in its simplicity and directness. The application retains full control over tool execution, permission checks, timeouts, retries, and result processing, eliminating the need for an additional protocol layer.

To improve parameter reliability, strict JSON Schema constraints should be prioritized. OpenAI’s official documentation recommends enabling strict mode to ensure function calls adhere as closely as possible to the provided schema. When dealing with a large number of tools, it is unnecessary to indiscriminately include all of them in every inference request: the official API provides mechanisms such as deferred tool loading, tool search, and allowed tools to narrow down the set of callable tools for the current context.

References:

• OpenAI Function Calling Guide
• OpenAI Tools Guide

The Real Architecture of MCP: The Host Is the Coordinator

MCP employs a Client-Host-Server architecture built on top of JSON-RPC.

AI Host
├── MCP Client A ── MCP Server A
├── MCP Client B ── MCP Server B
└── 模型与用户界面

Specifically:

• Host: Manages multiple Clients, model integration, context aggregation, permission policies, user authorization, and confirmation workflows.
• Client: Establishes a session with a specific Server to handle initialization, capability negotiation, message routing, notifications, and subscriptions.
• Server: Exposes focused Tools, Resources, and Prompts; it can be a local process or a remote service.

The official architecture explicitly places security policies, consent requirements, and user authorization decisions on the Host side, rather than assuming Servers are automatically secure. A single Host typically creates separate Client connections for each Server, minimizing the opportunity for Servers to directly share context.

Reference: MCP Architecture

MCP Tools: Discoverable and callable, but not automatically executable

An MCP Server that supports Tools must declare the tools capability. The Client retrieves the tool list via tools/list and then invokes tools using tools/call.

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

Tool definitions include a name, description, and input schema, and may also include an output schema. The server should validate tool inputs, enforce access control and rate limiting, and sanitize outputs; the client should display parameters for sensitive operations, request user confirmation, set timeouts, and record audit logs.

The most common misconception here is that the specification’s recommendation to provide Human-in-the-loop does not mean all MCP clients automatically implement the same confirmation flow. Products must still explicitly define which tools are read-only, which perform writes, and which require approval.

Reference: MCP Tools Specification

MCP Resources: Standardized Context, Not Automatic Disk Mounting

Resources allow servers to expose files, database schemas, or application data via URIs. Clients can use resources/list to discover resources and resources/read to retrieve their content.

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "resources/read",
  "params": {
    "uri": "file:///project/src/main.ts"
  }
}

However, Resources are application-driven: the Host determines how to present, search, filter, and incorporate them into the model’s context. The protocol does not mandate “automatically sending all discovered resources to the model.”

Subscription and resource list change notifications are also optional capabilities; they can only be used if the Server declares support for them. Therefore, you cannot treat Resources as “the model natively possessing the entire local file system.” The directories and data that are truly accessible must be constrained by a combination of Server whitelists, operating system permissions, and Host policies.

Reference: MCP Resources Specification

Is MCP More Token-Efficient Than Function Calling?

You cannot draw conclusions based solely on the protocol name.

The token cost of Function Calling depends on:

• How many tool definitions are provided to the model in the current request.
• Whether the schema is excessively long.
• Whether tool search, allowlists, and prompt caching are used.
• Whether tool results are excessively stuffed back into the context.

The token cost of MCP depends on:

• Whether the Host converts all MCP tools before passing them to the model.
• Whether tools are filtered first by Server, task, and permission.
• Whether Resources are read on demand or injected in bulk.
• Whether tool results are pruned, summarized, and structured.

Therefore, MCP’s advantage lies in providing standardized discovery and connectivity, not in guaranteeing that “schemas are transmitted only once” or that “tokens automatically drop by several orders of magnitude.” The actual cost reduction comes from routing, lazy loading, result pruning, and context governance.

Is MCP Inherently More Secure?

Again, no.

MCP provides clearer role boundaries, but security remains an engineering discipline:

Layer	Required Controls
Host	Trusted Server list, sensitive operation confirmation, context isolation, result validation
Client	Timeouts, cancellation, message validation, connection lifecycle management, and auditing
Server	Input validation, access control, rate limiting, output sanitization, least privilege
Operating System	Directory permissions, user permissions, container isolation, network egress restrictions
Remote Services	OAuth, token lifecycle management, TLS, gateway policies, and tenant isolation

Do not assume processes are inherently secure just because stdio is used, nor should you hand over OAuth tokens directly to third-party Servers when using remote MCP. Untrusted Servers should be placed in isolated users, containers, or sandbox environments, with write operations disabled by default.

The Most Robust Combined Architecture

Real-world projects do not need to choose exclusively between MCP and Function Calling. A common approach is to combine them:

用户
  ↓
AI Host / Agent Runtime
  ↓
模型选择工具（Function Calling）
  ↓
Host 路由到 MCP Client
  ↓
MCP Server
  ↓
API Gateway / 数据库 / 文件系统 / SaaS

In this architecture:

• Function Calling handles structured selection on the model side.
• MCP provides standardized connectivity between the Host and capability servers.
• API Gateway manages formal backend service governance.
• Host connects user permissions, model decisions, and server capabilities.

This approach aligns better with production system layering principles than “migrating everything to MCP.”

How to Choose for Three Specific Scenarios

Scenario 1: In-app Weather and Order Queries

Choice: Function Calling.

Reasoning: With few tools, fixed interfaces, and a single app target, you can handle parameter validation, user authentication, and API calls directly within the application. This minimizes complexity.

Scenario 2: Shared Code Tools for IDEs, Desktop Assistants, and Internal Agents

Choice: MCP + Function Calling.

Reasoning: Capabilities like code search, file reading, and test execution need to be reused across multiple Hosts. An MCP Server provides unified capabilities, while the Host decides which tools are exposed to the model.

Scenario 3: Enterprise Financial Report Analysis and Internal Data

Choice: MCP + API Gateway + Human Approval.

Reasoning: The MCP Server standardizes financial report parsing, knowledge bases, and audit tools. The API Gateway handles identity, quotas, and auditing. For write operations, exports, and sensitive data access, the Host initiates a confirmation step.

Migration Path from Function Calling to MCP

Avoid refactoring all tools at once. Follow this sequence for a more stable transition:

1. Audit existing tools to map callers, permissions, and data sources.
2. Keep simple, single-application tools under Function Calling.
3. Select a group of read-only tools that genuinely require cross-client reuse and implement them as an MCP Server.
4. Configure the Server with directory whitelists, input validation, timeouts, and audit logging.
5. Establish a trusted Server allowlist and sensitive operation confirmation policies within the Host.
6. Handle remote authentication, OAuth, and API Gateway integration.
7. Finally, migrate high-risk tools such as file writing, command execution, and production data modification.

Common Mistakes

Mistake 1: Treating MCP as a New Model Tool Call Format

MCP does not replace Function Calling in the model API. It defines the protocol connection between the Host, Client, and Server. The Host must still present available capabilities in a format the model understands.

Mistake 2: Treating MCP Servers as Security Sandboxes

A Server is merely an independent capability provider. Its isolation depends on process users, containers, directory permissions, and network policies—not the protocol name.

Mistake 3: Exposing All Server Tools to the Model

This recreates problems related to excessive tool counts, similar descriptions, and context bloat. The Host should filter tools based on the task, user permissions, and server trust levels.

Mistake 4: Using MCP to Bypass Existing Backend Authentication

MCP Servers should not hold unconstrained superuser privileges. Accessing enterprise APIs must still go through OAuth, API Gateways, tenant isolation, and auditing.

Mistake 5: Automatically Flooding Context with Resources

Resources should be read on demand. List directories and metadata first, then read only what is necessary. For large files, use pagination, chunking, or retrieval-based location to avoid injecting everything at once.

Final Decision Matrix

Your Project Context	Recommendation
A single application with a fixed number of APIs (1–5)	Function Calling
A single application with many tools, but all maintained in the same codebase	Function Calling + tool search / allowlist
Multiple AI clients sharing the same set of capabilities	MCP
Need standardized access to files, codebases, and database schemas	MCP Resources / Tools
Formal enterprise APIs, quotas, tenants, and audit trails	API Gateway, optionally extended with MCP
High-risk write operations or command execution	Both MCP and Function Calling require approval workflows and least-privilege enforcement
Want to reduce token costs	Prioritize tool filtering, lazy loading, and result truncation; don’t rely solely on protocol switching

Next Steps

• MCP Deep Dive: From Protocol Boundaries to Production Governance
• MCP Protocol Guide: Understand Boundaries Before Integrating Tools
• MCP Combined Architecture with Function Calling and API Gateways
• MCP vs. Semantic Kernel: Protocols, Plugins, and Agent Orchestration
• MCP OAuth Authentication: How Remote Servers Handle Authorization
• MCP Server Production Governance: Permissions, Auditing, and Lifecycle
• MCP Security Best Practices: allowedRoots, Least Privilege, and Prompt Injection

Topic path / MCP

Continue from protocol details to production MCP governance

The MCP hub connects protocol fundamentals, transports, authentication, security, JSON-RPC debugging and production deployment without splitting the search intent across isolated guides.

Open MCP hub → Review the security checklist Subscribe for updates