![Imagen de portada de [MCP·Skill #1] ¿Qué es un servidor MCP? Desde cómo conectarlo hasta las consideraciones de seguridad](/assets/images/posts/45e71f91-f21d-492e-a6da-e0ffc8d4af18/1.jpg)
Al usar ChatGPT o Claude, hay momentos en los que echas algo en falta. El modelo es inteligente, pero no puede ver tu base de datos ni leer la wiki interna de la empresa.
Por eso muchos empezaron a conectar las API directamente. Sin embargo, cada modelo y herramienta tiene un método de integración distinto, y el código crece exponencialmente a medida que aumentan las combinaciones.
MCP (Model Context Protocol) es un estándar creado para resolver este problema. En una frase, es una especificación común para conectar herramientas y datos externos a los modelos de IA. A menudo se le llama «el USB-C de la IA».
En este artículo veremos qué resuelve exactamente MCP, cómo cambia el trabajo de integración antes y después de adoptarlo, su estructura interna y sus diferencias con function calling, además de algunos servidores destacados que puedes conectar ahora mismo.
Empecemos por el resumen clave.
- MCP es un protocolo estándar abierto que conecta la IA con herramientas externas (publicado por Anthropic en noviembre de 2024).
- Un trabajo que requiere cientos de líneas con una integración directa se completa con unas pocas líneas de configuración si existe un servidor MCP.
- No sustituye a function calling; es una capa que estandariza y permite reutilizar herramientas sobre él.
- Con la adopción de OpenAI y Google, se ha convertido de facto en un estándar del sector y su ecosistema de servidores crece rápidamente.
El problema que resuelve MCP: el infierno de integración M×N
Veamos primero la situación anterior a MCP.
Si había M aplicaciones de IA y N herramientas que conectar, se necesitaban M×N integraciones. Había que crear por separado la integración de GitHub para Claude, ChatGPT y Cursor.
MCP introduce una especificación estándar entre ambos lados. El lado de las herramientas crea un servidor MCP una sola vez y el de las aplicaciones implementa un cliente MCP una sola vez. M×N se reduce a M+N.
Es como la época anterior al USB-C, cuando llevabas un cable de carga distinto para cada dispositivo. MCP unifica esa especificación de cables.
Pero una fórmula como M+N no permite apreciar bien la diferencia. Si construyes la misma función de las dos formas, el contraste queda claro.
La misma función: comparación antes y después de adoptar MCP
Supongamos que vamos a crear «una IA que consulta incidencias de GitHub y responde».
Antes de MCP, todo este trabajo era responsabilidad tuya.
- Definir el esquema de la herramienta: escribir directamente como esquema JSON «list_issues recibe owner, repo y state».
- Escribir el código de llamada: cliente de la API REST de GitHub, gestión de tokens y paginación.
- Implementar el bucle de ejecución: código de ida y vuelta que recibe el resultado y lo devuelve al modelo cuando este llama a una herramienta.
- Repetirlo todo para cada aplicación: una integración para Claude y otra para el chatbot interno.
Solo consultar incidencias requiere cientos de líneas con el código repetitivo, y hay que repetirlo entre 1 y 3 veces cada vez que se añaden herramientas.
Con MCP, queda así de sencillo.
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"]
}
}
}El esquema, las llamadas a la API, la autenticación y el manejo de errores ya están dentro del servidor. Solo registras el servidor y dices: «Resume las incidencias de errores recientes de este repositorio».
| Elemento | Integración directa | Uso de un servidor MCP |
|---|---|---|
| Código escrito | Cientos de líneas de esquema, llamadas y bucles | 5 líneas de configuración |
| Autenticación y manejo de errores | Implementación manual | Integrado en el servidor |
| Añadir otra aplicación de IA | Empezar de nuevo | Reutilizar el mismo servidor |
| Añadir una herramienta | Modificar y volver a desplegar el código | Solo actualizar el servidor |
La última fila es especialmente importante. Aunque se añadan funciones al servidor, tu código no cambia ni una línea. Ese es el poder de la estandarización.
Estructura interna: host, cliente y servidor
MCP tiene tres participantes.
| Componente | Función | Ejemplo |
|---|---|---|
| Host | La aplicación de IA que usa el usuario | Claude Desktop, Cursor |
| Cliente | Comunicación uno a uno con el servidor dentro del host | Integrado en el host |
| Servidor | Programa que expone herramientas y datos | Servidor de GitHub, servidor de base de datos |
Un host inicia varios clientes y cada cliente se conecta a un servidor. El protocolo de comunicación es JSON-RPC 2.0; para procesos locales se usa stdio y para conexiones remotas, HTTP streaming.
Las funciones que expone el servidor se dividen en tres tipos.
- Herramientas (tools): funciones que llama el modelo, como «crear una incidencia» o «ejecutar una consulta».
- Recursos (resources): datos que lee el modelo, como el contenido de archivos y los esquemas de bases de datos.
- Prompts (prompts): plantillas de prompts preparadas de antemano por el servidor.
La clave es que la lista de herramientas se solicita en tiempo de ejecución. Cuando el cliente se conecta al servidor, pregunta «¿qué puedes hacer?» y el servidor devuelve la lista y los esquemas. Por eso tu código puede permanecer igual aunque el servidor se actualice.
¿En qué se diferencia de function calling?
Al llegar aquí surge una duda: «¿No se podía hacer ya con function calling?»
Están en capas distintas. function calling es un protocolo para conversar con el modelo: «Modelo, estas funciones están disponibles; cuando las necesites, responde con el formato de llamada». El desarrollador decide cómo se implementan y de dónde proceden.
MCP es un protocolo para distribuir y reutilizar esas funciones. Agrupa la implementación, la autenticación y la documentación de las herramientas en un paquete de servidor que puede usar cualquier aplicación de IA.
Si function calling es la «sintaxis para llamar funciones», MCP es un «ecosistema de bibliotecas que contiene funciones». De hecho, los clientes MCP usan function calling internamente. No son alternativas, sino capas superior e inferior.
Por eso la pregunta «¿qué uso, function calling o MCP?» no está bien planteada. Para un par de funciones usadas en una sola aplicación, basta con implementar function calling directamente. Si quieres reutilizarlas en varias aplicaciones o usar herramientas creadas por otros, MCP es la opción adecuada.
Servidores destacados que puedes conectar ahora mismo
El ecosistema crece rápidamente y ya existen servidores para casi todas las herramientas habituales. Hemos seleccionado cinco con buena acogida.
| Servidor | Qué permite hacer |
|---|---|
| Playwright | La IA controla el navegador directamente: hace clic, escribe y toma capturas |
| Figma | Lee diseños y los convierte en código frontend |
| Notion | Busca y organiza documentos y actas, y crea páginas |
| GitHub | Consulta y crea incidencias y PR, y busca código |
| Supabase(Postgres) | Consulta la base de datos en lenguaje natural y entiende el esquema |
Si tuviera que elegir uno, sería Playwright. Conéctalo y di: «Entra en este sitio, completa el formulario de registro y haz una captura». Cuando veas a la IA abrir el navegador, hacer clic y escribir, entenderás por qué conectar herramientas cambia las reglas del juego. También puedes usarlo directamente para automatizar pruebas E2E y tareas web repetitivas.
Figma también marca una gran diferencia para los desarrolladores frontend. El trabajo de trasladar manualmente un diseño a marcado se convierte en pedirle a una IA que lo lea directamente: «Convierte este frame en un componente de React».
Precauciones y limitaciones
No es una solución universal. Conviene tener presentes estos problemas prácticos.
Primero, la seguridad. Un servidor MCP es un canal que concede permisos de ejecución al modelo, por lo que conectar uno no confiable puede filtrar datos mediante prompt injection. Lo más seguro es usar únicamente registros oficiales o servidores verificados.
También existe un coste de contexto. Cuantos más servidores conectes, más definiciones de herramientas ocupan la ventana de contexto, lo que puede reducir el rendimiento del modelo. Como muestra la tabla, es mejor conectar solo lo que necesitas ahora.
Conclusión
MCP no hace que el modelo sea «más inteligente»; estandariza «el alcance al que puede llegar». Convertir cientos de líneas de integración directa en unas pocas líneas de configuración y crear un ecosistema donde puedes conectar herramientas hechas por otros: esa es la esencia.
En el próximo artículo explicaré qué función cumplen Skill de Claude Code y los subagentes, que suelen compararse con MCP.