EN

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

MCP no sustituye a tu API REST: la envuelve para que un agente descubra sus herramientas solo. Comparativa y cuándo usar MCP, API, RAG o function calling.

· 9 min lectura
MCP vs API: diferencias y cuándo usar cada uno

MCP (Model Context Protocol) y una API REST no compiten: viven en capas distintas. Una API REST expone funcionalidad para que un desarrollador la integre leyendo documentación. MCP expone esa misma funcionalidad en un formato que un modelo descubre y ejecuta por su cuenta, en tiempo de ejecución, sin que nadie le explique antes cómo se llama cada endpoint.

La duda real cuando ya tienes backend montado suele ser otra: si mi API funciona, ¿para qué levanto un servidor MCP encima? La respuesta corta es que te ahorras escribir una integración a medida por cada cliente que quiera usarla. La larga ocupa el resto del artículo.

MCP vs API REST, lado a lado

API RESTServidor MCP
Consumidor previstoUn desarrollador que lee la documentación y escribe el clienteUn cliente LLM que lee el catálogo de herramientas mientras corre
DescubrimientoFuera del protocolo: OpenAPI, un README, una colección de PostmanDentro del protocolo: tools/list devuelve nombre, descripción y inputSchema en JSON Schema [1]
Formato y transporteHTTP con verbos y rutas, y cada API con sus convencionesJSON-RPC 2.0 sobre stdio o Streamable HTTP [1]
EstadoSin estado por diseñoConexión con estado: un handshake initialize negocia versión de protocolo y capacidades antes de nada
Cambios en el catálogoVersionas, publicas changelog y esperas a que los clientes se enterenEl servidor emite notifications/tools/list_changed y el cliente vuelve a pedir la lista
AutenticaciónLa que tú decidas: API key, JWT, OAuthSobre HTTP la especificación fija OAuth 2.1, con el servidor MCP actuando como resource server (el que valida el token, no el que lo emite) y verificación PKCE obligatoria en el intercambio [2]
Dónde brillaContratos estables, control fino, clientes que escribes túMuchos clientes distintos usando tus mismas herramientas

La fila que de verdad separa a los dos es la segunda. Todo lo demás son consecuencias de ella.

Por qué un modelo no puede leerse tu documentación

Un modelo solo puede llamar a lo que tiene descrito en su contexto en ese momento. Tu documentación de OpenAPI está en una web, no en la ventana de contexto, y aunque se la pegues entera te comes miles de tokens de esquemas que probablemente no necesita para la tarea de hoy.

MCP mueve esa descripción dentro del protocolo. El cliente pide el catálogo, el servidor responde, y cada herramienta llega con todo lo que el modelo necesita para decidir si le sirve:

{
  "tools": [
    {
      "name": "get_weather",
      "description": "Get current weather information for a location",
      "inputSchema": {
        "type": "object",
        "properties": {
          "location": { "type": "string", "description": "City name or zip code" }
        },
        "required": ["location"]
      }
    }
  ]
}

Ese description no es documentación. Es la interfaz. El modelo elige la herramienta leyendo esa frase y nada más, así que una descripción vaga produce exactamente el mismo síntoma que un bug: la herramienta correcta existe y no se llama nunca. En el servidor MCP con el que publico en este blog, las herramientas que daban problemas no eran las de lógica complicada, eran las que tenían una descripción escrita en tres palabras porque el nombre “ya se entendía”.

Debajo de todo esto puede haber perfectamente tu API de siempre. Un servidor MCP suele ser una capa fina que traduce tools/call a una petición HTTP contra el backend que ya tienes. Si quieres el paso a paso de cómo se monta uno, lo tienes en la guía de qué es MCP y cómo construir tu primer servidor.

MCP vs function calling: mismo mecanismo, distinto contrato

Function calling y MCP no son alternativas. Function calling es la capacidad del modelo de responder “quiero ejecutar esta función con estos argumentos”; MCP es un protocolo para publicar qué funciones existen y cómo se ejecutan. Cuando usas MCP, por debajo sigue habiendo function calling.

La diferencia está en quién define el contrato. Sin MCP, el formato lo pone cada proveedor:

// La misma herramienta, definida para dos proveedores distintos
const anthropicTool = {
  name: 'get_weather',
  description: 'Devuelve el tiempo actual de una ciudad.',
  // Anthropic llama input_schema al JSON Schema de los argumentos
  input_schema: { type: 'object', properties: { location: { type: 'string' } }, required: ['location'] }
}

const openaiTool = {
  type: 'function',
  name: 'get_weather',
  description: 'Devuelve el tiempo actual de una ciudad.',
  // OpenAI lo llama parameters
  parameters: { type: 'object', properties: { location: { type: 'string' } }, required: ['location'] }
}

Dos claves distintas para lo mismo, y cada SDK con su forma de devolverte la llamada y de recibir el resultado (en la API de Anthropic, un bloque tool_use de ida y un tool_result de vuelta). Multiplica eso por cada cliente que quiera usar tus herramientas y ya tienes el problema que MCP viene a quitar: la definición se escribe una vez en el servidor y la adaptación al formato del proveedor la hace el cliente.

Con dos herramientas y un solo cliente, esa ganancia no existe. Con doce herramientas y tres clientes, es la diferencia entre mantener una cosa o doce por tres.

MCP vs RAG: capas distintas del mismo agente

RAG y MCP responden a preguntas diferentes. RAG resuelve “qué información necesita el modelo para responder”: buscas fragmentos relevantes y los metes en el contexto (si no tienes claro el mecanismo, lo explico desde cero en qué es RAG). MCP resuelve “qué puede hacer el modelo sobre sistemas externos”: crear el ticket, mover el fichero, lanzar el despliegue.

Un agente de soporte de verdad usa las dos cosas en el mismo turno. Recupera la política de devoluciones que aplica a ese pedido, y luego ejecuta la devolución. Quitarle cualquiera de las dos capas lo deja cojo: sin recuperación responde de memoria y se inventa la política, sin ejecución te contesta muy bien y no hace nada.

Y se pueden anidar. Una búsqueda semántica sobre tu base de conocimiento puede exponerse como una herramienta MCP más, con un inputSchema que reciba la consulta. Ahí RAG corre por dentro de MCP, sin que el modelo tenga que saber que hay embeddings de por medio.

¿Cuándo usar cada uno?

Ya tienes una API y quieres que un agente la use. Envuélvela en un servidor MCP en lugar de reescribirla. La lógica, los permisos y las validaciones se quedan donde están; el servidor solo publica el catálogo y traduce llamadas. Empieza exponiendo las cuatro o cinco operaciones que el agente necesita de verdad, no las cuarenta que tiene la API.

Construyes desde cero y varios clientes van a usar las mismas herramientas. Aquí MCP compensa desde el primer día. Si tus herramientas las van a consumir un IDE, un agente propio y algún cliente de escritorio, escribir la definición una vez y que los tres la descubran solos es justo el caso de uso para el que se diseñó el protocolo.

Un único cliente que controlas tú, con dos o tres herramientas. Function calling directo contra la API del modelo. Un servidor MCP aquí es un proceso más que arrancar, un handshake más que depurar y ninguna ventaja a cambio.

Solo necesitas que el modelo responda sobre tus documentos. RAG y para casa. No hay acciones que ejecutar, así que no hay nada que MCP aporte. Si más adelante aparece la primera acción real, ya tendrás motivo para replantearlo.

Ya le pasas comandos de una CLI al agente y funciona. Si es tu propia máquina y un solo cliente, no hay prisa por migrar: MCP gana cuando esos mismos comandos los tienen que descubrir y validar varios clientes distintos sin que cada uno adivine los flags a mano (más abajo, en la FAQ, entro en qué cambia exactamente frente a una CLI).

Si estás tomando estas decisiones por primera vez y quieres practicarlas en lugar de leerlas, el curso de patrones agénticos recorre este tipo de elecciones de arquitectura con ejercicios en vez de teoría.

Dos decisiones que suelen salir mal

Convertir la API entera en herramientas

Un servidor MCP generado automáticamente desde una especificación OpenAPI de sesenta endpoints te da sesenta herramientas. Todas ellas ocupan contexto en cada turno, y cuantas más opciones parecidas le pongas delante al modelo, más fácil es que elija la que no era. Empieza por las operaciones que el agente necesita para completar una tarea concreta y añade a partir de ahí. Cuando el catálogo crece de verdad hay estrategias para no pagarlo todo en contexto, como cargar herramientas bajo demanda o ejecutarlas desde código en lugar de una a una.

Escribir las descripciones para humanos

update_record con la descripción “Actualiza un registro” es una herramienta que el modelo va a usar mal. No sabe qué registro, ni cuándo, ni qué pasa si el campo no existe. Escribe la descripción como si se la explicaras a alguien que va a usar la función sin ver el código: qué hace, cuándo tiene sentido llamarla y qué devuelve. Es el sitio donde media hora de trabajo cambia más el comportamiento del agente.

Checklist antes de montar un servidor MCP

  • Hay más de un cliente (actual o previsto) que va a usar las mismas herramientas
  • Las operaciones expuestas son acciones, no consultas de documentos que RAG ya resuelve
  • Cada herramienta tiene una descripción que explica cuándo usarla, no solo qué hace
  • El inputSchema marca los campos obligatorios y describe cada propiedad
  • La autenticación y los permisos siguen aplicándose en el backend, no solo en la capa MCP
  • El catálogo empieza pequeño y crece según lo que el agente falla, no según lo que la API tiene

Fuentes

  1. Model Context Protocol — Especificación 2025-06-18 — base del protocolo (JSON-RPC 2.0, conexiones con estado, negociación de capacidades), transportes stdio y Streamable HTTP, y el formato de tools/list y tools/call.
  2. Model Context Protocol — Authorization — el servidor MCP como resource server de OAuth 2.1, metadatos de recurso protegido (RFC 9728) y PKCE obligatorio en transportes HTTP.

Preguntas Frecuentes

¿MCP sustituye a las APIs REST?

No. Un servidor MCP casi siempre se apoya en una API que ya existe: recibe la llamada del modelo y la traduce a peticiones HTTP contra tu backend. Lo que sustituye es la integración a medida que tendrías que escribir para cada cliente LLM.

¿Cuál es la diferencia entre MCP y RAG?

RAG recupera información y la mete en el contexto del modelo para que responda mejor; MCP le da la posibilidad de ejecutar acciones sobre sistemas externos. No son opciones excluyentes y un agente de producción suele necesitar las dos. De hecho, una búsqueda RAG puede exponerse como una herramienta MCP más.

¿MCP y function calling son lo mismo?

No exactamente. Function calling es el mecanismo del modelo para pedir la ejecución de una función con unos argumentos, y existe en las APIs de los proveedores con formatos distintos entre ellas. MCP es el protocolo que estandariza cómo se publican esas funciones, cómo se descubren y cómo se ejecutan, para que un mismo servidor valga con cualquier cliente compatible. Cuando un agente usa MCP, por debajo sigue habiendo function calling.

MCP vs CLI: ¿qué gano frente a darle una CLI al agente?

Una CLI también deja que el modelo actúe, pero el contrato es implícito: tiene que acertar con los flags y luego interpretar texto de salida pensado para leerse en un terminal. Con MCP los argumentos vienen validados por un JSON Schema y el resultado llega estructurado, así que hay menos margen para que el agente adivine mal. La CLI sigue siendo perfectamente razonable para tareas puntuales sobre tu propia máquina.

Sigue explorando

Articulos relacionados