ai-testcase-designer-mcp
🤖 Generador de Casos de Prueba con IA - Servidor MCP
Un servidor de Protocolo de Contexto de Modelo (MCP) que genera planes de prueba de API completos (casos positivos, negativos y de límites/edge) directamente a partir de metadatos de endpoints, impulsado por LLMs.
Este es un servidor de Protocolo de Contexto de Modelo (MCP) basado en TypeScript para ingenieros de QA. Demuestra conceptos centrales del Protocolo de Contexto de Modelo al proporcionar:
Herramienta impulsada por IA para generar planes de casos de prueba exhaustivos a partir de endpoints y payloads de API
Integración de LLM impulsada por prompts para calidad y cobertura
Estructura extensible para futuras herramientas de automatización
✨ Características
🔌 Servidor compatible con MCP (transporte
stdio).📝 Herramienta:
generate_tests_excelEntrada: endpoint, método HTTP, payload, contexto adicional.
Opciones de entrada:
Detalles directos del endpoint: endpoint, método HTTP, payload
Usa extraContext para proporcionar cualquier nota o restricción de prueba adicional
Salida: 📊 Plan de pruebas en Excel con columnas: N.º, Nombre de la prueba, Precondición, Pasos, Resultado esperado.
🧠 Generación de pruebas impulsada por prompts con LLM configurable (Groq, OpenAI, Anthropic).
📜 Registro detallado con Winston.
Related MCP server: ai-testcase-generator-mcp
🏗️ Arquitectura
flowchart TD
A[Claude / MCP Client] -->|Run Tool| B[MCP Server]
B -->|Prompt| C[LLM API]
C -->|Test Cases JSON| B
B -->|Excel Export| D[(Test Plan .xlsx)]
B -->|Logs| E[Server Log File]📂 Estructura del Proyecto
ai-testcase-designer-mcp/
├── build/ # Compiled JavaScript output
├── assets/ # Demo gifs, images, and sample files
│ ├── demo.gif
│ ├── excel_preview.png
│ └── sample_chat_message.txt
├── configs/
│ └── config.json # Server/tool config
├── src/
│ ├── index.ts # Main server entry point (MCP interface & routing)
│ ├── excel.ts # Excel file creation & writing logic (modular)
│ ├── logger.ts # Winston logger configuration & log writing (modular)
│ └── prompts/
│ └── testcase_prompt.txt # Prompt template for LLM-based test generation
├── package.json
├── tsconfig.json
├── README.md
└── .gitignoresrc/excel.ts: Maneja toda la creación de archivos Excel (.xlsx) y la exportación del plan de pruebas (modularizado).
src/logger.ts: Proporciona funcionalidad de registro modular en todo el servidor MCP usando Winston.
src/prompts/: Contiene plantillas de prompts para la generación de pruebas impulsada por LLM.
assets/: GIFs de demostración, vista previa de muestra de Excel y ejemplos de prompts de chat.
🎥 Demostración
Aquí está el MCP generando casos de prueba y exportándolos a Excel:

🔍 Vista Previa de Excel
A continuación, una vista previa rápida de los casos de prueba generados:

Desarrollo
Instala las dependencias:
npm installCompila el servidor:
npm run buildPara desarrollo con recompilación automática:
npm run watch⚙️ Instalación
Sigue estos pasos para configurar el servidor MCP del Diseñador de Casos de Prueba con IA localmente:
Clona el repositorio
git clone cd ai-testcase-designer-mcpInstala las dependencias
npm installCompila el servidor
npm run buildConfigura el servidor en tu cliente MCP
a. Claude Desktop o cualquier cliente compatible con MCP
Añade la siguiente configuración del servidor:
En MacOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonEn Windows:
%APPDATA%/Claude/claude_desktop_config.json
{ "mcpServers": { "ai-testcase-designer-mcp": { "disabled": false, "timeout": 60, "command": "node", "args": [ "c:/Auto_WS/ai-testcase-designer-mcp/build/index.js" ], "transportType": "stdio" } } }b. Cline (Extensión de VS Code)
Inicio rápido:
Abre la barra lateral de Cline (desde la barra de actividades de VS Code).
Ve a la sección "Servidores MCP" y haz clic en "Añadir nuevo servidor MCP".
Completa los detalles del servidor:
{ "mcpServers": { "ai-testcase-designer-mcp": { "disabled": false, "timeout": 60, "command": "node", "args": [ "c:/Auto_WS/ai-testcase-designer-mcp/build/index.js" ], "transportType": "stdio" } } }Prueba la conexión y guarda.
Para una guía visual paso a paso, consulta a continuación:


Para obtener una guía detallada de Cline, consulta la documentación oficial:
cline.bot/getting-started/installing-cline#vs-code-marketplace%3A-step-by-step-setup
c. Agente Hermes
Añade la siguiente configuración del servidor a
~/.hermes/config.yamlbajomcp_servers:
mcp_servers:
ai-testcase-designer-mcp:
command: "node"
args: ["/absolute/path/to/ai-testcase-designer-mcp/build/index.js"]🔑 Configuración de la Clave API y del Directorio de Trabajo
Para usar el MCP del Diseñador de Casos de Prueba con IA.
Obtén tu clave API de Groq aquí de forma gratuita: https://console.groq.com/keys
Un directorio de trabajo (WORK_DIR) donde se guardarán los planes de prueba en Excel generados y los registros del servidor.
Actualiza tu archivo config.json de la siguiente manera:
{
"MODEL_API_KEY": "gsk_7Ma3Fabcd <your-api-key-here>",
"WORK_DIR": "C:/Auto_WS/ai-testcase-designer-mcp"
}Cómo Usar
🖥️ Abre Claude Desktop (o cualquier cliente compatible con MCP).
📂 Descarga el mensaje de chat de muestra: sample_chat_message.txt y copia su contenido.
✉️ Pega el contenido en el chat y envía el mensaje: la IA generará casos de prueba detallados en formato Excel.
💾 Los archivos de Excel generados y los registros del servidor se guardan en tu carpeta
WORK_DIR.
▶️ Ejemplo de Solicitud
{
"name": "generate_tests_excel",
"arguments": {
"endpoint": "https://api.example.com/v1/users",
"method": "POST",
"payload": {
"name": "John Doe",
"email": "john@example.com"
},
"extraContext": "Focus on invalid email and empty payload scenarios."
}
}📊 Ejemplo de Salida en Excel
N.º | Nombre de la prueba | Precondición | Pasos | Resultado esperado |
1 | Creación de usuario válida | La BD está vacía | Enviar POST con payload válido | Usuario creado exitosamente |
2 | Correo faltante | La BD está vacía | Enviar POST solo con el nombre | Error de validación 400 |
3 | Correo inválido | La BD está vacía | Enviar POST con formato de correo inválido | Mensaje de error 422 |
📂 Archivos de Salida
Los archivos se escriben en: ./workdir/generated/
Ejemplo de Registro de Salida
2025-09-13T10:22:11 [info]: [Step1] Incoming request: endpoint=/v1/users, method=POST
2025-09-13T10:22:11 [info]: [Step2] Building LLM prompt...
2025-09-13T10:22:13 [info]: [Step5] Converting LLM JSON to Excel rows (15 test cases)Depuración
npm run inspectorEl Inspector proporcionará una URL para acceder a las herramientas de depuración en tu navegador.
Licencia
Este proyecto está licenciado bajo la Licencia MIT.
Consulta el archivo LICENCIA para más detalles.
Available Tools
1 toolgenerate_tests_excelB
Generate a comprehensive API test plan with positive, negative, and boundary value analysis test cases and export to Excel (.xlsx). You (Cursor IDE model) can generate test cases directly into the testCases array argument, or pass endpoint, method, and payload to generate via external LLM if configured.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | HTTP method (GET, POST, PUT, DELETE, etc.) | |
| payload | No | Sample payload for the request (if applicable) | |
| endpoint | Yes | API endpoint to test (e.g., https://api.example.com/v1/users) | |
| testCases | No | Direct list of test cases generated by Cursor IDE's AI model. Bypasses external LLM API if provided. | |
| extraContext | No | Any additional instructions/context for the test plan |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the core behavior: generating test cases and exporting to Excel, and it mentions the bypass mechanism for external LLM. However, it does not disclose potential side effects (e.g., file creation, network calls to external LLM, or failure modes if no external LLM is configured). The description is partially transparent but leaves out important behavioral details such as whether the tool makes external API calls when testCases are not provided, and what happens if the external LLM is not configured.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, fitting in two sentences. It front-loads the core purpose (generating test plan and exporting to Excel) and then explains the two modes of use. The structure is effective, but the second sentence contains a parenthetical that adds some complexity, though it's still efficient. No wasted words, but it could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of this tool (5 parameters, nested objects, two modes of operation, no output schema), the description provides a decent overview but misses several critical details. It does not explain what happens when both testCases and endpoint/method are provided (which takes precedence), it doesn't mention the format of the Excel file or where it is saved, and it doesn't clarify what is required for the external LLM to be used. The absence of an output schema means the description should clarify what the tool returns, but it only says 'export to Excel' without specifying the output format. This is a significant gap for a tool that likely produces a file artifact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, meaning that every parameter has a description in the schema itself. The description adds extra context about the testCases parameter, explaining that it bypasses the external LLM, and explains the alternative use of endpoint/method/payload. This adds value beyond the schema but is not exhaustive for all parameters. With full schema coverage, the baseline is 3, and the description slightly enhances clarity for the testCases parameter, but doesn't add semantic depth to method or endpoint beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating a comprehensive API test plan with positive, negative, and boundary value analysis, and exporting to Excel. It distinguishes itself by mentioning two modes of operation (direct test case generation or via external LLM), which is a specific feature. However, it does not compare to any sibling tools since none are provided, so it lacks explicit differentiation in that regard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when generating test plans for APIs) and provides context on how to use it (either provide testCases directly or provide endpoint/method/payload for external generation). However, it does not specify when not to use it or mention alternatives, leaving some ambiguity about the exact selection criteria. The guidance is present but not explicit about exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
generate_tests_excel
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of confusion between tools. The single tool's purpose is clearly defined.
With only one tool, naming consistency is trivially satisfied. The name 'generate_tests_excel' follows a clear verb_noun pattern and accurately describes the action.
Having just one tool feels thin for a server named 'ai-testcase-designer-mcp', which suggests a broader scope. The single tool does combine generation and export, but it may leave agents wanting for more modular capabilities.
The tool covers the core workflow of generating and exporting test cases to Excel, with support for both manual input and external LLM generation. However, it lacks separate operations like previewing, editing, or managing test case files, which are minor gaps given the narrow purpose.
Maintenance
Related MCP Connectors
Generates unit tests for Python code with coverage before/after reports and concrete edge cases.
End-to-end API testing — generate and run tests from OpenAPI, curl, Postman, or real user traffic.
3rd Generation Testing (3TG) — generate deterministic test suites from Markdown spec tables via MCP.
AI-callable tools for API mocking, testing, monitoring, security, and automation.
Related MCP Servers
- AlicenseAqualityFmaintenanceMCP server for API test case generation from Swagger/OpenAPI specs. Parses Swagger 2.0 and OpenAPI 3.x, generates test cases across 8 categories (positive, negative, boundary, auth, security, idempotency, pagination, business logic), and exports to Postman, TestRail, Allure, k6, pytest, Gherkin, and CSV. Supports internal corporate APIs with auth headers. Auto-saves export files to your working di1010 npm2MIT
- AlicenseAqualityCmaintenanceGenerates comprehensive API test plans (positive, negative, and boundary/edge cases) from endpoint metadata using LLMs, and exports them as Excel files.116MIT
- AlicenseBqualityCmaintenanceEnables QA/SDET engineers to test APIs by ingesting Swagger/OpenAPI specs and Postman collections, generating and executing tests in multiple languages and frameworks with real-time progress tracking.1151 npm41 PyPI6MIT
- AlicenseAqualityDmaintenanceGenerates structured, comprehensive test cases from user stories, API specs, or raw text, with automatic Excel export and Playwright automation code generation.61MIT