Since the introduction of MCP by Anthropic in November 2024, there has been an explosion of MCP adoption, both by vendors supporting the protocol and customers implementing it. MCP‘s primary intent is to be used by LLMs to improve answering prompts, and it represents the interface that LLMs use to interact with systems and back-end applications to execute actions. The use case is similar to the use of APIs by client applications. This has developers often jump to the conclusion that they can just transform an MCP server from existing APIs to expose the same functionality to LLMs.
Fundamentally, this is not the correct way of creating MCP interfaces, due to some fundamental differences between LLMs and traditional applications. The relationship is more like deploying different pieces of API building blocks into an MCP server, not transforming it.
Let’s discuss the main differences and similarities of MCP servers and APIs, and we’ll also provide some best practices on how to create MCP servers from existing APIs.
APIs vs MCP servers: what is the difference?
Both APIs and MCP servers are interfaces that allow client applications to interact with server applications through a standardized protocol. The protocol is independent of the technology and implementation of the client and server.
But even though APIs and MCP servers share many features, there are some fundamental differences to consider. They use different layers of abstraction. We will highlight these differences in the following table.
| APIs | MCP servers |
| APIs are resource-based, with API methods to manipulate the resources. E.g. GET /invoice/invoiceid API method to get details about the invoice resource. | MCP servers are task-based, with tools to execute a certain task. E.g. read_invoice_details tool to get details about an invoice. MCP servers also have resources to expose data and prompts to expose prompt templates. |
| The interaction between a client application and an API is usually request/response. The client sends a request, and the API sends a response. | The interaction between an MCP client and an MCP server is more complex:
|
| Calling an API can be done through all HTTP methods: GET, POST, PUT, PATCH, DELETE. A GET will retrieve data about a resource, while a POST will create an instance of a resource. | Calling an MCP server is always through an HTTP POST. To get data, you would call, for example, getResourceInfo over HTTP POST. To create a resource, you would call, for example, createNewResource over HTTP POST. |
| An API can contain dozens of resources, and each resource can be manipulated using different API methods. | For an MCP server, it is recommended to keep the number of tools, prompts, and resources limited to 50 max. |
| APIs are used by client applications, which use predefined business logic to call APIs. The business logic can be used to link together different API calls to complete a given use case. E.g., to create a new customer entry, 5 different API calls need to be made in a specific order. | Tools are used by LLMs, and because LLMs are probabilistic, it is not possible to predict what tools an LLM will use to achieve its goal. An LLM is also not well-suited to link multiple fine-grained actions together to complete a use case. E.g., an LLM will not be able to figure out how to create a new customer entry if that involves making 5 different API calls in a specific order. |
| Documentation is important so that developers leveraging the APIs will understand what they do and how they can be used in the applications they are developing. Documentation is not used by the application calling the APIs. | Documenting an MCP server is crucial for the application using it. An LLM will use the description of a tool to figure out what it does and when it will use it. |
| APIs can be described with standardized specifications such as OpenAPI, RAML, and API Blueprint. | Currently, there is no official specification to describe an MCP server, which makes it more difficult to provide users with a single file that describes the entire MCP server in a standard manner. |
| An API is a very mature concept, so we shouldn’t expect many significant changes to the technology and specifications. | MCP is a relatively new standard, with the initial official version being available since November 2024. Major changes, including breaking changes, have already been introduced in the protocol. |
| There is a multitude of different authentication and authorization mechanisms, such as API key, OAuth, mTLS, Basic Auth, etc. | While it is technically possible to use different authentication and authorization mechanisms, the protocol states that OAuth 2.1 is currently the best protocol to use. |
How to turn an API into an MCP server
With a better understanding of the differences and similarities between MCP servers and APIs, you can see that it’s not entirely as straightforward as a direct 1:1 conversion from an API to an MCP server.
It’s not so much about transforming the API itself, but enabling it to participate in a broader AI ecosystem: MCP is about integration, it connects an LLM to other services, agents, or workflows. So, an API is not simply converted into an MCP server; an API’s functionality is exposed through an MCP server.
Let’s use a business example to show the best method to follow.
Step 1 – Define the MCP use case
The first step is to define the use case you want your MCP server to cover. For example, you might want an MCP server that an LLM can use to manage the procurement of new laptops, so company employees can use a chatbot to be more self-sufficient.
Once you have defined the MCP server, you need to decide what tools the MCP server should contain. A tool should be a task that an LLM can understand and should be a single action. For this use case, 3 tools need to be created, which will cover the 3 use cases in the laptop order process:
- check_laptop_offering
- order_laptop
- check_status_of_order
Step 2 – Create the business logic of the MCP servers
Now that you have defined which tools you want to implement, you can create the business logic for these tools. The tools will leverage the IT Procurement API and the IT Inventory API.
Since APIs are resource-based and MCP servers are task-based, it is usually not possible to create a tool directly from an API method. For the tools in our example, we need to call different API methods to complete the task defined in the description of the tool.
- check_laptop_offering
- 1 – get list of available models: GET /it/procurement/laptop
- 2 – get stock for each model: GET /it/inventory/laptop/model
- order_laptop
- 1 – check validity of current laptop: GET /it/procurement/laptop/[id]/validity
- 2 – check if the new laptop matches what the employee can order: GET /it/procurement/laptop/order/[userid]
- 3 – order laptop: POST /it/procurement/laptop
- check_status_of_order
- 1 – check the status of the order: GET /it/procurement/laptop/order/[id]
As can be seen, we need to call different API methods using different resources to accomplish the task of one of the tools in the MCP. This shows that it is not possible to simply transform an API into an MCP server.
Step 3 – Add the necessary authentication and authorization
Different APIs can be protected by different authentication mechanisms. An MCP server should be protected with OAuth 2.1, and the MCP server should be able to call the API using the authentication mechanisms defined by the API.
This means that the incoming request from the LLM into the MCP server will be authenticated using OAuth 2.1, and the subsequent outgoing calls to the different API methods will be authenticated with other mechanisms such as API Key, OAuth 2.0, Basic Auth, etc.
This blog post has shown that even though MCP servers and APIs share a similar purpose which is to provide an interface for client applicants to interact with backend applications, there are some fundamental differences between them which makes it usually not possible to perform a 1:1 transformation of an API into an MCP server. An MCP’s features may wrap around an API, but they are not an exact mirror of each other.
For these reasons, it is important to follow a process that starts with the definition of the use case for the MCP server, then defining and implementing the APIs required to support the use case.
Discover how the Amplify AI Gateway can help you perform the transformation from APIs to MCP servers.