)
Última actualización: 15 de octubre, 2026
¿Qué es un servidor MCP? Un servidor MCP es un programa que expone herramientas, datos y plantillas de prompts a una aplicación de IA a través del Model Context Protocol (MCP). Puede ejecutarse en local o en remoto, y permite que un agente de IA actúe sobre un sistema como una base de datos, un repositorio de código o una app SaaS. Esta guía explica cómo funciona, cuándo necesitas uno y cómo ejecutarlo con seguridad.
TL;DR: puntos clave
- Un servidor MCP expone 3 tipos de primitivas (recursos, herramientas y prompts), y cada cliente mantiene una relación 1:1 con un solo servidor, según la especificación de MCP, página de arquitectura (revisión 2026-07-28).
- Streamable HTTP es el transporte principal para servidores remotos. El antiguo transporte HTTP+SSE está obsoleto, y la revisión 2026-07-28 eliminó las sesiones a nivel de protocolo, según la especificación de MCP, página de Streamable HTTP.
- La guía de seguridad de MCP recoge al menos 9 patrones de ataque con nombre, desde el confused deputy hasta el token passthrough, y establece que los servidores no deben aceptar ningún token que no se haya emitido explícitamente para ellos (buenas prácticas de seguridad de MCP).
- La Cloud Security Alliance cita el benchmark MCPTox: la tasa de éxito de los ataques superó el 60 % en más de 45 servidores MCP reales, y el mejor modelo llegó al 72,8 % (CSA, julio de 2026).
- El OWASP MCP Top 10, todavía en beta, enumera 10 riesgos, entre ellos el tool poisoning (MCP03) y los servidores MCP en la sombra (MCP09) (OWASP).
Conceptos de un servidor MCP de un vistazo
| Término | Qué es | Ejemplo |
|---|---|---|
| Host | La aplicación de IA que crea los clientes y aplica el consentimiento | Un asistente de programación con IA |
| Cliente | Un componente del host que habla con exactamente un servidor | Un cliente por cada servidor conectado |
| Servidor MCP | Un programa que expone herramientas, recursos y prompts | Un servidor de archivos y Git, o de base de datos |
| Herramienta (tool) | Una función que el modelo puede invocar | get_weather |
| Recurso | Datos que un cliente puede leer | Contenido de archivos |
| Prompt | Una plantilla reutilizable que elige el usuario | Un comando con barra |
| Transporte | Cómo viajan los mensajes entre cliente y servidor | stdio o Streamable HTTP |
¿Qué es un servidor MCP?
Un servidor MCP es la parte del Model Context Protocol que se sitúa junto a tus datos o herramientas. Anuncia lo que puede hacer, acepta peticiones de un cliente MCP, ejecuta la operación solicitada y devuelve el resultado. El servidor no contiene ningún modelo. Solo aporta contexto y capacidades a la aplicación de IA que se conecta a él.
Nuestra guía sobre el Model Context Protocol explica el protocolo en conjunto. Este artículo se centra en el lado del servidor: qué expone, cómo se comunica y cómo operarlo con seguridad.
Servidor MCP frente a cliente y host
La especificación describe una arquitectura cliente-host-servidor. El proceso host crea las instancias de cliente, controla sus permisos y aplica la política de seguridad y el consentimiento. Cada cliente se comunica con exactamente un servidor, y un servidor puede ser un proceso local o un servicio remoto, según la página de arquitectura.
Un principio de diseño importa para la seguridad. La especificación establece que un servidor no debería poder leer toda la conversación ni «ver dentro» de otros servidores. Por tanto, un servidor solo recibe el contexto que el host decide enviarle.
Servidor MCP frente a API
Una API es un contrato fijo escrito para desarrolladores. Un servidor MCP envuelve capacidades en un formato que se describe a sí mismo, de modo que una aplicación de IA pueda descubrirlas en tiempo de ejecución, pedir aprobación al usuario e invocarlas con argumentos tipados. Muchos servidores MCP llaman a una API convencional por debajo.
Un servidor añade descubrimiento y un modelo de consentimiento, no un acceso nuevo a los datos. Si la API que hay detrás tiene demasiados permisos, el servidor hereda ese problema.
Por qué importan los servidores MCP
Los servidores MCP importan porque permiten que una sola integración sirva a muchas aplicaciones de IA. Los principios de diseño de la especificación dicen que los servidores deben ser extremadamente fáciles de construir y muy componibles. Un equipo escribe un servidor una vez y cualquier host compatible puede usarlo.
Esa misma comodidad crea una nueva frontera de confianza. Un servidor puede guardar credenciales, ejecutar código en un portátil o devolver texto que el modelo lee como instrucciones. La documentación de Claude Code de Anthropic lo dice sin rodeos: «Verify you trust each server before connecting it», es decir, verifica que confías en cada servidor antes de conectarlo (documentación de Claude Code).
OWASP mantiene ya un MCP Top 10 específico, todavía en beta. Sus entradas parecen un mapa de los fallos del lado del servidor, y volvemos a ellas en la sección de seguridad.
)
Qué expone un servidor MCP: herramientas, recursos y prompts
Un servidor MCP expone tres primitivas. Las herramientas son funciones que el modelo puede invocar, los recursos son datos que el cliente puede leer y los prompts son plantillas que el usuario puede lanzar. Cada primitiva tiene una parte distinta al mando, lo que determina dónde deben situarse la aprobación y la validación.
| Primitiva | Quién la controla | Qué hace | Ejemplo |
|---|---|---|---|
| Herramientas | El modelo | Funciones que el modelo decide invocar | Escribir un archivo, enviar una petición a una API |
| Recursos | La aplicación | Datos de contexto que adjunta el cliente | Contenido de archivos, historial de Git |
| Prompts | El usuario | Plantillas que se lanzan por elección del usuario | Comandos con barra, opciones de menú |
Las etiquetas de control y los ejemplos proceden de la vista general de funciones de servidor de la especificación (revisión 2025-03-26). Las herramientas son las que más riesgo implican, porque es el modelo, y no el usuario, quien decide cuándo invocarlas.
Anatomía de una herramienta
La definición de una herramienta tiene un nombre único, una descripción legible y un inputSchema escrito en JSON Schema. También puede incluir un outputSchema y anotaciones opcionales. Un servidor que admite herramientas declara la capacidad tools y puede avisar a los clientes cuando cambia su lista de herramientas, según la página de herramientas (revisión 2025-11-25).
La descripción es lo que hay que vigilar. El modelo la lee para decidir cuándo invocar la herramienta, así que funciona como una instrucción que escribió otra persona. La especificación indica que los clientes deben tratar las anotaciones de las herramientas como no fiables salvo que procedan de servidores de confianza, y añade que siempre debería haber una persona en el circuito con capacidad de denegar las invocaciones de herramientas.
Cómo funciona un servidor MCP: transportes y una llamada a una herramienta
Un servidor MCP habla con un cliente por uno de los dos transportes de la especificación: stdio para procesos locales y Streamable HTTP para servicios locales o remotos. Ambos transportan los mismos mensajes JSON-RPC. La elección decide quién puede alcanzar el servidor, cómo autentica a quien le llama y qué ataques aplican.
| stdio | Streamable HTTP | |
|---|---|---|
| Dónde se ejecuta el servidor | Un proceso local que arranca el cliente | Un servicio HTTP local o remoto |
| Cómo viajan los mensajes | JSON-RPC por entrada y salida estándar | Cada mensaje es un HTTP POST a un único endpoint MCP, con respuesta en JSON o en un flujo SSE |
| Autenticación | Las credenciales vienen del entorno | Se recomienda la autorización OAuth 2.1 para servidores basados en HTTP |
| Riesgo principal | El código se ejecuta con los privilegios del cliente | DNS rebinding, gestión de tokens, exposición de red |
La documentación de Claude Code muestra ambos en la práctica. Recomienda HTTP para servicios remotos en la nube, marca SSE como obsoleto y usa stdio para procesos locales y scripts propios. La especificación de autorización dice que las implementaciones basadas en HTTP deberían seguirla, mientras que las de stdio no deberían y han de obtener las credenciales del entorno.
Cómo fluye una llamada a una herramienta
Una llamada a una herramienta pasa por seis etapas. La tabla sigue la revisión 2026-07-28 para el protocolo y la página de herramientas de 2025-11-25 para los mensajes de las herramientas.
| Etapa | Quién actúa | Qué ocurre |
|---|---|---|
| 1. Descubrir | Cliente y servidor | El cliente conoce las capacidades del servidor y lista sus herramientas con tools/list |
| 2. Seleccionar | El modelo, a través del host | El modelo elige una herramienta según la petición del usuario y las descripciones |
| 3. Aprobar | Host y usuario | El host muestra la herramienta y sus entradas, y el usuario puede denegar la llamada |
| 4. Llamar | Cliente | El cliente envía tools/call con el nombre de la herramienta y los argumentos |
| 5. Ejecutar | Servidor | El servidor valida la entrada, comprueba el acceso y ejecuta la operación |
| 6. Devolver | Servidor y cliente | El servidor devuelve contenido y un indicador isError, y el cliente valida el resultado antes de que lo lea el modelo |
Las etapas 3 y 6 son donde encajan la mayoría de los controles. Los servidores deben validar las entradas, aplicar controles de acceso, limitar la frecuencia de las invocaciones y sanear las salidas. Los clientes deberían confirmar las operaciones sensibles y validar los resultados antes de que el modelo los vea.
Qué cambió en la revisión 2026-07-28
La última revisión cambió la forma en que los servidores gestionan las conexiones. Comprueba qué revisión hablan tu SDK y tus clientes antes de desplegar.
| Área | Revisiones 2025-03-26 a 2025-11-25 | Revisión 2026-07-28 |
|---|---|---|
| Inicio de la conexión | Handshake initialize y una sesión opcional con Mcp-Session-Id | Sin sesiones a nivel de protocolo; cada petición lleva su versión de protocolo y las capacidades del cliente |
| Flujo independiente | El cliente podía abrir un flujo SSE con HTTP GET | Endpoint de flujo GET eliminado |
| Peticiones iniciadas por el servidor | Se enviaban por flujos SSE | Se devuelven dentro de los resultados como peticiones de entrada |
| Reanudación de flujos | Reanudables con Last-Event-ID | No se admite |
Fuentes: la página de Streamable HTTP y la página de arquitectura. Los servidores que aún necesitan estado entre peticiones emiten un identificador explícito, como el ID de un carrito. La guía de seguridad advierte de que un identificador adivinado no debe dar acceso al estado de otro usuario.
Streamable HTTP también replica el método y el nombre de la herramienta en cabeceras HTTP. El objetivo es que los intermediarios puedan enrutar e inspeccionar las peticiones sin analizar el cuerpo. Los servidores deben rechazar las peticiones en las que cabeceras y cuerpo no coincidan.
Ejemplos de servidores MCP y cuándo necesitas uno
El diagrama de arquitectura de la especificación muestra tres servidores típicos: archivos y Git y una base de datos, ambos en la máquina local, y uno de APIs externas en internet. Dónde se ejecuta un servidor y qué hay detrás de él definen su perfil de riesgo.
La documentación de Claude Code añade casos concretos: un servidor stdio local para Airtable que se arranca con npx, y servidores HTTP remotos para Stripe y HubSpot.
Necesitas tu propio servidor MCP cuando un agente debe llegar a un sistema que no tiene servidor publicado, o cuando quieres controlar exactamente qué herramientas ve el agente. Puedes prescindir de él cuando una sola aplicación llama a una sola API.
| Situación | Mejor opción | Motivo |
|---|---|---|
| Un proveedor SaaS ya publica un servidor | Conecta el servidor remoto del proveedor tras revisarlo | No hay código que mantener, pero heredas sus descripciones de herramientas |
| Los agentes necesitan datos internos, como tickets o una base de datos | Construye un servidor con pocas herramientas acotadas | Controlas las descripciones, los esquemas y los permisos |
| Una app llama a una API con lógica fija | Llama a la API directamente | El descubrimiento en tiempo de ejecución no aporta valor |
| Muchos equipos ejecutan muchos servidores | Añade un punto de política entre agentes y servidores | Un único lugar para aplicar permisos y límites |
Cómo construir o ejecutar un servidor MCP
Construir un servidor empieza en pequeño. Elige un SDK para tu lenguaje, expón una herramienta acotada y conéctala a un cliente que controles. La mayor parte del esfuerzo va al diseño de las herramientas y al control de acceso, no a la mecánica del protocolo.
Diseña herramientas acotadas
Escribe cada herramienta para una sola tarea, con una descripción precisa y un esquema de entrada estricto. Para una herramienta sin parámetros, la especificación recomienda { "type": "object", "additionalProperties": false }. Devuelve errores accionables con isError: true, porque el modelo puede usarlos para corregir el reintento.
Mantén la salida pequeña. Claude Code muestra un aviso cuando la salida de una herramienta MCP supera los 10.000 tokens y fija un máximo por defecto de 25.000 tokens.
Conéctalo a un cliente
En Claude Code, un servidor remoto se añade con claude mcp add --transport http <name> <url> y uno local con claude mcp add <name> -- <command>. Un servidor puede tener alcance local (el predeterminado), de proyecto (compartido en .mcp.json) o de usuario (todos tus proyectos). Para los archivos con alcance de proyecto, Claude Code pide aprobación en las sesiones interactivas, y un repositorio clonado no puede aprobar sus propios servidores.
Ejecútalo con el transporte adecuado
Usa stdio para herramientas que sirven a una persona en una máquina. Usa Streamable HTTP cuando varias personas o agentes comparten el servidor, y pon autenticación delante.
Seguridad y gobernanza de los servidores MCP
Los servidores MCP concentran riesgo porque combinan credenciales, código ejecutable y texto en el que el modelo confía. Las amenazas principales son el tool poisoning, el prompt injection a través de la salida de las herramientas, las herramientas con demasiados permisos, la gestión descuidada de tokens y los servidores locales o sin revisar. Cada una tiene un control publicado.
| Amenaza | Qué ocurre | Control |
|---|---|---|
| Tool poisoning y rug pulls | Instrucciones ocultas en la descripción de una herramienta dirigen al agente, o la descripción cambia tras la aprobación | Revisar las descripciones completas, fijar hashes y volver a revisar ante cambios |
| Prompt injection por la salida de herramientas | Una herramienta devuelve texto que el modelo trata como instrucciones | Tratar los resultados como no fiables, validarlos y sanearlos |
| Herramientas con demasiados permisos | Un scope o una herramienta amplios hacen que un error alcance muchos sistemas | Scopes de mínimo privilegio, herramientas acotadas, aprobación humana |
| Mal uso de tokens | Un servidor acepta o reenvía tokens pensados para otros servicios | Validar la audiencia, no reenviar nunca tokens |
| Compromiso de un servidor local | Un servidor descargado ejecuta código con los privilegios del usuario | Mostrar el comando exacto, aislar en un sandbox, restringir el acceso |
| Servidores sin revisar | Un servidor no fiable o en la sombra entra en el entorno | Inventario, lista de permitidos, nueva revisión en cada actualización |
Tool poisoning y rug pulls
El tool poisoning oculta instrucciones adversarias en las descripciones de las herramientas o en metadatos similares. La nota de investigación de julio de 2026 de la Cloud Security Alliance describe cuatro variantes: envenenamiento de descripciones, rug pulls en los que una definición cambia tras la aprobación, tool shadowing entre servidores y compromiso de la cadena de suministro.
La nota cita el benchmark MCPTox, que informa de un éxito de ataque superior al 60 % en más de 45 servidores MCP reales y del 72,8 % para el modelo de agente con mejor resultado. Son resultados de un benchmark comunicados por investigadores, no una medida de tu entorno. La nota también recoge el CVE-2025-6514, con un CVSS de 9,6, en la biblioteca mcp-remote, que tenía cerca de medio millón de descargas cuando se divulgó.
La CSA recomienda mantener un inventario, calcular el hash de los manifiestos de herramientas al aprobarlos y verificarlos de nuevo, y permitir solo servidores aprobados. Nuestra guía MCP Security 101 explica el ataque en detalle.
Prompt injection a través de la salida de las herramientas
El resultado de una herramienta vuelve al modelo, así que cualquier texto que una herramienta recupere puede llevar instrucciones. El MCP Top 10 de OWASP lo recoge como MCP06: Prompt Injection via Contextual Payloads. La documentación de Claude Code advierte igualmente de que los servidores que obtienen contenido externo pueden exponerte a prompt injection.
Los servidores deben sanear las salidas, y los clientes deberían validar los resultados de las herramientas antes de pasarlos al modelo. Nuestra guía sobre prompt injection en MCP muestra cómo una instrucción inyectada viaja desde el resultado de una herramienta hasta la siguiente acción de un agente.
Herramientas con demasiados permisos y scopes
Un servidor con demasiados permisos convierte un error pequeño en uno grande. La guía de seguridad sobre minimización de scopes desaconseja publicar todos los scopes de entrada y usar scopes comodín o generales como *, all o full-access. Recomienda un conjunto inicial mínimo de scopes y peticiones de elevación cuando se intenta por primera vez una operación privilegiada.
OWASP recoge el mismo patrón como MCP02: Privilege Escalation via Scope Creep. Nuestra guía sobre excessive agency cubre el problema más amplio.
Gestión de tokens
Un servidor MCP protegido actúa como servidor de recursos OAuth 2.1. La especificación de autorización le exige validar que los tokens de acceso se emitieron específicamente para él. También establece que el servidor no debe aceptar ni reenviar ningún otro token. Los tokens no deben aparecer en la cadena de consulta de la URI.
El token passthrough es el antipatrón que evita esa regla. La guía de seguridad indica que puede saltarse controles como la limitación de frecuencia, difuminar la pista de auditoría y convertir el servidor en un proxy de exfiltración si se roba un token. También describe un problema de confused deputy en los servidores proxy MCP que usan un client ID estático con registro dinámico y una cookie de consentimiento. La solución es el consentimiento por cliente antes de cualquier paso de autorización de terceros.
Servidores locales, comprobaciones de Origin y localhost
Un servidor local se ejecuta con los privilegios del cliente que lo arranca. La guía de seguridad advierte de que un comando de arranque malicioso puede ejecutar código arbitrario, por lo que los clientes con configuración en un clic deben mostrar el comando exacto y exigir aprobación explícita. También recomienda aislar en un sandbox con privilegios mínimos por defecto.
Para Streamable HTTP, la especificación fija tres reglas. Los servidores deben validar la cabecera Origin en todas las conexiones entrantes y responder con HTTP 403 Forbidden cuando esté presente y sea inválida, para evitar el DNS rebinding. Los servidores que se ejecutan en local deberían enlazar solo a 127.0.0.1 y no a 0.0.0.0. Los servidores deberían implementar una autenticación adecuada en todas las conexiones.
Revisar servidores y registros
Un registro te dice quién publicó un servidor, no si su código es seguro. El MCP Registry oficial, que está en preview, usa autenticación de espacios de nombres para que solo el propietario de una cuenta de GitHub o de un dominio pueda publicar bajo ese nombre. Delega el análisis de seguridad en registros de paquetes como npm y PyPI y en agregadores posteriores.
Trata cada servidor como una dependencia de terceros: comprueba el editor y el código fuente, lee las definiciones de las herramientas completas y vuelve a revisar cuando cambie la versión. OWASP recoge los servidores MCP en la sombra como MCP09, por lo que el inventario va primero.
Cómo evaluar y ejecutar un servidor MCP con seguridad
Usa este procedimiento antes de que cualquier servidor llegue a producción. Combina los requisitos de la especificación con mitigaciones de OWASP y de la CSA.
- Haz inventario de cada servidor. Lista todos los servidores MCP que usan tus equipos, incluidos los añadidos al margen de compras de TI, y anota el responsable y los sistemas a los que llegan.
- Comprueba la procedencia. Confirma el editor, el repositorio de código y el espacio de nombres. Un espacio de nombres del registro demuestra la titularidad de una cuenta o dominio, no la seguridad del código.
- Lee las definiciones de las herramientas completas. Revisa nombres, descripciones y esquemas de entrada, y guarda un hash de cada uno al aprobarlos para detectar cambios posteriores.
- Elige el transporte y las credenciales más estrechos. Usa stdio para herramientas locales de un solo usuario y Streamable HTTP protegido con OAuth para servidores compartidos. Pide scopes mínimos y no reenvíes tokens nunca.
- Aísla y enlaza con cuidado. Ejecuta los servidores locales con acceso restringido a archivos y red, enlaza los servidores HTTP locales a 127.0.0.1 y valida la cabecera
Origin. - Mantén a una persona en el circuito en las herramientas de alto impacto. Muestra la herramienta y sus entradas antes de la llamada, exige aprobación para escrituras y pagos, y trata la salida de las herramientas como no fiable.
- Registra, prueba y vuelve a revisar. Registra las cargas de definiciones de herramientas y las invocaciones, prueba casos de poisoning e injection antes del despliegue y vuelve a revisar un servidor cada vez que se actualice.
Cómo aborda NeuralTrust el riesgo de los servidores MCP
NeuralTrust es una empresa de seguridad para agentes de IA con sede en Barcelona. Agent Gateway (TrustGate) se sitúa entre agentes, flujos de trabajo, modelos y herramientas MCP, aplica permisos y límites por agente y ofrece más de 200 servidores MCP prediseñados. Así se aborda el problema de las herramientas con demasiados permisos en un único punto de política, en lugar de servidor por servidor.
Agent Runtime Security (TrustGuard) detecta prompt injection y fugas de datos en tiempo de ejecución, lo que cubre el riesgo de la salida de las herramientas. Agent Posture Management (TrustLens) inventaría agentes y sus conexiones, lo que apoya el paso 1 anterior. AI Red Teaming (TrustTest) prueba los agentes antes del lanzamiento, que es donde encajan los casos de prueba de poisoning e injection. Juntos forman el Runtime Security Mesh, y NeuralTrust cuenta con cuatro reconocimientos en los Gartner Hype Cycle 2026 por AI Runtime Defense.
Nada de esto sustituye lo básico del lado del servidor. Los tokens con la audiencia comprobada, la validación de entradas y los scopes de mínimo privilegio siguen siendo responsabilidad de quien opera el servidor.
¿Qué configuración deberías elegir?
Elige la configuración que encaje con quién usa el servidor y a qué puede llegar. Una herramienta personal y una integración empresarial compartida necesitan transportes, credenciales y reglas de aprobación distintos.
| Tu situación | Configuración | Motivo |
|---|---|---|
| Desarrollador individual en una máquina | Un servidor stdio local de una fuente que hayas revisado, en un sandbox | La especificación indica que stdio limita el acceso solo al cliente |
| Un equipo que comparte una integración SaaS | El servidor HTTP remoto del proveedor con OAuth y scopes mínimos | Los servidores basados en HTTP deberían seguir la especificación de autorización |
| Agentes que necesitan datos internos | Tu propio servidor con pocas herramientas acotadas | Controlas descripciones, esquemas y permisos |
| Muchos equipos y muchos servidores | Un inventario más un gateway entre agentes y servidores | Un único lugar para permisos, límites y registros |
| Una app, una API fija | Llama a la API directamente | El descubrimiento en tiempo de ejecución no aporta valor |
Conclusión
La respuesta a «qué es un servidor MCP» se resume en una idea: convierte un sistema en algo que un agente de IA puede descubrir y usar, mediante herramientas tipadas, recursos legibles y prompts reutilizables. Esa comodidad traslada la confianza al servidor, porque sus descripciones de herramientas, sus tokens y su código determinan lo que hace el agente. Elige el transporte que encaje con tus usuarios, acota los tokens, revisa cada servidor como una dependencia y mantén la aprobación humana en las herramientas de alto impacto.
Protege los servidores MCP en producción con NeuralTrust
Pon un único gateway entre tus agentes y tus servidores MCP, con permisos y límites por agente.
)
Comparativas relacionadas
Preguntas frecuentes sobre qué es un servidor MCP
1. ¿Qué es un servidor MCP en pocas palabras?
Un servidor MCP es un programa que da a una aplicación de IA acceso controlado a una herramienta o fuente de datos. Lista lo que puede hacer, acepta peticiones de un cliente MCP, ejecuta la operación y devuelve el resultado. Puede ejecutarse en local o en remoto, y no contiene ningún modelo propio.
2. ¿Cuál es la diferencia entre un servidor MCP y un cliente MCP?
El servidor expone herramientas, recursos y prompts. El cliente vive dentro de la aplicación host y se conecta a exactamente un servidor. El host crea los clientes, aplica el consentimiento y decide qué contexto recibe cada servidor.
3. ¿Un servidor MCP es lo mismo que una API?
No. Una API es un contrato fijo para desarrolladores, mientras que un servidor MCP describe sus capacidades de una forma que una aplicación de IA puede descubrir en tiempo de ejecución e invocar con aprobación del usuario. Muchos servidores MCP llaman a una API por debajo, así que heredan sus permisos y debilidades.
4. ¿Un servidor MCP debe ejecutarse en local o en remoto?
Ejecútalo en local por stdio cuando sirva a una persona en una máquina. Ejecútalo en remoto por Streamable HTTP cuando lo compartan un equipo o varios agentes, y protégelo con OAuth. Los servidores locales se ejecutan con los privilegios del cliente, así que necesitan un sandbox y un origen revisado.
5. ¿Son seguros los servidores MCP?
Un servidor MCP es tan seguro como su código, sus descripciones de herramientas y sus permisos. La especificación fija requisitos de validación de tokens, comprobaciones de Origin y consentimiento, y OWASP enumera 10 riesgos de MCP en beta. Revisa cada servidor como una dependencia, limita sus scopes y mantén la aprobación humana en las herramientas de alto impacto.
6. ¿Qué es el tool poisoning en MCP?
El tool poisoning oculta instrucciones adversarias en la descripción o los metadatos de una herramienta, que el modelo lee como contexto de confianza. La Cloud Security Alliance describe variantes como los rug pulls, en los que una descripción cambia tras la aprobación. Las defensas incluyen revisar las descripciones completas, fijar hashes y volver a revisar los servidores cuando se actualizan.
7. ¿Cómo protejo un servidor MCP remoto?
Pon OAuth 2.1 delante y valida que cada token se emitió para tu servidor. No aceptes ni reenvíes nunca tokens pensados para otros servicios. Valida la cabecera Origin, mantén los scopes mínimos, valida las entradas, limita la frecuencia de las llamadas y sanea las salidas.
Sobre el autor
Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde lidera la estrategia de búsqueda de la empresa en SEO, AEO, GEO y optimización para LLM. Se especializa en búsqueda con IA, estrategia de contenidos y SEM. Conecta en LinkedIn.
NeuralTrust es la plataforma líder para proteger y escalar agentes de IA. Reconocida como Pioneer en el Gartner Emerging Market Quadrant for AI Application Security 2026, destacada en cuatro informes Gartner Hype Cycle en 2026 y presente en el Gartner Market Guide for Guardian Agents 2026, el Gartner Market Guide for AI Gateways 2025 y el KuppingerCole Leadership Compass for Generative AI Defense 2025. Con sede en Barcelona y oficinas en Londres y Nueva York. Certificada ISO 27001.
Fuentes
- Model Context Protocol, «Architecture», revisión de la especificación 2026-07-28: https://modelcontextprotocol.io/specification/2026-07-28/architecture
- Model Context Protocol, «Tools», revisión de la especificación 2025-11-25: https://modelcontextprotocol.io/specification/2025-11-25/server/tools
- Model Context Protocol, «Streamable HTTP», revisión de la especificación 2026-07-28: https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http
- Model Context Protocol, «Authorization», revisión de la especificación 2026-07-28: https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
- Model Context Protocol, «Security Best Practices», especificación más reciente: https://modelcontextprotocol.io/specification/latest/basic/security_best_practices
- Model Context Protocol, «The MCP Registry» (preview), consultado el 15 de octubre de 2026: https://modelcontextprotocol.io/registry/about
- OWASP, «OWASP MCP Top 10» (beta), consultado el 15 de octubre de 2026: https://owasp.org/www-project-mcp-top-10/
- Cloud Security Alliance, «MCP Tool Poisoning: Adversarial Hijacking of AI Agent Workflows», 2 de julio de 2026: https://labs.cloudsecurityalliance.org/research/csa-research-note-mcp-tool-poisoning-ai-agent-exfiltration-2/
- Claude Code Docs, «Connect Claude Code to tools via MCP», consultado el 15 de octubre de 2026: https://code.claude.com/docs/en/mcp
- Model Context Protocol, «Server Features», revisión de la especificación 2025-03-26: https://modelcontextprotocol.io/specification/2025-03-26/server