This article is based on MCP Specification 2025-11-25, which was marked as the latest version on July 13, 2026.
If you use ChatGPT, Claude, Codex, Cursor, or a similar AI application, you have probably encountered the term “MCP.” At first glance, however, MCP can seem redundant. If an AI application can already call a REST API through function calling, why introduce another technology?
Is MCP a new kind of API? Is it a replacement for function calling?
The short answer is that the three operate at different layers.
A REST API exposes a system’s capabilities, function calling lets a model choose a capability, and MCP standardizes how AI applications connect to external systems.
MCP does not replace APIs or function calling. This article uses a GitHub Issue search-and-create integration to explain how they fit together and when an MCP server is worth building.
The problem MCP is designed to solve
An LLM cannot operate external systems by itself
An LLM can generate a response from its input, but the model alone cannot query a database, create a GitHub Issue, or update an internal calendar.
The surrounding AI application therefore needs integration code. For GitHub, that code must manage credentials, send requests to the GitHub API, and transform responses into a form the model can use.
More AI applications and services mean more custom integrations
Imagine connecting an AI chat application, a coding agent, and an internal assistant to GitHub, a database, an internal API, and local files.
Without a shared standard, each combination may need its own tool definitions, connection logic, result conversion, and error handling.
Without MCP
AI application A ── custom integration ── GitHub
AI application A ── custom integration ── Database
AI application B ── custom integration ── GitHub
AI application B ── custom integration ── DatabaseMCP addresses this fragmented integration layer. By defining a common contract between AI applications and external systems, it makes one capability easier to reuse across multiple MCP-compatible applications.
What is MCP?
MCP, or the Model Context Protocol, is an open protocol for connecting AI applications to external data, tools, and workflows. The official introduction compares it to USB-C: a common connection standard that works across different devices. Official MCP introduction
In beginner-friendly terms:
MCP is a shared set of rules for exposing and using data and capabilities in a format AI applications understand.
MCP communication is based on JSON-RPC 2.0. The protocol defines connection initialization, protocol-version and capability negotiation, feature discovery, invocation, results, and notifications. A server can expose three primary kinds of features. MCP Specification 2025-11-25
- Tools: operations the AI can invoke, such as creating an Issue or querying a database
- Resources: data that can be used as context, such as files or database records
- Prompts: reusable message and workflow templates
MCP is neither an AI model nor a business API. It is a layer for presenting existing APIs, databases, and local programs through a consistent AI-facing interface.
MCP hosts, clients, and servers
MCP separates the system into three roles: host, client, and server. In the official architecture, a host creates an MCP client for each server, and each client maintains a connection to its corresponding server. MCP architecture overview
MCP host
The MCP host is the AI application the user interacts with. Examples include chat applications, IDEs, and coding agents.
In addition to managing the conversation and invoking the LLM, the host manages MCP clients, passes information from servers to the model, and controls whether tool execution is approved.
MCP client
An MCP client is a component inside the host that communicates with a particular MCP server.
A common source of confusion is calling the entire user-facing application the client. In MCP terminology, the application is the host; the connector that maintains the server connection is the client. Typically, one client maintains a dedicated connection to one server.
MCP server
An MCP server is a program that exposes data and capabilities in MCP format.
You might create a server that searches and creates GitHub Issues, queries an internal database, or reads local files. Behind the MCP interface, the server can continue to use an existing REST API or database client.
User
↓
MCP Host
├── MCP Client A ── MCP Server A ── GitHub API
├── MCP Client B ── MCP Server B ── Database
└── MCP Client C ── MCP Server C ── Local FilesDespite its name, an MCP server does not have to be a standalone web server on the internet. MCP servers can run as local processes or as remote services accessed over a network.
MCP vs. REST APIs
A REST API exposes system capabilities
A REST API gives web, mobile, backend, and other applications access to a system’s data and operations.
A program using the GitHub API needs to understand its endpoints, HTTP methods, authentication, and request and response formats. None of this is specific to AI.
MCP standardizes an AI-facing connection
An MCP server exposes tools and resources to AI applications in a shared format. After connecting, a client can use methods such as tools/list to discover the capabilities available from that server.
The MCP server does not need to own all the underlying business logic. It can act as an adapter around an existing REST API.
AI application
↓ MCP
MCP Server
↓ HTTP
GitHub REST APIPerspective | REST API | MCP |
|---|---|---|
Primary purpose | Expose system data and operations | Provide context and tools to AI applications |
Primary consumers | Web, mobile, and backend applications | MCP hosts and AI agents |
Capability discovery | API documentation or OpenAPI | Tools and other features returned by the server |
Transport | Commonly HTTP | STDIO or Streamable HTTP, among others defined by the protocol |
Relationship | Can be called by an MCP server | Can wrap a REST API |
MCP is therefore not a replacement for REST. A REST API can expose the underlying business capability while an MCP server translates it into an interface designed for AI applications.
MCP vs. function calling
What function calling does
Function calling, also called tool calling in many products, lets an application give a model function names, descriptions, and argument schemas. The model can then produce the function and arguments needed for the task.
The model does not usually execute that function itself. The application receives the model’s output, runs the relevant code, and sends the result back to the model. OpenAI function calling guide
In the GitHub example, the model might decide that it needs to search Issues and return search_issues with a query. Calling the GitHub API remains the application’s responsibility.
What MCP does
MCP standardizes the connection to the server that provides the tool. This includes initialization, capability negotiation, discovery of Tools, Resources, and Prompts, invocation, and result delivery.
The key distinction is:
Function calling determines which capability the model wants to use; MCP defines how that capability is made available to the AI application.
They are complementary and can participate in the same execution flow.
User request
↓
LLM selects a tool and arguments
↓ Function Calling / Tool Calling
Host invokes it through an MCP Client
↓ MCP
MCP Server performs the operation and returns a resultA host can present tool definitions discovered from an MCP server to the model. If the model selects one, the host asks the server to execute it through the client. OpenAI’s tools documentation likewise presents function calling and remote MCP as separate available tool mechanisms. OpenAI tools guide
How this differs from giving the AI an API specification directly
You can skip MCP and convert an OpenAPI document or custom JSON Schema into definitions for function calling.
API specification
↓ conversion
Function-calling tool definitions
↓
AI-application-specific execution code
↓ HTTP
REST APIThis can be the simplest approach when you have one AI application and only a few APIs or functions. If a small amount of existing code already works reliably, adding an MCP server may offer little immediate benefit.
As the number of AI applications and integrations grows, however, each application may need to own tool-definition generation, API requests, credential handling, error conversion, and model-friendly result formatting. MCP makes it possible to centralize the AI-facing interface in a server and reuse it from multiple compatible hosts.
The OpenAI Cookbook includes an example that converts an OpenAPI specification into function definitions. The page is currently archived and warns that it may refer to outdated models or APIs. OpenAPI function-calling example
When MCP is—and is not—a good fit
Cases where MCP is a good fit
MCP becomes more useful when one or more of the following conditions apply:
- You want the same capability to work across multiple AI applications.
- You want to expose internal data or business tools to AI agents.
- Clients need to discover available tools and react to changes.
- You want a consistent model for local tools and remote services.
- You want to reduce client-specific AI integration code.
- You expect to add more MCP-compatible hosts later.
For example, an MCP server is a reasonable boundary if an internal chat application, an IDE, and a coding agent all need the same GitHub Issue search-and-create capability.
Cases where MCP may be unnecessary
Function calling with ordinary application code may be enough when:
- You have only one AI application.
- The application uses two or three fixed functions.
- The existing function-calling implementation is simple and stable.
- You are connecting conventional systems without an AI host.
- No other MCP host needs to reuse the integration.
- The operation must be deterministic and should not depend on an LLM selecting it.
The useful decision criterion is not whether MCP is popular. It is whether your system needs standardized, reusable AI integrations. Direct integration is often simpler for one small application; MCP tends to become more valuable as the number of hosts and services grows.
Common misconceptions
Is MCP a new API?
It is better understood as a protocol for connecting AI applications to external systems. An MCP server may call an API internally.
Does MCP make REST APIs unnecessary?
No. Wrapping an existing REST API with an MCP server is one of the most natural ways to combine the two.
Should I choose MCP or function calling?
It is not an either-or decision. A host can discover a Tool through MCP and use function calling or tool calling to let the model select it.
Must an MCP server be hosted on the internet?
No. An MCP server can run locally or remotely. The right choice depends on the host, sharing requirements, and operational model.
REST API, function calling, and MCP compared
Item | REST API | Function Calling | MCP |
|---|---|---|---|
Category | System interface | Model API capability | AI integration protocol |
Primary purpose | Expose data and operations | Let a model select a tool and arguments | Standardize AI-to-system connections |
Tool definition | API specification or OpenAPI | JSON Schema or a similar schema | Published as Tools by the server |
Execution | Calling application | Application | Host, client, and server cooperate |
Typical reuse | Any kind of application | Usually the AI application implementing it | MCP-compatible hosts |
Relationship | Can be called by an MCP server | Can select an MCP Tool | Can combine APIs and function calling |
In the GitHub Issue example, the REST API exposes GitHub functionality over HTTP, function calling lets the model decide whether to use the Issue-search tool, and MCP presents that tool to AI applications in a shared format.
Summary
The three technologies have distinct responsibilities:
- REST API: exposes a system’s data and capabilities
- Function calling: lets the model select a capability and its arguments
- MCP: standardizes the connection between AI applications and external systems
The easiest way to understand MCP is not as a replacement for APIs, but as a shared layer for connecting existing APIs and data sources to AI applications.
If you are unsure whether to build an MCP server, ask two questions: Will multiple hosts reuse this AI-facing capability? Do we need a standard integration boundary as the number of connected services grows? If both answers are no, starting with ordinary function calling is perfectly reasonable.
The next article will build a minimal MCP server and invoke one of its Tools from an AI client.