Qué es un servidor MCP y para qué sirve

Respuesta rápida

Un servidor MCP es un servicio que expone sus operaciones como herramientas que un modelo de lenguaje puede llamar directamente, siguiendo el Model Context Protocol, un estándar abierto. La diferencia con una API normal no está en lo que hace, sino en quién la lee: una API la integra un programador escribiendo código; un servidor MCP lo descubre el propio agente en tiempo de ejecución, con la descripción de cada herramienta y su esquema de argumentos.

El problema que resuelve, antes que la definición

Un modelo de lenguaje, por sí solo, es un sistema que produce texto. Sabe mucho y no puede hacer nada. Si le preguntas cuánto gastaste en la compra el mes pasado, no lo sabe: no tiene acceso a tus datos, y lo mejor que puede hacer es pedirte que se los pegues.

Durante un par de años, el parche fue integrar cada servicio a mano. Alguien escribía código que traducía entre el modelo y una API concreta, decidía qué funciones exponer, redactaba las descripciones y mantenía todo eso cuando cualquiera de las dos partes cambiaba. Funcionaba, pero no escalaba: cada combinación de agente y servicio era un trabajo nuevo. Con diez agentes y diez servicios no hay veinte piezas que mantener, hay cien.

MCP es el estándar que rompe esa multiplicación. El servicio publica una vez un servidor que describe sus herramientas de forma que cualquier agente compatible las entienda. El agente, del otro lado, aprende una vez a hablar el protocolo. A partir de ahí, cualquiera de los dos lados se conecta con el otro sin código a medida.

Qué contiene realmente un servidor MCP

Cuando un agente se conecta, lo primero que hace es preguntar qué hay. El servidor responde con un catálogo de herramientas, y cada una trae tres cosas.

Un nombre, en el estilo create_gasto o list_gastos, que es como el agente la invoca.

Una descripción en lenguaje natural, y esta es la parte que más se subestima. El agente no tiene documentación ni ejemplos: ese texto es literalmente todo lo que sabe sobre cuándo usar la herramienta y qué esperar. Un servidor bien hecho documenta ahí las reglas de negocio que el esquema no puede expresar —que los importes de un desglose tienen que cuadrar con el total, qué signo lleva cada tipo de movimiento—, porque si no, el agente las descubre equivocándose.

Un esquema de argumentos en JSON Schema, que define qué campos acepta, cuáles son obligatorios y de qué tipo. Eso permite al cliente validar antes de llamar en vez de descubrir el error al otro lado.

Con esas tres cosas, un agente que nunca ha visto tu servicio puede decidir por su cuenta que para responder «¿cuánto llevo este mes?» tiene que llamar a la herramienta de listar gastos con un rango de fechas, y hacerlo bien a la primera.

En qué se diferencia de una API de toda la vida

La confusión más común es pensar que MCP sustituye a las API REST. No las sustituye: casi siempre va montado encima de las mismas.

La diferencia está en el destinatario. Una API REST está diseñada para que la lea una persona y la integre escribiendo código; su documentación vive en una web aparte, y si cambia, alguien tiene que enterarse y actualizar el cliente. Un servidor MCP está diseñado para que lo lea un modelo en el momento de usarlo; la documentación viaja dentro del propio catálogo, así que cuando el servidor añade una herramienta, el agente la ve en la siguiente conexión sin que nadie toque nada.

Hay una segunda diferencia, menos comentada y más importante en la práctica: MCP trae la noción de permisos y consentimiento de serie. Una clave de API típica es todo o nada. Un servidor MCP bien diseñado expone qué permiso exige cada herramienta y el cliente puede anunciar, antes de ejecutar, si una operación es de solo lectura o si es destructiva, para que el usuario confirme.

El mismo concepto, con un caso concreto

Vale la pena bajarlo a tierra con un ejemplo real, porque en abstracto todo esto suena a diagrama.

ControlarGastos —una aplicación para llevar gastos compartidos entre parejas, pisos o grupos— publica un servidor MCP en https://controlargastos.es/api/mcp. Cuando conectas ahí un agente con un token tuyo, el agente descubre herramientas para crear un gasto, listar los del mes, consultar quién debe qué a quién, mirar un presupuesto o confirmar una deuda.

A partir de ese momento, «apunta la compra de hoy, 43 euros, y dime cómo va el mes» deja de ser una petición que el agente no puede atender. Llama a la herramienta de crear, luego a la de resumen, y contesta con datos reales. Nadie ha escrito una integración para eso: el agente ha leído el catálogo y ha decidido.

Y funciona igual de bien al revés. Si el token que le diste solo tiene permiso de lectura, el agente ve la herramienta de crear en el catálogo, intenta usarla y recibe una negativa del servidor. La comprobación de permisos ocurre antes de ejecutar nada, no dentro de la lógica de la herramienta.

Lo que un servidor MCP no arregla

Conviene decirlo, porque el entusiasmo del sector tiende a olvidarlo. Un servidor MCP no hace que el modelo acierte más: si el agente entiende mal lo que le pides, ahora se equivoca con más alcance, no con menos. No sustituye a una interfaz: hay tareas que se hacen mejor mirando una pantalla. Y no es seguro por defecto: un servidor que expone operaciones de escritura sin permisos granulares, sin verificación de origen y sin límite de cadencia es una superficie de ataque, no una función.

Esa última parte es donde se separa un servidor MCP serio de uno hecho en una tarde, y merece su propio artículo.

Preguntas frecuentes

¿MCP es de Anthropic?

El protocolo lo publicó Anthropic como estándar abierto, y hoy lo implementan clientes y servicios de distintos fabricantes. No hace falta usar un modelo concreto para conectarte a un servidor MCP.

¿Un servidor MCP es lo mismo que una API?

No, aunque casi siempre se apoya en una. Una API la integra un programador escribiendo código; un servidor MCP lo descubre el agente en tiempo de ejecución, leyendo la descripción y el esquema de cada herramienta.

¿Qué diferencia hay entre un servidor MCP local y uno remoto?

Uno local se ejecuta en tu máquina y el cliente lo arranca como un proceso. Uno remoto vive en un servidor y se conecta por HTTP con una URL, que es lo que permite usarlo desde varios dispositivos sin instalar nada.

¿Necesito saber programar para usar uno?

Para usarlo, no: se añade con un comando o desde el panel de conectores de tu cliente. Para publicar uno, sí.

¿Puede un servidor MCP hacer cosas sin que yo lo autorice?

Puede hacer aquello para lo que le hayas dado permiso, que es exactamente por lo que importa mirar los permisos del token antes de conectarlo. Los clientes serios, además, piden confirmación antes de ejecutar operaciones marcadas como destructivas.