IA

MCP vs API vs function calling

· 7 min de lectura

MCP, API y function calling no son lo mismo. Tres capas distintas: contrato entre sistemas, capacidad del modelo y protocolo entre hosts. Cuándo usar cada una.

Si mezclas MCP, API y function calling en la misma frase, acabas diciendo tres cosas distintas como si fueran alternativas, pero no lo son.

En corto:

  • Una API es un contrato entre sistemas (tu backend, un cron, otra app). No hace falta un LLM.

  • Function calling (o tool calling) es una capacidad del modelo: pide “ejecuta esta función” y tu código lo hace.

  • MCP es un protocolo para que varias apps de IA (Cursor, Claude, ChatGPT…) descubran y reutilicen las mismas tools.

MCP no es “una API más potente”. Function calling no es “un MCP pequeño”. Y sí: en la práctica se apilan. Un server MCP casi siempre llama a tu API por detrás. Un host MCP casi siempre usa function calling con el modelo.

Si aún no tienes el mapa de host / client / server, empieza por Qué es un MCP. Si quieres código, cómo crear un MCP.

Serie MCP: 1. Qué es → 2. Cómo crear → 3. App en ChatGPT4. Esta comparativa.

El lío en una analogía

Piensa en un restaurante:

Pieza

Analogía

En software

API

La cocina. Recibe “mesa 4, un risotto” y cocina.

GET /pokemon/pikachu. Sistemas hablando.

Function calling

El camarero que decide ir a cocina y vuelve con el plato.

El modelo dice get_pokemon("pikachu"); tu app ejecuta.

MCP

El lenguaje estándar entre cualquier restaurante y cualquier app de delivery.

El mismo server en Cursor, Claude y ChatGPT.

La cocina no “es” el camarero. El camarero no “es” Uber Eats. Pero un pedido real usa las tres.

Tres capas: API, function calling y MCP no se sustituyen, se apilan

1. API: contrato entre sistemas

Una API REST/GraphQL es lo de toda la vida: HTTP, JSON, auth, versionado. La llama:

  • tu frontend,

  • un cron,

  • otro microservicio,

  • un script.

No hay modelo decidiendo nada. Si pegas curl y te responde, es una API.

Ejemplo (PokéAPI, la de los tutoriales):

GET https://pokeapi.co/api/v2/pokemon/pikachu

Eso no es MCP. Tampoco es function calling. Es un contrato HTTP.

Docs de referencia: cualquier API HTTP; REST en MDN si quieres el vocabulario canónico.

2. Function calling: el modelo pide, tú ejecutas

OpenAI lo llama function calling o tool calling. Anthropic, tool use. Misma idea.

Le das al modelo una lista de tools (nombre, descripción, JSON Schema). El modelo, si lo necesita, no te inventa el tiempo en París: te pide get_weather({ location: "Paris" }). Tu aplicación:

  1. Recibe esa llamada estructurada.

  2. Ejecuta tu código (que a menudo pega a una API).

  3. Devuelve el resultado al modelo.

  4. El modelo redacta la respuesta al usuario.

OpenAI describe ese bucle en cinco pasos en su guía de function calling. Anthropic igual: Claude emite un bloque tool_use; tú mandas tool_result (tool use).

Usuario → tu app → API del modelo (con tools[])
                ←  "llama get_pokemon({ name: pikachu })"
         tu app ejecuta (fetch a PokéAPI, o lo que sea)
                →  resultado
                ←  "Pikachu es de tipo eléctrico"

Dónde vive la tool: dentro de esa app, en esa petición. Cambias de producto (de un script OpenAI a Cursor) y vuelves a definir las tools.

Encaja cuando:

  • tienes un producto y pocas tools pegadas a él,

  • controlas el bucle entero (tu backend llama a OpenAI/Anthropic),

  • no te hace falta que Cursor y ChatGPT usen lo mismo.

3. MCP: el mismo server en varios hosts

MCP (Model Context Protocol) es un estándar abierto: cómo una app de IA se conecta a tools, datos y flujos externos. Definición oficial: What is MCP?. Spec: modelcontextprotocol.io/specification.

Las tools no van en cada request a OpenAI. Van en un server MCP. El host (Cursor, Claude, ChatGPT…) se conecta, descubre las tools (tools/list) y se las ofrece al modelo.

Por debajo, el host sigue haciendo function calling con el modelo. MCP ordena dónde viven las tools y cómo se descubren. Build once, connect many.

Usuario → Cursor / ChatGPT / Claude
              ↓  MCP (JSON-RPC)
         Tu MCP server  (get_pokemon, list_pokemon…)
              ↓  HTTP
         PokéAPI (o tu API)

Eso es exactamente el stack de cómo crear un MCP: el server orquesta; PokeApiClient habla HTTP.

Encaja cuando:

  • quieres las mismas tools en más de un host,

  • vas a publicar un connector / app en ChatGPT (MCP Apps),

  • el catálogo de tools lo mantiene un equipo distinto al del chat.

La frase para entenderlo

Capa

Pregunta que responde

API

¿Cómo habla mi sistema con otros sistemas?

Function calling

¿Cómo pide el modelo una acción en esta conversación?

MCP

¿Cómo reutilizo esas acciones entre Cursor, Claude y ChatGPT?

MCP no mata al function calling. OpenAI, de hecho, trata los MCP servers como una tool más en su plataforma (function calling — built-in tools).

MCP no sustituye tu API. El server MCP es un wrapper con contrato para agentes. Detrás sigue habiendo HTTP, DB, auth.

API abajo, function calling en el medio, MCP entre hosts

Misma feature, tres montajes

Caso: “¿Qué tipo es Pikachu?”

Solo API

Un form o un cron hace GET /pokemon/pikachu. Nadie “decide” nada con un LLM.

Function calling (app tuya)

Tu backend manda a OpenAI/Claude las tools. El modelo elige get_pokemon. Tú haces el fetch. El usuario está en tu chat.

MCP

El usuario está en Cursor o ChatGPT. El host descubre get_pokemon en tu server. El modelo la llama igual (tool calling). El server pega a PokéAPI. Cambio de host, no de tools.

Cuándo usar cada una

Situación

Qué coger

Cron, webhook, otro backend, app sin LLM

API

Un chatbot tuyo, 2–5 funciones internas

Function calling contra tu API

Mismo catálogo en Cursor + Claude + ChatGPT

MCP (que por detrás llama a la API)

“¿Hago MCP porque mola?” y solo hay un script

No. Function calling. O ni eso.

Errores típicos al mezclarlos

  1. “MCP es una API.” No. La API es el contrato de datos. MCP es el protocolo con el host de IA.

  2. “Con MCP ya no hay function calling.” Al revés: el host lo sigue usando con el modelo.

  3. Meter 20 tools en function calling y clonarlas en cada producto. Ahí MCP empieza a pagar el coste.

  4. Exponer la API cruda al modelo (JSON gigante, sin schema). Da igual MCP o function calling: normaliza. En los tutoriales el PokeApiClient existe por eso.

  5. Auth “porque el modelo es de fiar”. El modelo no es tu capa de seguridad. Ni en tools locales ni en MCP HTTP.

Mini ejemplo mental

Function calling (idea; una sola app):

// Tú se lo mandas al modelo en CADA request
const tools = [
  {
    type: "function",
    name: "get_pokemon",
    description: "Use when the user asks about one Pokémon by name or id.",
    parameters: { /* JSON Schema */ },
  },
];
// El modelo responde: llama get_pokemon({ nameOrId: "pikachu" })
// Tú haces fetch a PokéAPI y se lo devuelves

MCP (idea; un server, muchos hosts):

// Lo registras UNA vez en el server
server.registerTool("get_pokemon", { description: "...", inputSchema: { ... } }, handler);
// Cursor / ChatGPT hacen tools/list y se lo ofrecen al modelo
// El handler sigue haciendo fetch a PokéAPI

Misma acción. Distinto dónde se declara y quién se conecta.

FAQ

¿Puedo tener MCP sin API?

Sí, si la tool solo lee un fichero local o calcula en proceso. En cuanto hay un sistema externo (CRM, PokéAPI, DB), casi siempre hay una API (o un driver) detrás.

¿Puedo tener function calling y MCP a la vez?

Sí. Tools internas del producto (function calling) + catálogo compartido (MCP). OpenAI incluso permite MCP como tool built-in.

¿Por cuál empiezo?

Si estás aprendiendo agentes: function calling en un script. Si ya quieres Cursor y ChatGPT con las mismas tools: crea el MCP.

Siguiente paso

Enlaces