MCP, APIs and function calling, untangled.

MCP does not replace APIs or function calling. They are three layers of one stack. An API is how programs talk to a service. Function calling, also called tool use, is how a model asks your code to run a named action. MCP, the Model Context Protocol, is a shared standard that lets any AI app discover and run those actions on outside servers, which usually call an API underneath.

We traced one request through all three layers with a small weather API, an MCP server and a test app, and this guide shows the real JSON at each step. Then it compares MCP vs API vs function calling side by side and explains when an MCP server is worth building.

01What is an API?

An API (application programming interface) is the set of requests a service accepts from other programs, and the answers it sends back. Most web APIs take an HTTP request and return JSON. Each service designs its own, so every integration is written by hand against its docs.

Here is our toy weather API, called directly:

curl -s "http://127.0.0.1:8787/v1/forecast?city=Lisbon"

{"city":"Lisbon","tomorrow":{"high_c":24,"low_c":17,"summary":"Sunny"}}

No AI is involved. Any program that knows the URL and the parameters gets the data.

02What is function calling?

Function calling is a model’s ability to answer with a request to run a tool instead of with text. You send the model a list of tools, each with a name, a description and a JSON Schema for its inputs. When a tool fits the task, the model returns its name and arguments, your code runs it, and you send the result back.

Anthropic calls this tool use and returns a tool_use block. OpenAI calls it function calling and returns a function_call item with the arguments as a JSON string. For tools you define, the model never runs anything itself: your code does. Our guide to building your first AI agent writes that loop in about 100 lines.

03What is MCP?

MCP is an open protocol that standardizes how AI apps connect to tools and data. A server publishes its tools once, and any MCP-capable app, such as Claude, ChatGPT, Cursor or VS Code, can list them and call them. Messages are JSON-RPC 2.0, sent over standard input and output for local servers or over HTTP for remote ones.

Under the current spec, version 2026-07-28, every request stands on its own with no handshake first. This is one real tools/call message we typed into our test server, and its reply, formatted for reading:

{
  "jsonrpc": "2.0", "id": 1, "method": "tools/call",
  "params": {
    "name": "get_forecast",
    "arguments": { "city": "Lisbon" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {},
      "io.modelcontextprotocol/clientInfo": { "name": "by-hand", "version": "1.0.0" }
    }
  }
}

{
  "result": {
    "content": [{ "type": "text", "text": "Lisbon tomorrow: Sunny, 17 to 24 C" }],
    "resultType": "complete",
    "_meta": { "io.modelcontextprotocol/serverInfo": { "name": "weather", "version": "1.0.0" } }
  },
  "jsonrpc": "2.0", "id": 1
}

For the basics, see what MCP is. To write a server yourself, follow our MCP server tutorial.

04Is MCP just an API?

No. An API belongs to one service and is built for programmers who read its docs. MCP is a protocol that every tool server speaks the same way, built for AI apps that discover tools while they run. Most MCP servers are thin wrappers: our get_forecast tool is a few lines that call the weather API and turn the answer into text a model can read.

MCP adds three things on top of a plain API. Discovery: the app asks the server what it offers. One format for every tool, whoever wrote it. And an optional sign-in flow for remote servers, built on OAuth 2.1. Servers can also offer resources to read and prompt templates to pick, not only actions.

05What is the difference between MCP and function calling?

Function calling is how the model chooses a tool; MCP is how the app finds tools and runs them. They meet in the app. It converts each MCP tool into a function-calling definition for its model, and turns each tool call from the model into an MCP request.

Our trace shows how close the two formats are. The name, description and schema that came from the MCP server became the tool definition for Anthropic’s API almost unchanged: we dropped the display title and renamed one field, inputSchema to input_schema.

06How MCP, APIs and function calling work in one request

Here is one question, “What’s the weather in Lisbon tomorrow?”, traced through our test setup: the toy API, an MCP server wrapping it, and a small app. Everything is real output from Node.js 26 and the official MCP SDK 2.0.0, except the model’s reply, which we faked because it needs an API key.

1. 01

   The app asks the MCP server what it offers

   The app sends tools/list and gets back each tool’s name, description and input schema:

   {
     "name": "get_forecast",
     "title": "Get forecast",
     "description": "Get tomorrow's weather forecast for a city.",
     "inputSchema": {
       "$schema": "https://json-schema.org/draft/2020-12/schema",
       "type": "object",
       "properties": {
         "city": { "type": "string", "minLength": 1, "description": "City name, for example Lisbon" }
       },
       "required": ["city"]
     }
   }

2. 02

   The app hands those tools to the model

   It converts them into the model API’s tool format and sends them along with your question. For Anthropic’s Messages API, it keeps the name and description and renames inputSchema to input_schema.

3. 03

   The model answers with a tool call

   Instead of text, the model replies with the tool and the arguments it wants:

   { "type": "tool_use", "id": "toolu_demo_1", "name": "get_forecast", "input": { "city": "Lisbon" } }

4. 04

   The app runs the call through MCP

   It sends tools/call to the server. The server calls the REST API and returns Lisbon tomorrow: Sunny, 17 to 24 C.

5. 05

   The result goes back to the model

   The app wraps the text in a tool_result block with the same ID, toolu_demo_1, so the model can write the final answer in plain words.

Steps two, three and five are function calling. Steps one and four are MCP. The API only appears inside step four, behind the server. That is the whole difference.

Some model APIs can take over the MCP steps. Anthropic’s MCP connector, in beta, and OpenAI’s Responses API accept a remote MCP server’s URL and call its tools themselves. Both need a server that is publicly reachable over HTTP, so a local stdio server still needs an app in between.

07MCP vs API vs function calling compared

Checked against the MCP specification (2026-07-28) and Anthropic’s and OpenAI’s docs on September 28, 2026:

08When should you build an MCP server instead of calling an API?

Build an MCP server when you want your tools to work in AI apps you do not control; call the API directly when you are building one app with a fixed set of tools. These questions settle most cases:

• Who will use it? If other people’s agents in Claude, ChatGPT, Cursor or VS Code should use it, build an MCP server. If only your own app will, function calling over your API is simpler, with one less process to run and secure.

• Does each person sign in? Remote MCP servers have a standard OAuth-based sign-in, so every user connects with their own account and scopes.

• How many tools? Every tool’s name, description and schema goes to the model with each request and counts as input tokens. Dozens of servers add up. Anthropic, for one, offers a tool search tool that loads tools on demand.

• Do agents need to talk to each other? That is a different job. A2A connects agents to other agents, while MCP connects agents to tools.

Before you publish a server, pick good examples to copy from the best MCP servers, and read the MCP security risks, because every server is also a way into someone’s agent.

09FAQ

Read next: how AI agents talk to each other with A2A, or build an MCP server in 30 minutes.