MCP es el protocolo abierto que conecta apps de IA con herramientas y datos. Revisa roles, primitivas, transportes y seguridad en un laboratorio aislado.
El Model Context Protocol (MCP) es un protocolo abierto que permite a una aplicación de IA conversar con herramientas y datos externos de una forma estándar. Antes de MCP, cada app de IA que quería leer archivos, consultar una base de datos o abrir un ticket necesitaba su propia integración. MCP pone un único contrato entre la app y aquello a lo que se conecta. Una app que habla MCP puede usar cualquier servidor que hable MCP, y un servidor escrito una vez funciona con todo cliente que implemente el protocolo.
Si ya entiendes el uso de herramientas, conoces el ciclo básico. El modelo ve una lista de funciones, pide llamar a una con argumentos y recibe un resultado. MCP no sustituye ese ciclo. Lo que estandariza es de dónde sale la lista de funciones, por dónde viaja la llamada y qué más puede ofrecer un servidor aparte de funciones.
El protocolo está especificado en la revisión 2026-07-28, la que enlaza la página de especificación cuando se escribió este artículo. La especificación es la referencia para los nombres de campos y las reglas. Este artículo explica el modelo que hay detrás, para que leas la especificación y el código de los servidores con una idea clara.
Tres razones hacen que MCP valga la pena.
La primera es la reutilización. Un servidor de sistema de archivos, uno de GitHub o uno de base de datos se puede instalar en cualquier host compatible. Dejas de escribir el mismo código de pegamento para cada aplicación.
La segunda es el descubrimiento. El cliente le pregunta al servidor qué ofrece, y el servidor responde con nombres, descripciones y esquemas de entrada. El modelo puede entonces elegir entre capacidades que nadie fijó en el código de la aplicación.
La tercera es el riesgo. En cuanto un modelo puede acceder a tus archivos, repositorios o cuentas, la capa de herramientas se convierte en superficie de ataque. Muchos problemas de seguridad en IA vienen de un servidor que hace más de lo que su descripción dice, o de un host que llama herramientas sin preguntarle a nadie. MCP hace visibles estas preguntas. No las responde por ti.
La arquitectura tiene tres participantes. La especificación y la visión general de la arquitectura usan los mismos nombres.
El host es la aplicación de IA en la que trabaja el usuario. Claude Desktop, Claude Code y un IDE con asistente son hosts. El host decide a qué servidores conectarse y qué herramientas puede usar el modelo.
El cliente es un componente dentro del host. El host crea un cliente por servidor, y cada cliente mantiene una conexión dedicada con exactamente un servidor. Si un host se conecta a tres servidores, ejecuta tres clientes.
El servidor es un programa que expone capacidades. Puede correr en tu portátil como proceso hijo o en una máquina remota detrás de una URL. Los servidores locales suelen atender a un cliente. Los remotos, a menudo a muchos.
Un dibujo simple:
Host (tu app de IA)
├── Cliente A ── stdio ──> servidor de archivos (proceso local)
├── Cliente B ── stdio ──> servidor de base de datos (proceso local)
└── Cliente C ── HTTPS ──> servidor de tickets (remoto)Cada flecha transporta mensajes JSON-RPC 2.0. El protocolo tiene dos capas. La capa de datos define los mensajes y lo que significan. La capa de transporte define cómo se mueven.
Las primitivas determinan lo que un servidor puede ofrecer. La especificación nombra tres funciones del lado del servidor.
Tools (herramientas) son funciones que el modelo puede llamar. Una herramienta tiene un nombre, una descripción, un esquema de entrada en JSON Schema y un handler en el servidor. Listar herramientas usa tools/list. Ejecutar una usa tools/call. Las acciones ocurren en las herramientas: escribir un archivo, enviar una petición, ejecutar una consulta.
Resources (recursos) son datos que la aplicación puede leer por URI. Un recurso puede ser un archivo, una fila de base de datos o una respuesta de API. Los recursos son contexto. Leer uno no ejecuta ninguna acción, y el host decide cómo presentar ese contenido al modelo.
Prompts son plantillas de mensaje reutilizables que publica el servidor, a menudo con argumentos. El usuario elige un prompt como elige un comando, y el host lo completa y lo envía al modelo.
Los clientes también tienen funciones propias. Elicitation permite que un servidor pida al usuario más información durante una operación, como una confirmación o un valor que falta. Dos funciones antiguas del lado del cliente, sampling y logging, están marcadas como obsoletas en la revisión 2026-07-28. Sampling permitía que un servidor pidiera una completación al modelo del host. La visión general de la arquitectura dice que las implementaciones nuevas deben integrarse directamente con las APIs de los proveedores de modelos, y que el registro debe ir a stderr en stdio o usar OpenTelemetry.
Cada primitiva sigue el mismo patrón: un método */list para descubrir, un */get o */read para leer y un método de llamada cuando la primitiva es una acción. Las listas pueden cambiar en tiempo de ejecución. Un cliente que abre una suscripción puede recibir notificaciones de cambio, así que se actualiza sin tener que consultar.
El transporte es el camino por el que viajan los mensajes. La visión general de la arquitectura nombra dos.
stdio arranca el servidor como proceso hijo. El host escribe mensajes JSON-RPC en la entrada estándar del servidor y lee las respuestas de su salida estándar. No hay puerto de red. Es el transporte habitual de los servidores locales, y el que usarás en el laboratorio. La regla más importante: en stdio, la salida estándar pertenece al protocolo. Un print que se cuela en stdout corrompe el flujo. Los diagnósticos van a stderr.
Streamable HTTP pone el servidor detrás de un endpoint HTTP. El cliente envía mensajes con HTTP POST, y el servidor puede devolver respuestas o notificaciones en streaming usando Server-Sent Events. Es el transporte de los servidores remotos. Como queda expuesto a la red, trae los problemas habituales de HTTP: autenticación, TLS, verificación de origen y límites de tasa. La visión general de la arquitectura recomienda OAuth para obtener tokens.
La capa de datos es la misma en ambos. Una llamada a una herramienta se ve igual, pase por una tubería o por un socket.
Esta es la secuencia para un host que se conecta a un servidor local. Los mensajes exactos dependen de la revisión del protocolo, así que revisa la especificación antes de construir algo sobre ella.
server/discover, que todo servidor debe implementar. Llamarla es opcional, porque cada petición trae lo que el servidor necesita. El servidor responde con las versiones de protocolo que admite, sus capacidades y su identidad. En la revisión 2026-07-28, cada petición lleva la versión del protocolo y las capacidades del cliente en un campo _meta. El protocolo no guarda estado: cada petición trae lo necesario para procesarla, así que el servidor no depende de lo que pasó antes en la conexión.tools/list, resources/list y prompts/list para las funciones que el servidor declaró.tools/call. El servidor ejecuta el handler y devuelve un resultado con un arreglo content, que puede contener texto, imágenes o recursos incrustados. Una llamada fallida devuelve un resultado de error que el modelo puede leer.subscriptions/listen recibe un mensaje notifications/tools/list_changed y puede volver a pedir la lista.El host está entre los pasos 4 y 5. Es el componente que te pide aprobación, si la pide. Ese punto vuelve en la sección de seguridad.
MCP en sí no impone seguridad. La especificación lo dice en su sección de confianza y seguridad, y enumera los principios que quien implementa debe aplicar. Léelos como una lista de verificación para tu propia configuración.
Los usuarios deben consentir de forma explícita los accesos y operaciones que hace un servidor, y entenderlos. Los hosts deben obtener consentimiento explícito antes de exponer datos del usuario a un servidor y antes de invocar cualquier herramienta. La especificación también dice que las descripciones de las herramientas, incluidas las anotaciones, no son confiables salvo que vengan de un servidor en el que confíes. Un servidor puede afirmar que una herramienta es de solo lectura. Eso es una afirmación dentro de una cadena, y un servidor con errores o malicioso puede hacerla falsa.
En la práctica, son cuatro hábitos.
Trata un servidor como código que ejecutas. Un servidor stdio es un programa en tu máquina con los permisos de tu cuenta de usuario. Instalarlo es como instalar cualquier paquete. Lee su código fuente o, como mínimo, su README, mira quién lo publica y fija la versión que usas. Los servidores de referencia del repositorio oficial son un buen punto de partida, pero lee qué hace cada uno antes de activarlo.
Limita el acceso. Dale al servidor solo las carpetas, cuentas y ámbitos que necesita. El servidor de sistema de archivos del laboratorio recibe un directorio permitido como argumento, y todo lo que esté fuera se rechaza. Los servidores remotos deben recibir los ámbitos OAuth más estrechos disponibles y tokens que puedas revocar.
Exige aprobación para las acciones. Las herramientas de lectura y las que escriben, borran, envían o gastan son categorías distintas. Configura el host para que pregunte antes de ejecutar cualquier herramienta que cambie estado, y lee los argumentos antes de aprobar.
Vigila lo que vuelve. Los resultados de herramientas y el contenido de los recursos son datos. Pueden contener texto que parece una instrucción para el modelo, copiado de una página web o de un archivo. El host no debe tratar ese texto como una orden, y tú tampoco. Esta es la raíz de la inyección de prompts a través de herramientas, que tendrá su propio artículo.
Este laboratorio usa el servidor de referencia de sistema de archivos del repositorio oficial modelcontextprotocol/servers y el MCP Inspector oficial. No necesitas modelo, clave de API ni cuenta de pago. Sí necesitas Node.js. El Inspector requiere Node 22.19.0 o posterior, así que usa una versión LTS actual. Vas a crear una carpeta, arrancar el servidor con esa carpeta como único directorio permitido y comprobar lo que deja hacer.
Ejecuta estos comandos en la terminal donde quieras hacer el laboratorio. En Git Bash, Linux o macOS:
mkdir mcp-sandbox && echo 'hello from the sandbox' > mcp-sandbox/note.txtEn PowerShell, el mismo resultado sale de:
New-Item -ItemType Directory mcp-sandbox | Out-Null
Set-Content -Path mcp-sandbox\note.txt -Value 'hello from the sandbox'Arranca el Inspector con el servidor como objetivo:
npx @modelcontextprotocol/inspector npx -y @modelcontextprotocol/server-filesystem ./mcp-sandboxEl Inspector imprime una URL local con un token para esta ejecución, y la abre en tu navegador. Deja la terminal abierta, porque el servidor corre como proceso hijo del Inspector mientras lo uses. La primera ejecución puede tardar porque npx descarga los paquetes. Si la conexión falla mientras los paquetes aún se descargan, espera un minuto e inténtalo de nuevo. En modo CLI, --connect-timeout sube el límite, y los comandos de abajo lo usan.
En la página web, haz clic en Connect. Después abre la pestaña que lista las herramientas del servidor y ejecuta la acción de listar. Las etiquetas cambian entre versiones, así que busca la pestaña y el botón que muestran las herramientas. Deberías ver las herramientas del sistema de archivos. En la versión que probé, el servidor de referencia expuso dieciséis herramientas, entre ellas list_directory, read_text_file, write_file y list_allowed_directories. read_file sigue existiendo y aparece marcada como obsoleta a favor de read_text_file.
Ejecuta primero list_allowed_directories. Te dice lo que el servidor va a aceptar. El resultado muestra una sola ruta, la ubicación absoluta de mcp-sandbox. Nada más es alcanzable.
Selecciona list_directory y pasa . como ruta, que significa el propio directorio permitido. El resultado debe listar una entrada: [FILE] note.txt.
Selecciona read_text_file y pasa note.txt como ruta. El resultado debe contener el texto que escribiste, hello from the sandbox.
Fíjate en la ruta. Es note.txt, no ./mcp-sandbox/note.txt. El servidor resuelve las rutas relativas desde su directorio permitido, no desde la carpeta donde abriste el Inspector. Yo cometí este error en mi primer intento. El servidor devolvió un error de "archivo no encontrado" para una ruta que había resuelto como mcp-sandbox\mcp-sandbox\note.txt. El mensaje de error me mostró qué ruta usó realmente el servidor, por eso conviene leer el texto de los errores con atención.
Crea un archivo en la carpeta padre, un nivel por encima de mcp-sandbox:
echo 'this file is outside the sandbox' > outside.txtDe vuelta en el Inspector, llama a read_text_file con la ruta ../outside.txt. Espera un resultado de error, no el contenido del archivo. En mi máquina, el servidor devolvió este texto, con la ruta acortada:
Access denied - path outside allowed directories: ...\mcplab\outside.txt not in ...\mcplab\mcp-sandboxLuego prueba con una ruta absoluta al mismo archivo. El resultado debe ser la misma negativa. La comprobación se hace dentro del servidor, sobre la ruta ya resuelta, así que la petición falla sin importar cómo escribas la ruta.
Así se ve el alcance en la práctica. El servidor es código que corre en tu máquina con los permisos de tu usuario, y aun así no puede leer la carpeta padre, porque se inició con un único directorio permitido y aplica esa lista. Prueba más rutas si quieres, como .. solo o una carpeta que no existe, y compara los textos de error.
Ejecuté las mismas llamadas con el modo CLI del Inspector, que envía los mismos mensajes JSON-RPC que el cliente web:
npx @modelcontextprotocol/inspector --cli --connect-timeout 120000 npx -y @modelcontextprotocol/server-filesystem ./mcp-sandbox --method tools/call --tool-name read_text_file --tool-arg path=note.txtLa respuesta llegó como JSON, y el contenido de texto fue hello from the sandbox seguido de un salto de línea. El mismo comando con --tool-name list_allowed_directories mostró la única ruta permitida. La llamada ../outside.txt devolvió la negativa mostrada arriba. Las versiones de los paquetes el día de la ejecución fueron @modelcontextprotocol/inspector 2.14.0 y @modelcontextprotocol/server-filesystem 2.2.0. El servidor imprimió Secure MCP Filesystem Server running on stdio en stderr, que es la regla de stdio en acción. Su salida estándar quedó reservada para mensajes del protocolo.
Lo ejecuté en Windows 11 con Git Bash y Node 24, y no usé la página web en estas ejecuciones. Tus versiones y rutas serán distintas, y la lista de herramientas puede cambiar entre versiones.
Tratar MCP como una función del modelo. MCP es un protocolo entre host y servidor. El modelo solo ve lo que el host le pasa. El mismo servidor puede comportarse distinto en dos hosts si uno muestra mejor las descripciones de las herramientas o pide aprobación en otro punto.
Confundir un servidor publicado con uno auditado. Instalar un servidor ejecuta su código. Que un paquete esté en un registro público no dice nada sobre su seguridad.
Dar acceso de escritura por defecto. Empieza en solo lectura. Añade ámbitos de escritura solo cuando una tarea los necesite.
Imprimir en stdout en un servidor stdio. Los registros y los prints de depuración escritos en stdout rompen el protocolo. Usa stderr.
Confiar en las anotaciones de las herramientas. Una herramienta marcada como de solo lectura sigue ejecutando el código que contiene el servidor.
Construir a partir de un resumen de la especificación. Las revisiones cambian nombres de métodos y funciones obsoletas. Revisa la revisión que implementa tu SDK y lee la especificación para los nombres exactos de los campos antes de escribir código.
Esperar que el Inspector audite. El Inspector muestra lo que el servidor devuelve al cliente. Es una vista de depuración, no una revisión de seguridad.
Lee primero la visión general de la arquitectura, y después las páginas de conceptos de servidor y de cliente. Explican las primitivas con más ejemplos. Luego lee las secciones de protocolo base y de seguridad de la especificación, porque fijan las reglas que deben seguir todos los servidores y hosts.
Abre el código fuente del servidor de referencia de sistema de archivos. Es corto y muestra cómo un handler revisa las rutas y devuelve errores. Después escribe un servidor pequeño propio, con una herramienta que devuelva una cadena fija, usando un SDK oficial, e inspecciónalo con el Inspector antes de añadir cualquier cosa que toque tus archivos.
Mantén la carpeta del laboratorio pequeña y desechable, y bórrala cuando termines. El siguiente artículo de esta serie, qué es la inyección de prompts en aplicaciones con LLM, trata el ataque que hacen posible los resultados de las herramientas. Para el contexto que este artículo supone, empieza por qué son los agentes de IA y el uso de herramientas.
Agentes de IA para seguridad
Cómo funciona el uso de herramientas: el modelo devuelve una llamada estructurada, tu programa la ejecuta y la aprobación decide qué se permite.