Lista de comprobación de pruebas de integración MCP para herramientas de n8n
Verifica el descubrimiento, los argumentos, los resultados y los fallos de una herramienta MCP de n8n antes de adoptarla y después de cada cambio.
Comprobado con las fuentes citadas el .
Define tu caso de referencia para las pruebas de integración MCP
Las pruebas de integración MCP deben comprobar una herramienta existente de MCP Server Trigger de n8n tanto en una herramienta de inspección como en el cliente previsto. Esta lista propone criterios editoriales de aceptación: conectar, inspeccionar el contrato, comparar las llamadas con los resultados esperados, probar los fallos y repetir las pruebas en el cliente. Son comprobaciones sugeridas para equipos, no normas obligatorias de MCP ni pruebas de que un flujo de trabajo concreto las haya superado.
Empieza con un caso de referencia representativo de solo lectura. La guía de la CLI de Inspector del proyecto MCP recomienda elegir una herramienta que sea de solo lectura, idempotente y que resulte poco costoso llamar repetidamente. Registra lo siguiente antes de probar; esta comprobación estará completa cuando otro desarrollador pueda reproducir el mismo caso.
Creemos que un caso de referencia pequeño con un resultado esperado explícito es un mejor punto de partida que una conversación impresionante con un agente.
Sources: inspector/docs/cli-smoke-testing.md at main · modelcontextprotocol/inspector · GitHub
Comprueba la conectividad y el contrato descubierto
n8n documenta SSE y HTTP transmisible para las conexiones de MCP Server Trigger; stdio directo no es compatible. Distingue entre las URL de prueba y de producción, y registra el endpoint de producción cuando se publica el flujo de trabajo. Da por completada la comprobación de conectividad cuando Inspector se conecte al entorno previsto. Si falla, comprueba el transporte y la publicación antes de investigar la lógica de la herramienta.
La documentación de Inspector del proyecto MCP, archivada en abril de 2025, describe cómo descubrir herramientas, inspeccionar descripciones y esquemas, llamar a herramientas con entradas personalizadas e inspeccionar los resultados. Usa esa orientación histórica como procedimiento de inspección, en lugar de como instrucciones de la interfaz actual. Las siguientes comprobaciones de descubrimiento definen nuestro criterio de finalización sugerido.
Esta lista presupone un endpoint ya configurado. La instalación, la configuración inicial de la autenticación, la configuración del proxy, el despliegue en modo cola y MCP a nivel de instancia quedan fuera de su alcance.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger.md at main · n8n-io/n8n-docs · GitHub, docs/docs/tools/inspector.mdx at main · modelcontextprotocol/docs · GitHub
Verifica los argumentos, los resultados y los fallos controlados
Para las pruebas de integración de servidores MCP, escribe cada respuesta esperada antes de realizar la llamada. La documentación del SDK de TypeScript de MCP v2 indica que los argumentos deben cumplir inputSchema; esto no demuestra que todas las herramientas de n8n apliquen todas las restricciones. Prueba el endpoint real. La tabla siguiente es un conjunto de casos sugerido para las pruebas de integración MCP, no un instrumento de prueba validado.
| Caso | Entrada que preparar | Expectativa que registrar |
|---|---|---|
| Entrada válida | Valores conocidos del caso de referencia | Contenido y campos esperados |
| Argumento ausente | Omitir un campo obligatorio | Rechazo esperado |
| Tipo incorrecto | Cambiar el tipo de un valor | Rechazo esperado |
| Valor límite | Un límite documentado del contrato | Aceptación o rechazo esperados |
| Fallo controlado | Un fallo simulado de una dependencia que sea seguro provocar | Respuesta de fallo esperada |
En las llamadas válidas, compara el contenido devuelto y cualquier campo estructurado con el caso de referencia, en lugar de aceptar cualquier respuesta que no esté vacía. Para los casos negativos, la guía de la CLI de Inspector recomienda comprobar explícitamente el rechazo esperado. Un servidor inaccesible o un cierre inesperado no cuentan como un rechazo correcto.
El ejemplo de servidor meteorológico del SDK de TypeScript de MCP v2 devuelve isError establecido en true ante excepciones del manejador y argumentos rechazados. Es el comportamiento de un ejemplo, no una garantía universal de n8n: registra el indicador de error, el mensaje y la clasificación del fallo reales. Marca cada caso como completado solo cuando la respuesta observada coincida con su expectativa escrita.
Sources: inspector/docs/cli-smoke-testing.md at main · modelcontextprotocol/inspector · GitHub, Build your first client | MCP TypeScript SDK
Repite casos representativos en el cliente previsto
En un relato publicado en la comunidad en abril de 2026, Jeff Hooton describe cómo las comprobaciones de Inspector se superaban mientras un agente seguía comportándose incorrectamente con sus servidores MCP en Go. Este testimonio personal no es una evaluación de n8n y no demuestra la frecuencia del problema ni un efecto causal. Respalda la conveniencia de comprobar el cliente previsto por separado.
En nuestra opinión, una llamada directa a una herramienta y un agente que elige esa herramienta responden a preguntas de aceptación diferentes. Mantén ambas comprobaciones en la revisión.
Utiliza las siguientes comprobaciones sugeridas para el cliente. Estarán completas cuando la selección, los argumentos y el tratamiento de los resultados observados en el cliente coincidan con las expectativas registradas para la tarea.
Sources: Testing and Debugging MCP Servers: Inspector, Integration Tests, and CI Patterns · Jeff Hooton
Guarda una referencia para las pruebas de regresión antes de aprobar
Haz que las pruebas de integración MCP sean repetibles guardando las entradas, las respuestas esperadas, los resultados observados y las clasificaciones de los fallos junto con los detalles del entorno del caso de referencia. La guía de la CLI de Inspector del proyecto MCP presenta las pruebas de humo como comprobaciones repetibles para commits y despliegues, y las distingue de una batería de pruebas de conformidad.
Como regla editorial de aprobación, vuelve a ejecutar los casos guardados después de modificar los flujos de trabajo y antes de adoptarlos. Compara las diferencias, investiga los cambios sin explicación y actualiza las expectativas solo cuando el cambio de comportamiento sea intencional. Esta comprobación estará completa cuando quien revise pueda vincular cada caso aceptado con su entrada, su expectativa y su respuesta observada.
Sources: inspector/docs/cli-smoke-testing.md at main · modelcontextprotocol/inspector · GitHub
