MCP: Model Context Protocol, qué es y para qué sirve

El Model Context Protocol (MCP) es un estándar abierto que define cómo los modelos de lenguaje y los asistentes de IA se conectan con herramientas, bases de datos y otras fuentes de contexto externas. Fue presentado por Anthropic a finales de 2024 y adoptado desde entonces por Cursor, Claude Desktop, y otras aplicaciones. En lugar de que cada producto invente su propia forma de integrar datos, MCP ofrece un protocolo común: defines servidores que exponen recursos y herramientas, y cualquier cliente compatible con MCP puede conectarse a ellos.

En este artículo verás qué problema resuelve, los conceptos clave, cómo funciona por dentro, ejemplos prácticos y cómo configurar tu primer servidor MCP.

¿Qué problema resuelve MCP?

Los modelos de IA son muy capaces con el texto que reciben, pero por sí solos no pueden:

• Consultar tu base de datos o tu API en tiempo real
• Leer archivos de tu proyecto más allá de lo que se les envía en el prompt
• Ejecutar acciones en servicios externos (correo, calendario, tareas, etc.)
• Acceder a documentación actualizada o a datos que cambian constantemente

Antes de MCP, cada herramienta (IDE, chatbot, CLI) creaba sus propias integraciones. Eso implicaba:

• Duplicar trabajo: la misma integración (por ejemplo, con Notion o con tu repo) se implementaba una vez por producto
• Bloqueo por cliente: un “recurso” solo funcionaba donde el fabricante lo había añadido
• Falta de estándar: no había una forma común de describir “recursos” y “herramientas” que cualquier cliente pudiera consumir

MCP unifica todo esto: un servidor MCP expone recursos (documentos, datos, APIs) y herramientas (acciones invocables). Cualquier cliente que hable MCP puede conectarse a ese servidor y ofrecer ese contexto y esas acciones al modelo. Así, la lógica de integración vive en un solo lugar y se reutiliza en Cursor, Claude Desktop, o en el cliente que tú construyas.

Conceptos clave

Cliente MCP

Es la aplicación que usa el modelo de IA y se comunica con uno o varios servidores MCP. El cliente:

• Gestiona la conexión al servidor (por stdio o por HTTP/SSE)
• Envía y recibe mensajes según el protocolo MCP (JSON-RPC)
• Presenta al modelo los recursos que el servidor ofrece (por ejemplo, el contenido de un archivo o de una URL)
• Ejecuta las herramientas que el modelo decide invocar y devuelve el resultado al modelo

Ejemplos de clientes: Cursor, Claude Desktop, y en el futuro otros IDEs y asistentes que adopten el estándar.

Servidor MCP

Es un proceso (normalmente un programa que se ejecuta en tu máquina o en un servicio) que:

• Expone recursos: fuentes de contexto con un URI. El cliente puede leer el contenido de un recurso y pasarlo al modelo.
• Expone herramientas: funciones con nombre y parámetros que el modelo puede llamar; el servidor las ejecuta y devuelve la respuesta.

Un mismo servidor puede ofrecer solo recursos, solo herramientas, o ambos. Puede ser oficial (p. ej. de Anthropic), de la comunidad (GitHub, Notion, etc.) o uno que tú implementes para tu base de datos o API interna.

Recursos (resources)

Son fuentes de contexto identificadas por un URI. El servidor declara qué recursos ofrece y, cuando el cliente pide uno, devuelve su contenido (por ejemplo, texto o datos). El cliente incluye ese contenido en el contexto del modelo.

Ejemplos:

• Un archivo del sistema de archivos
• Una página de documentación
• El resultado de una consulta a una API o base de datos
• Un fragmento de tu código o de un repo

Los recursos son de solo lectura desde el punto de vista del modelo: sirven para dar contexto, no para modificar nada.

Herramientas (tools)

Son acciones que el modelo puede invocar. El servidor las define con un nombre y un esquema de parámetros (por ejemplo, en JSON Schema). Cuando el modelo decide llamar a una herramienta, el cliente envía la llamada al servidor, el servidor la ejecuta (consulta una API, escribe en un archivo, envía un email, etc.) y devuelve el resultado. Ese resultado se incorpora a la conversación para que el modelo continúe.

Ejemplos:

• Buscar en la web
• Crear o actualizar una tarea en un gestor de proyectos
• Ejecutar una consulta en una base de datos (lectura o escritura)
• Enviar un mensaje o una notificación

La diferencia importante: recursos = contexto que el modelo lee; herramientas = acciones que el modelo puede ejecutar.

Transporte: stdio y HTTP/SSE

El protocolo MCP se basa en JSON-RPC. La comunicación puede hacerse por:

• stdio: el cliente lanza el servidor como subproceso y se comunican por entrada/salida estándar. Es habitual para servidores que corren en tu máquina (p. ej. acceso al sistema de archivos).
• HTTP/SSE: el servidor expone un endpoint HTTP y, si aplica, Server-Sent Events. Útil para servidores remotos o en la nube.

Así puedes implementar servidores en cualquier lenguaje (TypeScript/Node, Python, Go, etc.) y reutilizarlos entre clientes que soporten MCP.

Cómo funciona el flujo en la práctica

1. Configuración: En el cliente (p. ej. Cursor o Claude Desktop) configuras uno o varios servidores MCP: comando o URL, y a veces variables de entorno (API keys, etc.).
2. Inicio: El cliente inicia el servidor (si es stdio) o se conecta al endpoint (si es HTTP). El servidor anuncia qué recursos y herramientas expone.
3. Conversación: Cuando tú preguntas algo, el cliente puede:
   • Pedir al servidor el contenido de recursos relevantes (por URI) y añadirlo al contexto del modelo
   • Mostrar al modelo la lista de herramientas disponibles
4. Decisión del modelo: El modelo puede responder solo con texto o decidir llamar a una herramienta (con parámetros).
5. Ejecución: El cliente envía la llamada a la herramienta al servidor; el servidor ejecuta y devuelve el resultado.
6. Siguiente turno: Ese resultado se pasa de vuelta al modelo, que puede seguir la conversación o invocar más herramientas.

Todo esto ocurre de forma transparente para ti: solo usas el asistente y, si está bien configurado, tendrá acceso a los recursos y herramientas que hayas conectado.

Recursos vs herramientas: cuándo usar cada uno

• Usa recursos cuando quieras que el modelo lea algo: documentación, archivos, resultados de una API de solo lectura, un fragmento de código. El modelo no cambia nada; solo usa esa información para responder.
• Usa herramientas cuando quieras que el modelo haga algo: crear una tarea, enviar un email, ejecutar una búsqueda, escribir en una base de datos. El servidor ejecuta la acción y devuelve el resultado.

En muchos casos tendrás ambos en el mismo servidor: recursos para dar contexto (p. ej. “estado actual del proyecto”) y herramientas para actuar (p. ej. “crear un issue en GitHub”).

Ejemplos de uso y servidores típicos

Desarrollo

• Sistema de archivos: exponer archivos o directorios del proyecto como recursos para que el asistente tenga contexto del código sin que tengas que copiarlo a mano.
• Documentación: un servidor que convierte tu doc (Markdown, OpenAPI) en recursos; el modelo puede consultar la API o la guía actualizada.
• Base de datos: recursos de solo lectura para esquemas o vistas; herramientas para ejecutar consultas (con cuidado y permisos limitados) o para generar migraciones.

Productividad

• Calendario y correo: recursos para “ver próximos eventos” o “últimos emails”; herramientas para “crear evento” o “enviar email”.
• Notion, Confluence, etc.: recursos que representan páginas o listas; herramientas para crear o editar páginas o tareas.

Datos y APIs

• Data warehouse o API interna: exponer métricas o endpoints como recursos para que el modelo responda preguntas sobre datos actuales.
• Búsqueda: herramienta “buscar en la web” o “buscar en tu base de conocimiento” para que el modelo pueda contrastar información en tiempo real.

Puedes buscar en la documentación oficial de MCP y en repositorios de la comunidad listas de servidores ya implementados (GitHub, Notion, bases de datos, etc.) y reutilizarlos o usarlos como referencia para crear el tuyo.

Cómo empezar: configurar un servidor en Cursor

En Cursor, la configuración de los servidores MCP suele estar en un archivo de configuración (por ejemplo en tu usuario o en el proyecto). La estructura típica es un JSON donde declaras cada servidor: nombre, comando (o URL si es HTTP), y opcionalmente variables de entorno.

Ejemplo conceptual (revisa la documentación actual de Cursor por la ruta y el formato exacto):

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/dir"]
    }
  }
}

Pasos recomendados:

1. Elige un cliente que soporte MCP (Cursor, Claude Desktop, etc.).
2. Revisa la lista de servidores existentes (oficiales y de la comunidad) en la documentación de MCP y en GitHub.
3. Añade uno o varios servidores en la configuración del cliente (comando, argumentos, env vars si piden API key).
4. Reinicia o recarga el cliente para que se conecte a los servidores.
5. En tus conversaciones, el modelo podrá usar los recursos y herramientas que cada servidor ofrezca.

Si quieres exponer algo propio (tu API, tu base de datos, tu doc), puedes implementar un servidor MCP en el lenguaje que prefieras siguiendo la especificación del protocolo (JSON-RPC, listado de recursos y herramientas, etc.).

Consideraciones de seguridad y límites

• Permisos: Un servidor MCP puede leer y, si expone herramientas, modificar datos. Configura solo servidores en los que confíes y, si es posible, limita permisos (p. ej. directorios concretos para un servidor de archivos, solo lectura para una BD).
• API keys y secretos: Si el servidor necesita keys, úsalas vía variables de entorno o gestor de secretos, no las pegues en el código ni en configs compartidas.
• Límites del modelo: El modelo decide cuándo usar recursos y herramientas; no siempre elegirá la óptima. Diseña recursos y herramientas con nombres y descripciones claras para que sea más fácil que las use bien.

Conclusión

MCP convierte la integración entre asistentes de IA y el mundo externo (archivos, APIs, bases de datos, servicios) en un estándar reutilizable: un mismo servidor sirve a varios clientes y una misma aplicación puede conectar muchos servidores. Si quieres que tu asistente tenga contexto real y pueda actuar sobre tus datos y herramientas, merece la pena revisar el protocolo, probar algún servidor ya hecho y, si hace falta, crear el tuyo para tu stack.

Para más detalles, especificación completa y ejemplos de servidores, consulta la documentación oficial del Model Context Protocol y los repositorios de referencia en GitHub.