¿Qué es un MCP y para qué sirve?

Le pides a una IA que revise tus correos y no puede. Que consulte tu base de datos, tampoco. Que mire los archivos de tu proyecto, menos. El modelo es capaz de razonar sobre casi cualquier cosa, pero está encerrado en una caja: solo sabe lo que le pegas en el chat.

MCP es la puerta de esa caja.

El problema que resuelve

Antes de MCP, conectar un modelo de IA a una herramienta externa significaba construir una integración a medida. Una para tu base de datos, otra para tu gestor de tareas, otra para tu correo. Y si cambiabas de modelo, a empezar de nuevo.

Anthropic lo describió como el problema N×M: N modelos por M herramientas, cada combinación con su propio conector. El resultado era un ecosistema fragmentado donde todo el mundo reconstruía lo mismo.

MCP —Model Context Protocol— reemplaza esa maraña con un solo protocolo. Construyes un conector una vez y funciona con cualquier aplicación de IA que hable el estándar.

La analogía que mejor lo explica: es el USB-C de la inteligencia artificial. Antes, cada dispositivo con su cargador. Ahora, un puerto común.

Qué es, en concreto

MCP es un protocolo abierto que estandariza cómo las aplicaciones de IA se conectan a fuentes de datos y herramientas externas.

Los datos verificables:

• Lo publicó Anthropic en noviembre de 2024 como proyecto de código abierto.
• Se apoya en tecnología probada: reutiliza las ideas de flujo de mensajes del Language Server Protocol y se transporta sobre JSON-RPC 2.0. No inventaron nada exótico.
• Fue adoptado por el resto de la industria —incluidos OpenAI, Google y Microsoft— y se convirtió en el estándar de facto.
• En diciembre de 2025, Anthropic donó el protocolo a la Agentic AI Foundation. Dejó de ser de una empresa.

Ese último punto importa más de lo que parece: un estándar controlado por un solo actor siempre carga el riesgo de que ese actor cambie de opinión. Uno donado a una fundación, mucho menos.

Cómo funciona: tres piezas

La arquitectura es simple y conviene entenderla antes de configurar nada.

El servidor MCP es un proceso pequeño y especializado que expone capacidades: uno para tu sistema de archivos, otro para una base de datos, otro para una API. Cada uno hace una cosa.

El cliente MCP vive dentro de la aplicación de IA que usas y mantiene la conexión con un servidor.

El anfitrión es la aplicación en sí —tu asistente, tu editor de código— y puede manejar varios clientes a la vez, uno por cada servidor conectado.

El flujo, paso a paso: le pides algo al asistente → el modelo determina que necesita una herramienta externa → el cliente envía la petición al servidor correspondiente → el servidor ejecuta (consulta la API, lee el archivo, escribe en la base) → devuelve el resultado → el modelo responde con información real, no inventada.

Lo que un servidor puede ofrecer

MCP define tres tipos de capacidades del lado del servidor, y la diferencia entre ellas es quién decide usarlas:

Esa columna de la derecha es la que casi nadie explica y la que más conviene tener clara: las herramientas las decide el modelo. No tú. Tú autorizas el acceso; el modelo elige cuándo tirar del gatillo. Volveremos a eso en la sección de seguridad.

Del lado del cliente el protocolo define otras primitivas —roots, sampling, elicitation— pero para empezar a usar MCP no necesitas manejarlas.

Local o remoto

Un servidor MCP puede correr de dos formas, y la distinción tiene consecuencias prácticas:

• Local (stdio): el servidor corre como un proceso en tu propia máquina. Ideal para archivos, bases de datos locales o herramientas internas. Nada sale de tu equipo.
• Remoto (HTTP): el servidor es un servicio alojado al que te conectas por internet. Es lo habitual para servicios en la nube.

Regla práctica: si el servidor toca datos sensibles y puede correr local, que corra local.

Ejemplos reales de configuración

⚠ [CONFIRMAR — completar con tu configuración real antes de publicar.] Los ejemplos siguientes describen usos típicos. Sustitúyelos por los MCP que de verdad tienes conectados y por lo que haces con cada uno; ese detalle es lo que hace útil esta sección.

Así es como uso MCP en mi trabajo diario:

[CONFIRMAR] Documentación y notas. Conectar el gestor de notas donde vive la documentación del proyecto permite que el asistente consulte decisiones ya tomadas en vez de que yo se las repita en cada conversación. El ahorro no es de tiempo: es de errores por contexto perdido.

[CONFIRMAR] Correo y calendario. Consultar la agenda o buscar un hilo de correo sin salir de la conversación. Aquí soy especialmente restrictivo con los permisos de escritura: leer, sí; enviar en mi nombre, no automáticamente.

[CONFIRMAR] Diseño. Conectar la herramienta de diseño para trabajar sobre piezas existentes en vez de describirlas de memoria.

[CONFIRMAR] Contabilidad / datos de negocio. Consultar información real del negocio para responder preguntas concretas, sin exportar hojas de cálculo a mano.

La lección general, más allá de cuáles uses: conecta pocos servidores y que cada uno tenga una razón. Cada MCP activo es una capacidad más para el modelo y también una superficie más de riesgo. La tentación de conectar todo "por si acaso" es exactamente la que hay que resistir.

Seguridad: lo que hay que tener claro

Esta es la parte que se salta la mayoría de tutoriales, y es la que más cuesta si se ignora.

Las descripciones de las herramientas no son de fiar por defecto. La guía de Google Cloud sobre MCP lo dice sin rodeos: no confíes en la descripción de una herramienta a menos que venga de un servidor confiable. El modelo lee esas descripciones para decidir qué usar; un servidor malicioso puede escribir ahí instrucciones diseñadas para manipularlo.

El "rug pull" es un riesgo real. Un servidor puede cambiar la definición de sus herramientas después de que tú aprobaste la conexión. Lo que autorizaste ayer no es necesariamente lo que corre hoy.

Toda entrada de una herramienta es no confiable. No viene del usuario: viene del modelo. Debe validarse con el mismo rigor que cualquier entrada externa.

Los permisos se dan uno por uno. Autoriza cada herramienta entendiendo qué hace antes de dejarla correr. "Aceptar todo" no es una configuración; es una apuesta.

La cadena de suministro también cuenta. Instalar un servidor MCP de origen dudoso es equivalente a instalar cualquier dependencia de origen dudoso: hereda todos los riesgos.

Nada de esto es motivo para no usar MCP. Es motivo para usarlo como se usa cualquier herramienta que toca tus datos: sabiendo qué le diste permiso de hacer.

Por dónde empezar

1. Elige una sola necesidad concreta. No "conectar todo", sino "quiero que el asistente lea la documentación de mi proyecto".
2. Busca si ya existe el servidor. Hay implementaciones de referencia mantenidas por el grupo del protocolo y un registro público de servidores publicados. Casi seguro alguien ya resolvió lo tuyo.
3. Conéctalo y pruébalo con algo inofensivo antes de darle acceso a nada importante.
4. Revisa los permisos de cada herramienta que autorizas.
5. Suma el siguiente solo cuando el primero te esté sirviendo de verdad.

Ojo con las implementaciones de referencia: el propio repositorio advierte que están pensadas como ejemplos educativos, no como soluciones listas para producción. Sirven para aprender y para arrancar, no para desplegarlas tal cual en algo serio.

Lo que cambia de verdad

MCP no hace que la IA sea más inteligente. Hace que deje de estar aislada.

Esa diferencia es la que separa un asistente al que le pegas contexto a mano de uno que trabaja con tus datos reales. Y es la base técnica sobre la que funcionan los agentes: sin acceso estandarizado a herramientas, un agente no puede hacer nada más que escribir texto.

La parte incómoda: cuanto más conectas, más puede hacer el modelo por su cuenta. Eso es exactamente lo que quieres y exactamente lo que hay que vigilar. El criterio no se delega junto con el acceso.

Fuentes

1. Anthropic (nov. 2024) — Introducing the Model Context Protocol. Anuncio original del estándar. → https://www.anthropic.com/news/model-context-protocol
2. Especificación oficial de MCP — versión 2025-11-25. → https://modelcontextprotocol.io/specification/2025-11-25
3. Google Cloud — What is Model Context Protocol (MCP)? Guía con las consideraciones de seguridad citadas. → https://cloud.google.com/discover/what-is-model-context-protocol
4. Repositorio oficial de servidores de referencia — implementaciones mantenidas por el grupo del protocolo. → https://github.com/modelcontextprotocol/servers

Verifica cada enlace antes de publicar: el protocolo está en desarrollo activo y la especificación se versiona por fecha.