一个模型上下文协议（MCP）服务器，可根据端点元数据直接生成全面的API 测试计划（包括正向、负向及边界/异常用例）——由**大语言模型（LLM）**驱动。
这是一个基于 TypeScript 的模型上下文协议（MCP）服务器，专为 QA 工程师设计。它通过以下方式演示 MCP 的核心概念：
提供 AI 驱动的工具，根据 API 端点和请求负载生成详尽的测试用例计划
通过提示词驱动集成 LLM，确保测试质量与覆盖率
采用可扩展架构，便于未来集成自动化工具
🔌 符合 MCP 规范的服务器（stdio 传输）。
📝 工具：generate_excel
输入：端点、HTTP 方法、请求负载、额外上下文。
输入选项：
直接指定端点详情：端点、HTTP 方法、请求负载
使用 extraContext 提供任何额外的测试说明或约束条件
输出：📊 Excel 测试计划，包含以下列：序号、测试名称、前置条件、测试步骤、预期结果。
🧠 基于提示词驱动的测试生成，支持可配置的 LLM（Groq、OpenAI、Anthropic）。
📜 使用 Winston 提供详细的日志记录。
Related MCP server: ai-testcase-generator-mcp
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]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：处理所有 Excel（.xlsx）文件创建和测试计划导出（模块化设计）。
src/logger.ts：使用 Winston 提供跨 MCP 服务器的模块化日志功能。
src/prompts/：包含用于 LLM 驱动测试生成的提示词模板。
assets/：演示 GIF、Excel 示例预览和聊天提示词示例。
以下是 MCP 生成测试用例并导出为 Excel 的演示：
以下是所生成测试用例的快速预览：
安装依赖：
npm install构建服务器：
npm run build开发模式（自动重建）：
npm run watch请按照以下步骤在本地设置 AI 测试用例设计器 MCP 服务器：
克隆仓库
git clone
cd ai-testcase-designer-mcp安装依赖
npm install构建服务器
npm run build在 MCP 客户端中配置服务器
添加以下服务器配置：
在 macOS 上：~/Library/Application Support/Claude/claude_desktop_config.json
在 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"
}
}
}快速开始：
从 VS Code 市场 安装 Cline。
打开 Cline 侧边栏（从 VS Code 活动栏）。
转到“MCP 服务器”部分，点击“添加新的 MCP 服务器”。
填写服务器详细信息：
{
"mcpServers": {
"ai-testcase-designer-mcp": {
"disabled": false,
"timeout": 60,
"command": "node",
"args": [
"c:/Auto_WS/ai-testcase-designer-mcp/build/index.js"
],
"transportType": "stdio"
}
}
}测试连接并保存。
有关可视化分步指南，请参阅下文：
有关详细的 Cline 指南，请参阅官方文档：
cline.bot/getting-started/installing-cline#vs-code-marketplace%3A-step-by-step-setup
在 ~/.hermes/config.yaml 的 mcp_servers 下添加以下服务器配置：
mcp_servers:
ai-testcase-designer-mcp:
command: "node"
args: ["/absolute/path/to/ai-testcase-designer-mcp/build/index.js"]要使用 AI 测试用例设计器 MCP 服务器：
从此处免费获取你的 Groq API 密钥：https://console.groq.com/keys
准备一个工作目录（WORK_DIR），用于保存生成的 Excel 测试计划和服务器日志。
按如下方式更新你的 config.json 文件：
{
"MODEL_API_KEY": "gsk_7Ma3Fabcd <your-api-key-here>",
"WORK_DIR": "C:/Auto_WS/ai-testcase-designer-mcp"
}🖥️ 打开 Claude Desktop（或任何兼容 MCP 的客户端）。
📂 下载示例聊天消息：sample_chat_message.txt 并复制其内容。
✉️ 将内容粘贴到聊天框中并发送消息：AI 将生成详细的测试用例并导出为 Excel 格式。
💾 生成的 Excel 文件和服务器日志将保存在你的 WORK_DIR 文件夹中。
{
"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."
}
}序号 | 测试名称 | 前置条件 | 测试步骤 | 预期结果 |
1 | 有效用户创建 | 数据库为空 | 发送包含有效负载的 POST 请求 | 用户创建成功 |
2 | 缺少邮箱 | 数据库为空 | 发送仅包含姓名的 POST 请求 | 返回 400 验证错误 |
3 | 无效邮箱 | 数据库为空 | 发送包含无效邮箱格式的 POST 请求 | 返回 422 错误消息 |
文件将写入：./workdir/generated/
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)npm run inspectorInspector 将提供一个 URL，用于在浏览器中访问调试工具。
本项目采用 MIT 许可证。
有关详细信息，请参阅 LICENSE 文件。
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 |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0generate_tests_excelScored 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.
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.
