I Thought MCP Was Just Another Name for Function Calling. I Was Wrong.

⋅

For a while, I kept running into the same cluster of terms: function calling, API calls, MCP servers, and MCP protocol. Every explanation I found seemed to assume I already knew what all of them meant. One article would explain MCP using APIs. Another would explain APIs using function calling. A third would explain function calling using tools. After a while, all the definitions started sounding circular.

I thought MCP was just another name for function calling.

It turns out they’re related, but they’re solving completely different problems.

The explanation that finally made everything click came from a completely unexpected place: Uber Eats.

Start with the simplest thing: a function

A function is just a piece of code that performs a task. You give it some input, it does some work, and it returns an output.

def get_weather(city):
    return "72°F, sunny"

In a real implementation this would call a weather API, but the point is the structure: input goes in, result comes out.

If you call get_weather(“New York”), you get a result back. That’s all a function is. Nothing mysterious. Most software is built on top of thousands of functions talking to one another. Whether you’re calculating a total on an e-commerce website, checking your bank balance, or displaying today’s weather, functions are doing the work behind the scenes.

An API is just a function that lives on someone else’s computer

Now imagine that same weather function isn’t running on your laptop. Instead, it’s running on a weather company’s server somewhere on the internet. Your application sends a request, their server runs the function, and the result comes back. That’s an API call.

When developers say “call the weather API,” what they really mean is “ask another computer to run a function and return the result.”

The API defines the rules for that interaction. What information do you need to send? What format will the response come back in? How are errors handled? Those rules together form the API contract. Think of it as the restaurant’s ordering interface, the specific rules for how you place an order with that particular kitchen.

Function calling gives LLMs access to tools

Normally, an LLM can only do one thing: read text and generate text. It can’t check your calendar, query a database, send a Slack message, or look up today’s weather. It just talks.

Function calling changes that. Instead of only giving the model a prompt, you also give it a list of tools it’s allowed to use, things like get_weather(city), send_email(recipient, subject, body), or search_database(query). When a user asks a question, the model reasons about whether one of those tools would help.

The important detail is that the model doesn’t actually execute the code itself. It says, “I’d like to call get_weather(“New York”)” and your application executes the function, gets the result, and sends it back. The model then uses that information to generate its final response.

Function calling flow diagram

The problem function calling doesn’t solve

Function calling works extremely well when you’re building a single application. You define your tools, wire them in, and you’re done.

But imagine you’re a large company building multiple AI products, a coding assistant, a research assistant, an analytics assistant, a customer support assistant. All of them need access to the same systems. GitHub, Slack, internal documentation, databases. Without a shared standard, every team ends up building the same integrations repeatedly. One team builds a GitHub connector. Another team builds a different GitHub connector. A third team builds yet another one. As the number of applications grows, the amount of duplicated work grows with it.

This is the problem MCP was designed to solve.

The Uber Eats analogy that made everything click

Think about how Uber Eats works. There are thousands of restaurants on the platform. You open the app, browse what’s available, place an order, and the food arrives. Now imagine a new restaurant joins. You don’t update the app, reinstall anything, or download a new version. The restaurant simply appears because Uber Eats has a standard that every restaurant follows to join the platform. Publish your menu, accept orders, and return updates. Do those three things, and you’re in.

Uber Eats Analogy Visually

MCP works in the same way. Claude is the Uber Eats app, the thing receiving your request and deciding what needs to happen. MCP servers are the restaurants, each one providing capabilities: one connects to GitHub, another to Slack, and another to a database. Functions are the dishes on the menu. Function calling is placing the order. The result is the food arriving. And MCP itself is the platform, the standard that lets any new tool join and immediately be available to Claude, without anyone rebuilding anything.

Before MCP vs After MCP

MCP standardizes how AI uses tools.

Before MCP, every application maintained its own set of integrations. With MCP, tools become shared infrastructure. Build once, use everywhere. That’s the real value proposition.

So where does the API fit?

Uber Eats doesn’t build its own maps. When you track a delivery, it’s calling Google Maps’ API. When you pay, it’s calling Stripe’s API. Uber Eats is the platform, but underneath, it’s relying on a whole set of other services to do the actual work.

MCP works the same way. A GitHub MCP server doesn’t reimplement Git; it calls GitHub’s API. A Slack MCP server doesn’t build its own messaging system; it calls Slack’s API. MCP is the platform layer that standardizes how AI applications discover and use tools. The APIs are the underlying services those tools rely on to get things done.

Where API sits in this stack?

A simple way to think about it: APIs define how a specific service works. Function calling allows an LLM to use tools. MCP provides a standard way for tools to be exposed across many AI applications. They’re complementary concepts, not competing ones.

When should you use MCP?

The practical answer is simple. If you’re building a single application with a handful of tools, plain function calling is usually enough. It’s simpler, easier to manage, and introduces less infrastructure.

MCP becomes valuable when tools need to be shared across multiple applications or maintained by different teams. If one team owns a GitHub integration and five product teams need access to it, MCP allows that integration to be maintained once and reused everywhere. Improvements made by the platform team become available to every application automatically.

Function calling is for individual applications. MCP is for shared infrastructure.

Why this matters right now

The AI industry is moving toward ecosystems rather than standalone applications. Companies don’t want a single AI assistant anymore; they want coding assistants, analytics assistants, research assistants, customer support assistants, and internal knowledge assistants. The challenge is no longer just building the model. The challenge is connecting those models to the systems where work actually happens.

MCP isn’t replacing APIs. It isn’t replacing function calling. It’s creating a standard way for AI applications and tools to communicate, the same thing Uber Eats did for food delivery. Before Uber Eats, if you wanted delivery from a new restaurant, someone had to build a whole new app. Uber Eats made that unnecessary. MCP does the same thing for AI tools.

That’s how I think about MCP today. Not another name for function calling. The standard layer that makes large-scale tool ecosystems possible.

And once I saw it that way, the entire MCP ecosystem finally made sense.

I’m building AI engineering projects and writing about what I learn along the way. If you’re exploring agents, MCP, RAG, and modern AI systems, I’d love to connect.

I Thought MCP Was Just Another Name for Function Calling. I Was Wrong. was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Liked Liked