Elegir el transporte deliberadamente
Un servidor stdio local y un servicio remoto HTTP tienen necesidades de despliegue diferentes. Utilice un transporte remoto compatible, TLS y una ruta autenticada. Compruebe las versiones del cliente y del servidor en lugar de suponer que todas las implementaciones admiten las mismas capacidades.
Trata cada herramienta como un API
Valida los argumentos, aplica la autorización específica de cada usuario y limita los recursos. No expongas la ejecución arbitraria de shell como herramienta de conveniencia. Restringe los destinos salientes cuando una herramienta obtenga URL y mantén los secretos fuera de las descripciones y las respuestas.
Mantén la recopilación de identidad proporcionada
Un proveedor sin KYC puede minimizar los datos de registro del proveedor, pero el servicio MCP puede seguir necesitando sus propios usuarios, seguridad de sesión y controles de abuso. Explica qué registra y evita conservar las entradas de herramientas sin un propósito definido.
Despliegue para una claridad operativa
Ejecuta bajo un usuario dedicado, usa comprobaciones de estado, limita los tiempos de solicitud y mantén el almacenamiento en búfer y los tiempos de espera del proxy inverso compatibles con el protocolo. Prueba la autenticación, la revocación, las desconexiones y los reintentos antes de conceder privilegios de escritura.
Alinea la autenticación con el protocolo compatible
Para un despliegue de MCP basado en HTTP, revisa los requisitos de autorización actuales del protocolo y la versión compatible del cliente. El acceso a recursos basado en OAuth implica la audiencia del token, el descubrimiento y el alcance, no simplemente una contraseña en la página de inicio. Usa HTTPS, valida los tokens para el recurso previsto y mantén las credenciales de portador fuera de las cadenas de consulta. Un servidor stdio utiliza un límite de credenciales local diferente.
- Probar una solicitud no autenticada
- Prueba una solicitud autenticada fuera de su alcance
- Revoca una credencial y verifica que deja de funcionar
Documentación oficial: Especificación de autorización de MCP
Publica un primer conjunto de herramientas limitado
Empieza con herramientas de solo lectura que devuelvan una cantidad de datos acotada. Añade escrituras de archivos, operaciones de ciclo de vida del servidor o mensajes externos solo cuando se comprendan sus permisos y su comportamiento ante duplicados. Trata las páginas web y los documentos devueltos como entrada no confiable; no deben ampliar silenciosamente la autoridad del servidor de herramientas.
Fija el comportamiento del protocolo antes de escribir reglas de proxy
Registra tanto la versión de SDK del servidor como la revisión de MCP que usará el cliente. En la revisión 2026-07-28 Streamable HTTP, las solicitudes usan un endpoint POST; los ejemplos más antiguos que dependen de sesiones de protocolo o de un flujo GET independiente corresponden a otra revisión. No elimines un requisito de compatibilidad aparente hasta que sepas qué cliente admites. Un proxy inverso debe preservar las cabeceras requeridas, el estado HTTP y el comportamiento de streaming de respuestas para esa versión.
- Comience con una herramienta de solo lectura en un listener de loopback y, después, coloque delante el límite previsto de HTTPS/autenticación.
- Pruebe un resultado normal, un resultado en streaming, un tiempo de espera agotado y un cliente desconectado a través del proxy público.
- Valide los valores de Origin permitidos según lo exija el transporte; una comprobación de Origin no sustituye la autenticación del llamador.
- Si los eventos llegan solo al final, inspecciona el almacenamiento en búfer del proxy y el comportamiento de los tiempos de espera antes de cambiar el código de la herramienta.
Documentación oficial: MCP 2026-07-28: HTTP reproducible en streaming
Pruebe los fallos de autorización con la misma deliberación que los éxitos
Para el acceso a HTTP protegido con OAuth, el servidor MCP es un recurso protegido. Prueba el descubrimiento de metadatos, el emisor esperado y la audiencia del token, y los ámbitos necesarios para una operación concreta. Mantén el token de autorización fuera de las cadenas de consulta de URL y nunca lo reenvíes sin cambios a un servicio downstream no relacionado. Un fallo de autenticación de cara al cliente debe conservar el desafío HTTP adecuado para que el cliente pueda recuperarse mediante su flujo compatible.
- Sin token o con un token caducado: el endpoint protegido rechaza el acceso en lugar de devolver datos privados de la herramienta.
- Token válido con permisos insuficientes: el recurso solicitado sigue siendo inaccesible.
- Token para otra audiencia: recházalo aunque su firma sea válida por lo demás.
- URL externo o ruta de archivo inesperados: valida contra la autoridad de la herramienta antes de obtener o escribir.
- Registros y trazas de errores: conserva un identificador de operación y el resultado, eliminando tokens y entradas privadas de herramientas.
Documentación oficial: MCP 2026-07-28: autorización HTTP · MCP: buenas prácticas de seguridad