Herramienta gratuita

Comprobación de conformidad MCP 2025-06-18

Mira qué revisión del protocolo negocia en realidad tu servidor y si un cliente que espera 2025-06-18 funcionará con él.

Funciona con endpoints Streamable HTTP y SSE, por ejemplo https://mcp.example.com/mcp
Este servidor requiere autenticación
Se usa solo en esta petición y nunca se almacena.

Funcionar no es lo mismo que poder venderse

Cuando el transporte está bien, queda el problema de que nadie ve qué hace tu servidor. MCP Showcase convierte la misma URL en un playground en vivo con documentación para cada herramienta.

Cómo funciona

link
Pega la URL de tu servidor

Cualquier endpoint MCP desplegado.

play_circle
Negociamos un handshake real

El intercambio initialize informa de la revisión en la que se queda tu servidor, que no siempre es aquella contra la que desarrollaste.

checklist
Compara con 2025-06-18

Junto con el transporte, las capacidades y la lista completa de herramientas.

¿Qué revisión habla en realidad tu servidor?

Las revisiones de MCP van fechadas en lugar de numeradas, y cliente y servidor negocian una común durante el handshake initialize. Eso significa que la revisión que importa no es la de tu archivo de dependencias: es aquella en la que coinciden ambos extremos en tiempo de ejecución, que es la que informa esta comprobación.

Los servidores construidos con un SDK más nuevo que aquel con el que se probaron, o fijados a uno antiguo por una dependencia transitiva, negocian con frecuencia algo distinto de lo que su autor espera.

Qué se rompe de verdad entre revisiones

Rara vez el núcleo: herramientas, resources y prompts han sido estables todo el tiempo. Las diferencias que duelen están en la negociación de capacidades, la autorización y, sobre todo, los transportes. El paso a Streamable HTTP acompañó a las revisiones más nuevas, y un desajuste de transporte causa muchas más caídas reales que un desajuste de revisión. Si un cliente no ve tu servidor, comprueba el transporte antes que la revisión.

A cuál apuntar

A la que admite tu SDK, mantenida razonablemente al día. Perseguir revisiones por delante de tu SDK no aporta nada. Quedarse varias por detrás es la forma en que un servidor deja poco a poco de funcionar con los clientes nuevos; y como la negociación se degrada en silencio en lugar de fallar con estrépito, suele notarse como «algunos dicen que no funciona» y no como una caída.

Herramientas relacionadas

El transporte no es la parte difícil

Cuando un cliente ya puede alcanzar tu servidor, queda el problema de que nadie puede saber qué hace. Una lista de herramientas no es una demostración, y un cliente potencial no instalará un cliente para averiguarlo. MCP Showcase apunta a la misma URL y produce un playground en vivo con documentación generada para cada herramienta, de modo que evaluar tu servidor cueste un clic.

Preguntas frecuentes

Una de las revisiones fechadas del Model Context Protocol. Cliente y servidor negocian una revisión común durante initialize, así que lo que importa no es contra cuál desarrollaste, sino en cuál coinciden de verdad ambos extremos.

Ejecuta la comprobación de arriba: la versión negociada aparece en el resultado. Viene de la respuesta initialize de tu servidor, así que es lo que vería un cliente real y no lo que afirma tu archivo de dependencias.

Por sí solo casi nunca; la negociación existe justo para eso. Los problemas vienen de funciones que solo existen en una revisión, y de los transportes: un cliente que espera Streamable HTTP frente a un servidor que solo habla el antiguo SSE falla sea cual sea la revisión acordada.

Apunta a lo que admite tu SDK y mantenlo al día. Perseguir revisiones por delante de tu SDK no aporta nada, pero quedarse varias por detrás significa que los clientes nuevos dejan de funcionar contigo poco a poco, de una forma difícil de diagnosticar.

Que el handshake se complete siquiera, qué transporte respondió y que la lista de herramientas sea la que esperas. El MCP Server Tester cubre todo eso como lista de aprobado/fallo.

Más herramientas MCP gratuitas