Herramienta gratuita

Linter de esquemas MCP

Cuando un agente llama a la herramienta equivocada, la causa suelen ser las descripciones. Pega la URL de tu servidor MCP y recibe una revisión de cada descripción y esquema, con reescrituras sugeridas.

Funciona con endpoints de HTTP en streaming 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.

Mejores descripciones para el modelo. ¿Y para las personas?

Una descripción ajustada para la selección de herramientas no es documentación que un cliente pueda leer. MCP Showcase genera ambas cosas desde el mismo servidor: esquemas ligeros para el agente y un playground en vivo con documentación real para los demás.

Cómo funciona

link
Pega la URL

Leemos las definiciones de herramientas que anuncia tu servidor: exactamente lo que recibe un agente al conectarse.

play_circle
Se revisa cada descripción

Descripciones ausentes o demasiado escuetas, parámetros sin documentar, esquemas sin propiedades declaradas y textos largos que cuestan contexto real en cada turno.

checklist
Recibe hallazgos y reescrituras

Una puntuación, cada problema con la herramienta afectada y, donde cambiaría de verdad el comportamiento del modelo, una descripción alternativa sugerida.

Por qué un agente llama a la herramienta equivocada

La descripción de una herramienta MCP no es documentación para personas. Se envía al modelo en cada petición y es lo único que el modelo usa para decidir si llama a esa herramienta. Cuando un agente elige delete_branch en lugar de list_branches, casi nunca es un fallo del agente: son dos descripciones que el modelo no pudo distinguir.

Pega arriba la URL de tu servidor MCP y este linter leerá cada definición de herramienta que anuncia tu servidor, exactamente como la recibe un agente, e informará de lo que hace que la selección sea poco fiable.

Qué comprueba

  • Descripciones ausentes o escuetas: una herramienta descrita en tres palabras no le da al modelo nada sobre lo que decidir.
  • Descripciones que repiten el nombre: el modelo ya tiene el nombre. «Listar incidencias: lista incidencias» no añade ninguna señal.
  • Parámetros sin documentar: las descripciones de parámetros son la forma en que el modelo sabe qué poner en cada campo. Sin ellas lo deduce del nombre y se equivoca.
  • Esquemas sin propiedades declaradas: una herramienta que no declara entradas aceptará lo que el modelo invente.
  • Sin array required: entonces todos los parámetros parecen opcionales, el modelo omite uno necesario y recibe un error.
  • Descripciones largas que cuestan contexto real: se envían en cada turno, así que la verbosidad es un cargo recurrente, no puntual.

Más largo no es mejor

Conviene decirlo claramente porque el instinto suele fallar aquí: el linter señala las descripciones demasiado largas igual que las demasiado cortas. Las definiciones de herramientas se reenvían en cada petición, así que un párrafo de más se paga en cada turno de cada conversación, para siempre, sin mejorar la precisión de la elección. Busca una o dos frases concretas: qué hace la herramienta y cuándo elegirla frente a la de al lado. Puedes ver exactamente cuánto cuesta tu lista actual con la calculadora de tokens MCP.

Qué incluye el informe

Una puntuación de calidad, cada hallazgo con la herramienta afectada y, donde una reescritura cambiaría de verdad el comportamiento del modelo, una descripción alternativa sugerida. Las comprobaciones en sí no usan ningún modelo y se ejecutan siempre. Las reescrituras sugeridas sí, y tienen un presupuesto mensual para que la herramienta siga siendo gratuita; si se agota, el informe lo dice con claridad y todos los hallazgos anteriores siguen en pie.

Herramientas y guías relacionadas

Una descripción no puede servir a dos lectores

Ajustar una descripción para la selección de herramientas la vuelve breve, concreta y orientada a la máquina, e inútil para un cliente que intenta entender qué hace tu servidor. Esa tensión es real y no se resuelve escribiendo mejor. MCP Showcase la zanja generando ambas cosas desde el mismo servidor: tus esquemas ligeros siguen yendo al modelo, mientras que los clientes potenciales obtienen un playground en vivo con documentación legible por herramienta que pueden probar de verdad en el navegador.

Preguntas frecuentes

Casi siempre por las descripciones. Un modelo elige una herramienta leyendo su descripción y nada más. Si dos herramientas se describen de forma parecida, o una solo dice cómo se llama, el modelo está adivinando. Ese fallo parece un bug de tu agente pero vive en el esquema de tu servidor.

Una o dos frases llanas que digan qué hace la herramienta y cuándo elegirla frente a otra parecida. Concreta, sin marketing y sin repetir el nombre de la herramienta. Cada parámetro lleva su propia descripción, y se declara el array required para que el modelo sepa qué no puede omitir.

No. Solo lee lo que tu servidor anuncia: nombres, descripciones y esquemas de entrada. No puede decirte si una herramienta funciona, solo si un modelo que lea tus descripciones elegiría la correcta.

Las comprobaciones se ejecutan siempre; no usan ningún modelo. Las reescrituras sí, y hay un presupuesto mensual para eso de modo que la herramienta siga siendo gratuita. Si se agota, el informe lo dice con claridad, y todos los hallazgos anteriores siguen siendo válidos.

No: el linter señala las descripciones demasiado largas igual que las demasiado cortas. Las definiciones de herramientas se envían en cada petición, así que un texto verboso se paga en cada turno sin mejorar la precisión de la elección. Busca claridad y concreción, no exhaustividad.

Más herramientas MCP gratuitas