MCP vs. Function Calling: How Customers and Teams Can Self-Serve Without Engineers

You Will Learn:You Will Learn:You Will Learn:

1. How MCP servers (like Google Ads MCP) let customers use services directly from AI interfaces without coding.
2. How internal teams can self-serve information through MCP, reducing reliance on engineers.
3. The basics of Function Calling and MCP — what they are and how they work.
4. The key differences between Function Calling and MCP, and what changes when customers implement tools themselves.
5. The main limitations and challenges of adopting MCP in real-world systems.

Modern AI applications often need to interact with external tools, APIs, and data sources. These systems usually involve two key components:

• The LLM (Large Language Model) — the reasoning engine that interprets user input and generates structured instructions or text responses (e.g., ChatGPT-4.1, Claude Sonnet, Gemini 2.5, Qwen 3).
• The LLM Controller Layer — the software layer that connects to the LLM via API, manages conversation state, and orchestrates tool or API execution. Controllers include applications such as ChatGPT web app (chat interface), OpenWebUI, Claude Desktop, Cursor IDE, and Claude Code.

The LLM itself never executes code or calls APIs directly. It only suggests what should happen. The controller interprets those suggestions and decides how and when to carry them out.

Two complementary mechanisms enable this collaboration:

1. Function Calling – the foundational mechanism where the LLM suggests structured function calls that the controller executes.
2. Model Context Protocol (MCP) – an open infrastructure standard built on top of function calling that allows the LLM controller to dynamically discover and connect to tool servers.

This tutorial explains both concepts, how they relate, and when to use each.
 

Function Calling

Function calling allows a model to suggest a structured function call (function name and arguments), while the LLM controller executes it.
The LLM model never runs code or calls APIs. It simply proposes what function to call and with what arguments. The controller interprets those suggestions, and performs the actual execution.
 

Process Overview

1. Function Definition: You provide the model with a list of available functions, typically defined in JSON schema format that includes:

• Function name
• Description of what the function does
• Parameters it accepts (with types and descriptions)
• Expected return format

You provide this list as a separate structured API parameter (e.g., tools parameter in OpenAI or Anthropic APIs), and you include it in every API request. For example, you might describe a list of functions like get_weather, get_traffic_status, send_email, etc.

This is like giving the model a "menu" of capabilities—you're describing what's possible, not executing anything yet.

2. Model Analysis: When the user sends a message (e.g., "What's the weather in London?"), the model inspects the available function definitions and determines whether external data is needed.

3. Tool Call Suggestion: The model emits a structured "call" containing:

• The function name it wants to call (e.g., get_weather)
• The arguments to pass (e.g., {"location": "London, UK", "units": "celsius"})
• This is formatted according to the LLM provider's specific schema (OpenAI, Anthropic, etc.)

This is only a suggestion, not actual execution. The model is saying “I think you should call this function with these parameters.”

4. Controller Execution: Your LLM controller receives this suggestion, parses it, and runs the actual function implementation. This might involve:

• Calling external APIs (weather services, databases)
• Performing computations
• Accessing file systems or other resources

The controller is responsible for error handling, authentication, security, and returning valid results

5. Result Formatting: The controller returns the function output to the model as a message with a special role (tool or function).

6. Final Response: The model receives the tool result, incorporates it into its context, and generates a natural language response for the user: "The current weather in London is partly cloudy with a temperature of 15°C."

Model Context Protocol (MCP)

Model Context Protocol is an open standard (created by Anthropic) that defines a client–server protocol for connecting AI models to external tools and data sources in a unified, scalable way.

Core Components

• MCP Server: Hosts tools that can complete certain tasks upon called. Example: A server exposing a get_orders tool that returns a customer’s last five orders. 
• MCP Client: Integrated into the LLM controller. The client:
  • Connects to one or more MCP servers
  • Discovers available tools dynamically
  • Routes tool calls to the correct server
  • Manages the communication between the model and tools

Example: Google Ads Tools

Let us consider another example but this time let us take a real meaningful example. Google recently enabled an Google Ad MCP server for marketers exposing tools such as: execute_gaql_query, get_campaign_performance, get_ad_performance. 

Let’s compare what engineers would need to do with and without MCP.

Without MCP (Using Function Calling)

With MCP

If OpenWebUI uses Google’s MCP server, Step 0 changes entirely:

The engineering team would not need to create functions as in the Step 0 of the above table. Instead the step 0 will replaced with the step 0 in the table given below.

Adaptation for ChatGPT Custom GPTs

If using ChatGPT's chat interface with custom GPTs instead of OpenWebUI, the core flow remains the same but the function execution mechanism differs significantly:

• Step 1 would involve defining "Actions" (OpenAI's term for external API integrations) in the custom GPT configuration using OpenAPI schema, rather than loading internal plugins. These Actions point to external API endpoints that you host or subscribe to.
• Step 10 changes fundamentally: Instead of executing functions internally, ChatGPT makes an HTTP POST request to your external API endpoint (e.g., https://your-api.example.com/campaign-performance). The request includes the function arguments as JSON in the request body, along with any required authentication headers (API keys, OAuth tokens).
• Step 11 would involve your external API server receiving the HTTP request, authenticating, querying the Google Ads API, processing the data, and returning an HTTP response with the campaign data in JSON format.

The key architectural difference: OpenWebUI executes functions in its own runtime environment (internal plugins), while custom GPTs delegate function execution to external API services via HTTP. Despite this difference, the conversation flow, message array structure, and ChatGPT's role in determining when to call functions and synthesizing responses remains identical. This same pattern applies to other platforms like Anthropic's Claude with tool use, Microsoft Copilot Studio, or any LLM controller supporting function calling.
 

Why Offer an MCP Server to Your Customers?

Providing your own MCP server — instead of letting customers build functions using your APIs — drastically lowers technical barrier for your customers, improves integration efficiency and user experience.

From a service-provider perspective:
 

• MCP servers make it dramatically easier for customers to use your services without requiring engineering resources.
• Customers save cost and effort, and are more likely to rely on your managed tools long-term.
• MCP doesn’t replace your APIs — advanced users will still build on your raw endpoints for custom workflows.
• You’ll incur extra cost maintaining both APIs and the higher-level workflows your MCP server exposes.

In short, Function Calling gives developers maximum flexibility, while MCP delivers scalable, frictionless integration for the broader market. The two approaches complement each other — not compete.

Empowering Non-Technical Teams Through MCP

One of the most powerful outcomes of adopting MCP is how it democratizes access to AI-driven automation and data workflows.
In a typical organization today, tasks like querying analytics data, checking campaign performance, or triggering system actions require help from engineers or data teams. With MCP:

• Business, marketing, and operations staff can interact with AI tools directly — no coding, SDKs, or API knowledge needed.
   
• Tools are predefined, validated, and centrally managed by technical teams, so non-technical users can safely use them via natural-language prompts.
   
• Each department (marketing, sales, HR, finance) can have its own MCP servers exposing relevant workflows — like get_campaign_metrics, fetch_invoice_status, or generate_hiring_summary.
   
• Because MCP tools are discoverable at runtime, employees can explore capabilities dynamically instead of depending on documentation or custom dashboards.
   

This model effectively turns AI chat interfaces (like ChatGPT, Claude Desktop, or OpenWebUI) into functional copilots for every role — built on a controlled, maintainable backend infrastructure.

From a business perspective:

• It cuts down support and ticket volume to engineering.
• Speeds up decision-making.
• Keeps compliance and data access under centralized governance.

Limitations and Challenges of MCP

1. Ecosystem Maturity
   MCP is still very new (originating from Anthropic). Only a few LLM controllers currently support it natively. Most integrations are experimental or rely on unofficial client libraries.
2. Implementation Complexity
   Hosting an MCP server isn’t trivial — you have to build a compliant JSON-RPC API layer, handle schema validation, manage authentication, and keep everything performant under real-time chat loads.
3. Security & Access Control
   Because MCP servers expose powerful tools directly to models, misconfigured endpoints can leak or damage data. Authentication, rate limiting, and scoped permissions must be airtight.
4. Performance Overhead
   The extra layer of indirection (client ↔ server ↔ model) can add latency. For high-frequency tool calls, this can become noticeable, especially over WebSocket or HTTP when many tools are being registered dynamically.
5. Limited Standardization Across Vendors
   While MCP defines the protocol, each vendor interprets it slightly differently. Tool discovery, auth schemes, and schema conventions aren’t always 100% compatible between OpenAI, Anthropic, or local controller ecosystems.
6. Debugging & Observability Gaps
   Unlike traditional function-calling setups where you control both ends, MCP often spans multiple systems. That makes debugging harder — logs, tracing, and error visibility can be fragmented across the LLM controller, MCP client, and the tool server.

About the Author

Dr. Rohit Aggarwal is a professor, AI researcher and practitioner. His research focuses on two complementary themes: how AI can augment human decision-making by improving learning, skill development, and productivity, and how humans can augment AI by embedding tacit knowledge and contextual insight to make systems more transparent, explainable, and aligned with human preferences. He has done AI consulting for many startups, SMEs and public listed companies. He has helped many companies integrate AI-based workflow automations across functional units, and developed conversational AI interfaces that enable users to interact with systems through natural dialogue.