MCP vs API REST y function calling: diferencias y cuándo usar cada uno

MCP, una API REST y el function calling no compiten entre sí. Son tres contratos distintos, y cada uno actúa en un tramo distinto de la misma llamada. La API REST es el contrato de una aplicación con los programas que la consumen. El function calling es el mecanismo con el que un modelo pide a la aplicación que ejecute una función. Y MCP (Model Context Protocol) es el protocolo estándar entre una aplicación de IA y los servidores que le exponen herramientas y datos. Por eso la pregunta útil no es «MCP vs API», sino dónde quieres que viva cada pieza y quién responde de ella.

Si todavía no sabes qué es MCP, empieza por la guía de qué es MCP. Aquí damos por conocidos el host, el cliente y el servidor, y vamos directos a la comparación. Todo lo que sigue describe la versión vigente de la especificación, la 2026-07-28.

¿Qué resuelve cada uno?

Una API REST es el contrato entre dos programas cualesquiera. La consume un programa cuyo autor leyó la documentación y dejó fijado en el código qué endpoint llamar y con qué parámetros. Cada API define su propio formato, y descubrir sus operaciones es trabajo de una persona.

El function calling es el contrato entre el modelo y la aplicación. Establece cómo describe la aplicación sus funciones al modelo y cómo indica el modelo que quiere llamar a una. Lo define cada proveedor de modelos, y no dice nada sobre dónde vive el código de la función ni quién lo mantiene. El modelo no ejecuta nada. Emite una petición estructurada con el nombre de la función y los argumentos, y la aplicación decide si la cursa. Con function calling directo, el código de cada función vive dentro de la aplicación.

MCP es el contrato entre una aplicación de IA y un servidor que expone un sistema. Los mensajes son JSON-RPC 2.0 con métodos de nombre fijo: el cliente pide la lista de herramientas con tools/list y ejecuta una con tools/call. Cada herramienta (tool) llega con un name y un inputSchema en JSON Schema con sus argumentos. Normalmente trae también una description que sirve de pista al modelo.

Lo que aporta MCP es que ese formato no depende del proveedor del modelo. Además, el servidor se describe en ejecución, así que añadir una tool no obliga a desplegar de nuevo ninguna aplicación.

¿En qué se diferencian MCP, una API REST y el function calling?

La tabla resume la comparación de la lección Introducción a MCP, que es de donde sale este artículo:

	Function calling directo	API REST	MCP
Entre qué piezas	Modelo y aplicación	Dos programas cualesquiera	Aplicación de IA y servidor que expone un sistema
Quién define el formato	Cada proveedor de modelos	Cada API	Una especificación común
Dónde vive el código de la función	En cada aplicación	En el servicio	En el servidor MCP, una vez
Cómo se descubren las operaciones	Están escritas en la aplicación	Documentación leída por una persona	En ejecución, con tools/list
Quién elige qué operación llamar	El modelo	El programador	El modelo, con las definiciones que publica el servidor

Hay dos filas que pesan más que el resto. «Quién elige» explica por qué una API REST no es un buen servidor MCP sin más. La diseñaste para un programador que lee documentación, y aquí decide un modelo guiado solo por nombres, descripciones y esquemas. «Dónde vive el código» es lo que separa MCP del function calling directo: la función deja de estar en cada aplicación y la publica un servidor independiente.

¿MCP sustituye al function calling?

No, lo usa. En una llamada real con MCP sigue habiendo function calling. La diferencia es que las funciones ya no las escribe la aplicación. Según la lección 1, el recorrido completo es este:

1. La aplicación (que contiene el cliente MCP) pide al servidor tools/list y recibe las definiciones.
2. La aplicación convierte cada definición al formato de tools de la API de su proveedor de modelos y la envía con la conversación. Este paso no es MCP.
3. El modelo responde con una petición de llamada: nombre de la tool y argumentos. Tampoco es MCP: es el function calling del proveedor.
4. La aplicación decide si la cursa y, si lo hace, la traduce a un tools/call hacia el servidor.
5. El servidor ejecuta y devuelve el resultado, que la aplicación entrega al modelo (otra vez fuera de MCP).

Con el SDK de TypeScript y la API de Anthropic, el paso 2 se ve tal cual en el código. Cada tool MCP se convierte en { name, description, input_schema: tool.inputSchema } dentro de las tools de client.messages.create(...). Después, por cada bloque tool_use que devuelve el modelo, la aplicación llama a mcp.callTool(...) y responde con un tool_result. El SDK de Anthropic también trae helpers que hacen esa conversión. Si quieres ver el lado del servidor, los tutoriales para crear un servidor MCP en TypeScript y en Python construyen uno desde cero.

Existe una variante en la que tu aplicación no da los pasos 1, 2, 4 y 5, porque algunas APIs de modelos actúan ellas mismas como cliente MCP:

• El MCP connector de la API de Anthropic, en beta, recibe en la petición una lista mcp_servers y un mcp_toolset en tools. Solo admite llamadas a tools, y el servidor tiene que estar expuesto públicamente por HTTP (no vale stdio).
• La Responses API de OpenAI acepta una tool de tipo mcp, que funciona con servidores Streamable HTTP o HTTP/SSE.

¿MCP sustituye a mi API REST?

Tampoco. Un servidor MCP suele ser un consumidor más de la API que ya tienes. La API sigue siendo el contrato con el resto de tus sistemas, y en ella siguen viviendo su autenticación, sus validaciones y su lógica de negocio. El servidor MCP traduce las llamadas del protocolo a llamadas a esa API.

Lo que sí cambia es el diseño de la interfaz que ve el modelo. La tentación obvia es convertir cada endpoint en una tool de forma automática, y las fuentes coinciden en desaconsejarlo:

• Cloudflare recomienda no tratar el servidor MCP como un envoltorio del esquema completo de la API: «Do not treat your MCP server as a wrapper around your full API schema». Propone menos tools, orientadas a los objetivos del usuario, y varios servidores enfocados con permisos acotados.
• La documentación de FastMCP advierte de que los servidores generados automáticamente desde una especificación OpenAPI rinden peor que los diseñados a mano, y recomienda la generación automática solo para prototipos.
• El coste de contexto lo hace tangible. Las definiciones de las tools viajan al modelo en cada conversación que tenga el servidor conectado, se usen o no. Cloudflare documenta que su servidor MCP para su propia API cubre más de 2.500 endpoints con dos tools, search() y execute(), por unos 1.000 tokens. Un servidor con el esquema completo de cada endpoint ocupa unos 1.170.000 tokens. La técnica, Code Mode, es experimental, y la cifra es de su API, no de la tuya. Aun así, la conclusión se puede trasladar: una tool por endpoint no escala.

Ese coste de contexto no es exclusivo de MCP, porque el function calling directo lo tiene igual. Lo que pasa es que con MCP se acumula con facilidad: conectar un servidor más es una línea de configuración.

Un ejemplo con Nortia: un abono de principio a fin

Nortia Logística, la empresa ficticia que recorre el curso, tiene una API REST interna de facturación protegida con OAuth. Encima ha desplegado nortia-facturacion, un servidor MCP que no copia la API. Expone dos tools orientadas a tareas: buscar_factura y emitir_abono. La lección 13 muestra el contraejemplo. Publicar la API de facturación entera (46 operaciones) convertida automáticamente en tools es justo lo que hay que rediseñar antes de publicar.

Un cliente recibe un palé dañado del pedido PED-2026-004812 y reclama. La controller financiera le pide a su asistente que abone 184,50 euros de la factura F-2026-0142. Los tres contratos aparecen en este orden:

• Function calling. El host ofrece al modelo las definiciones de buscar_factura y emitir_abono en el formato de su proveedor. El modelo propone llamar a emitir_abono con la factura, el importe y el motivo.
• Aprobación. emitir_abono tiene efecto contable, así que el host muestra a la controller la tool, los argumentos y las anotaciones, y espera su aprobación. Si la deniega, no sale ninguna petición hacia el servidor.
• MCP. Con la aprobación, el cliente envía el tools/call:

POST /facturacion/mcp HTTP/1.1
Host: mcp.nortia.example
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: emitir_abono

{
  "jsonrpc": "2.0",
  "id": 12,
  "method": "tools/call",
  "params": {
    "name": "emitir_abono",
    "arguments": {
      "factura_id": "F-2026-0142",
      "importe": 184.5,
      "motivo": "Palé dañado en la entrega del pedido PED-2026-004812",
      "clave_idempotencia": "7f3c1f0e-5d0a-4a52-9a43-2b1f6f0d9c11"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "nortia-agente-finanzas", "version": "2.1.0" },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Fuente: petición literal de la lección Herramientas. Como en la lección, omitimos la cabecera Authorization. No hay sesión: la versión del protocolo y las capacidades del cliente viajan en el _meta de cada petición.

• API REST. nortia-facturacion verifica el rol, el inquilino (España o México) y el límite de importe de ese rol. Solo entonces crea el abono contra la API interna, con su propio contrato HTTP y OAuth. Si el importe supera el saldo pendiente de la factura, el fallo no vuelve como error de protocolo. Vuelve como resultado con isError: true y un texto que dice qué cambiar, para que el modelo corrija y reintente.

Fíjate en quién ejecuta. No es el modelo ni su proveedor, sino el servidor. Lo hace al recibir el tools/call que el cliente envía cuando el modelo emite la petición de llamada. Por eso los controles (permisos, aprobación, auditoría) están en la aplicación y en el servidor. Y por eso, si la controller pregunta si al desplegar nortia-facturacion se puede retirar la API REST, la respuesta es no: el servidor MCP es un cliente más de esa API.

¿Cuándo no usar MCP?

La especificación no lo dice. Los criterios son los del curso, de las lecciones Introducción a MCP y Beneficios y desafíos, y se resumen en cuatro preguntas que conviene hacerse antes de exponer una operación como servidor MCP:

1. ¿Un modelo decide en cada conversación qué operación llamar? Si no, usa una API, una cola o una tarea programada. En Nortia, copiar cada noche los pedidos entregados a facturación es una secuencia fija, y MCP no aporta nada. Un asistente que responde sobre tarifas a partir de un documento fijo tampoco lo necesita, porque el documento va en el prompt de la aplicación.
2. ¿La consumirá más de una aplicación, o un equipo que no la mantiene? Si no, usa function calling directo dentro de la aplicación. Con una aplicación, un equipo y funciones que nadie más va a consumir, es más simple y más barato de operar. La señal para pasar a MCP es concreta: la segunda aplicación que necesita la misma función, o el primer equipo que quiere ofrecer su sistema a aplicaciones que no mantiene. Llegado ese momento, migrar es mover el código de las funciones a un servidor, no reescribirlo.
3. ¿Llega al servidor la identidad de la persona y queda registro de cada llamada? Si no, la respuesta es «todavía no». Resuelve antes la identidad y la auditoría, porque el protocolo no arregla una credencial compartida.
4. ¿Se puede exponer como pocas tools orientadas a tareas? Si sale una tool por endpoint, rediseña antes de publicar.

El motivo de fondo de la segunda pregunta es aritmético. Con N aplicaciones de IA y M sistemas, las integraciones punto a punto crecen como N × M, y con MCP crecen como N + M. En Nortia, tres aplicaciones y cuatro sistemas son hasta 12 integraciones, frente a tres clientes y cuatro servidores. Si N es 1, no hay nada que reutilizar.

¿Qué no hace MCP por ti?

Para cerrar la comparación con honestidad, la lección 1 recoge cuatro cosas que MCP no es. Una ya la has visto arriba: no hace útil una API mal diseñada. Estas son las otras tres:

• No es un framework de agentes ni un modelo. No decide qué tool llamar ni en qué orden. Eso lo hacen el modelo y la aplicación.
• No es una capa de seguridad. La especificación obliga al servidor a validar entradas, controlar el acceso, limitar la tasa de invocaciones y sanear las salidas, pero ese código lo escribes tú. La autorización es opcional en el protocolo y, sobre HTTP, se basa en OAuth 2.1.
• No certifica lo que declara un servidor. Las anotaciones de una tool, como readOnlyHint, son pistas. Los clientes deben tratarlas como no fiables salvo que vengan de un servidor de confianza.

Tampoco es el único protocolo del ecosistema de agentes. Si lo que necesitas es que dos agentes hablen entre sí, la comparación que te interesa es A2A frente a MCP.

Por dónde seguir

Estas lecciones tienen ficha pública:

• Introducción a MCP desarrolla la comparación con un intercambio tools/list y tools/call campo a campo.
• Arquitectura explica host, cliente y servidor, y los dos transportes.
• Herramientas enseña a diseñar tools como buscar_factura y emitir_abono, con errores que el modelo puede corregir.

El nivel Básico es gratis con registro, y el temario completo está en /aprende.