Skip to main content

MCP vs API: What's the Difference and When to Use Each

Short answer

MCP is a protocol that lets an AI app find and call tools on a server. A plain API is an interface your code calls directly. Function calling is the feature a model API uses to ask your application to run one of your functions. They usually work together rather than compete: an MCP server often calls a REST API behind the scenes, and the AI app uses function calling to run the MCP tools. Call the API directly when no model is involved, use function calling when one app is the only consumer, and use MCP when other AI apps or other people need the same tools.

Tested withMCP spec 2026-07-28Checked 20 Oct 2026

By Tony LewisHow we test these guides

The short version​

Plain APIModel function callingMCP
What it isEndpoints your code calls over HTTPA feature of a model API. The model returns a request to run a function you definedAn open protocol. A server publishes tools, resources and prompts, and an AI app connects to it
Who runs the callYour codeYour application runs the function and sends the result back to the modelThe AI app sends tools/call to the server, and the server runs the tool
Where the tool definitions liveIn the API's documentation, which a developer readsIn your application code, sent with each model requestOn the server. The app fetches them at runtime with tools/list
Who can use itAnyone whose code calls itThe one app that defines the functionsAny AI app that speaks MCP can connect to the same server
Extra featuresWhatever the API offersTools onlyTools, resources and prompts
Sign-inWhatever your code does, such as an API keyWhatever your code doesRemote servers use OAuth. MCP recommends it for getting tokens

The model never calls an API or an MCP server directly. Here is the path a tool call takes when you use MCP:

The MCP architecture overview describes the same loop. When the model decides to use a tool, the AI application routes the call to the right MCP server, runs it, and gives the result back to the model. MCP covers the protocol between the app and the server. It doesn't decide how the app uses the model or manages the conversation.

What MCP adds over a plain API​

A plain API leaves the developer to read the docs and write code for each endpoint. An MCP server describes each tool in the protocol itself, and the AI app reads that description when it connects. The app asks for the list with tools/list. Each tool comes back with a name, a description and an inputSchema that the model uses to fill in arguments:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "resultType": "complete",
    "tools": [
      {
        "name": "weather_current",
        "title": "Weather Information",
        "description": "Get current weather information for any location worldwide",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name, address, or coordinates (latitude,longitude)"
            },
            "units": {
              "type": "string",
              "enum": ["metric", "imperial", "kelvin"],
              "description": "Temperature units to use in response",
              "default": "metric"
            }
          },
          "required": ["location"]
        }
      }
    ],
    "ttlMs": 300000,
    "cacheScope": "public"
  }
}

The example above is trimmed from the architecture overview, which lists a second tool in the same response. ttlMs is a freshness hint, so the app can keep this list for five minutes before asking again.

Three things follow from that shape:

  • The server owns the description. When the server changes a tool, the next tools/list returns the change. You don't redeploy the apps that use it.
  • The transport is standard. A local server runs over stdio, with the app starting it as a child process. A remote server runs over Streamable HTTP. The JSON-RPC messages are the same in both cases.
  • Any MCP host can connect. The intro documentation lists Claude, ChatGPT, Visual Studio Code and Cursor among the apps that support MCP.

What MCP adds over function calling​

Function calling is built into the model API. You declare each function in the request, and the model replies with a call to one of them. Here is the OpenAI function definition for a get_weather function, from the OpenAI guide:

{
  "type": "function",
  "name": "get_weather",
  "description": "Retrieves current weather for the given location.",
  "parameters": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "City and country e.g. Bogotá, Colombia"
      },
      "units": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"],
        "description": "Units the temperature will be returned in."
      }
    },
    "required": ["location", "units"],
    "additionalProperties": false
  },
  "strict": true
}

The OpenAI guide says functions are usually declared in the tools parameter of each request, and that your application must execute each call and return the result. The definition lives in your code and travels with every request. Anthropic's tool use overview works the same way: you pass a tool with an input_schema, and your application runs the call when Claude returns a tool_use block.

MCP uses the same idea of a name, a description and a JSON Schema for the inputs. The difference is where the definition lives. With MCP the server holds it and the app discovers it, so the same definition works in any MCP host. Function calling only works in the app that declares it, and each model provider has its own request format.

Two model providers now connect to MCP servers themselves. The OpenAI guide lists access to an MCP server among its built-in tools. Anthropic's MCP connector lets the Messages API connect to remote MCP servers without a separate MCP client. In both cases the model provider's platform handles the MCP connection for you.

Do you need MCP, function calling or neither?​

Answer these questions in order. The first yes tells you where to start.

QuestionIf yesIf no
Is there a model in the loop at all?Go on to the next questionCall the API directly from your code. Nothing else is needed
Is one app, with one model, the only thing that calls these tools?Use function calling in that appGo on to the next question
Do other AI apps, or other people's apps, need the same tools?Build an MCP serverUse function calling
Do you want to use a service that already runs its own MCP server?Connect an MCP client to itBuild what you need
Do the tools need to be discovered at runtime, or change while the app runs?MCP. The server can notify clients when its tool list changesFunction calling is enough
Does each user need to sign in with their own account?MCP with a remote server, which uses OAuthYour code can handle the credentials

Some points that trip people up:

  • MCP doesn't replace the API. An MCP server usually sits on top of an API and still makes the API calls. You keep the API.
  • MCP isn't limited to one AI app. The protocol is open. Connecting an app to a server is a configuration step in that app.
  • Function calling and MCP aren't alternatives in the same slot. An app can use function calling to run an MCP tool. The model doesn't need to know which one it is.
  • A connected server doesn't mean silent tool calls. The MCP tools specification says there SHOULD always be a human in the loop who can deny a tool call. Whether an app asks you each time depends on the app.

What changed recently​

  • MCP spec 2026-07-28. The protocol is now stateless. The initialize handshake is gone, each request carries its protocol version and client capabilities, and every server answers server/discover. Remote servers use Streamable HTTP.
  • Some features are deprecated. The 2026-07-28 changelog deprecates Roots, Sampling and Logging, and the HTTP+SSE transport. New servers should use Streamable HTTP and should not add the deprecated features.
  • Function calling can defer tools. OpenAI's tool search loads rarely used functions only when the model needs them. The OpenAI guide says only gpt-5.4 and later models support it.

How to do each option​

  • Build an MCP server. The build an MCP server guide writes a working server in Python or TypeScript and connects it to an AI app.
  • Connect an existing MCP server. The MCP clients guide lists the AI apps that connect to MCP servers and links to each setup guide.
  • Use function calling. Follow the OpenAI function calling guide or the Claude tool use overview. Both cover how your application runs the calls and returns the results.
  • Call the API directly. Use the service's own documentation. No MCP layer is needed.

FAQ​

Is MCP replacing REST APIs?

No. An MCP server is an AI-facing layer that usually calls a REST API or another service behind the scenes. The API still does the work, and MCP describes which parts of it the model can use.

Is MCP the same as function calling?

No. Function calling is a feature of a model API that lets the model request a function call. MCP is a protocol for connecting an app to a server that offers tools. An app can use function calling to run MCP tools, so the two usually work together.

When should I skip MCP and use function calling?

When one app and one model are the only things that need the tools, and the tools live inside that app. Function calling needs no separate server, so there is less to run and maintain.

Can a model use an MCP server without a separate MCP client?

Some model APIs connect to remote MCP servers for you. Anthropic's MCP connector on the Messages API is one example, and the OpenAI guide lists access to an MCP server among its built-in tools.