为您的应用提供 AI 驱动的自主测试——将 Claude、Cursor 或任何兼容 MCP 的 AI 代理连接到 Wopee.io，即可在几秒钟内生成测试用例、用户故事并运行自主测试。
npx wopee-mcpNode.js（建议 v18 或更高版本）
支持 MCP（模型上下文协议）的 IDE，例如 Cursor 或 VSCode
将此服务器添加到您的 MCP 配置中。
{
"mcpServers": {
"wopee": {
"command": "npx wopee-mcp",
"env": {
"WOPEE_PROJECT_UUID": "your-project-uuid-here",
"WOPEE_API_KEY": "your-api-key-here"
}
}
}
}WOPEE_PROJECT_UUID - 您的 Wopee 项目 UUID。这用于标识您正在处理的项目。
WOPEE_API_KEY - 您的 Wopee API 密钥。您可以在 cmd.wopee.io 的项目设置中创建一个。
WOPEE_API_URL - Wopee API 端点 URL。仅在测试/开发目的时指定。
如果您处于企业代理/VPN 环境中并遇到连接超时，可以使用标准环境变量配置代理设置：
{
"mcpServers": {
"wopee": {
"command": "npx wopee-mcp",
"env": {
"WOPEE_PROJECT_UUID": "your-project-uuid-here",
"WOPEE_API_KEY": "your-api-key-here",
"HTTPS_PROXY": "http://your-proxy-server:8080"
}
}
}
}HTTPS_PROXY 或 https_proxy - HTTPS 连接的代理服务器 URL（推荐）
HTTP_PROXY 或 http_proxy - 后备代理服务器 URL
如果您不确定代理设置，请检查 VS Code 设置 (settings.json) 中的 http.proxy 值，或咨询您的 IT 部门。常见的企业代理格式：
http://proxy.company.com:8080
http://10.x.x.x:8080
http://username:password@proxy.company.com:8080（如果需要身份验证）
MCP 正常工作不需要此步骤。 如果您看到 HTTPS 或证书相关的错误，说明您的环境中存在 TLS 或证书信任问题。
如果服务器报错，例如 UNABLE_TO_VERIFY_LEAF_SIGNATURE 或 certificate has expired，可能是由于：
自签名证书（例如当 WOPEE_API_URL 指向内部或开发服务器时）
企业代理 / SSL 检查（流量被您的机器不信任的企业 CA 重新加密）
Node 的信任存储中缺少 CA 证书
使用有效的 TLS 证书 – 例如 Let’s Encrypt 或内部 CA – 并确保提供了完整的证书链。
安装企业或内部 CA 以便 Node 信任它：
示例：
export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/internal-ca.pem在 MCP 配置 env 中：
"env": {
"WOPEE_PROJECT_UUID": "your-project-uuid-here",
"WOPEE_API_KEY": "your-api-key-here",
"NODE_EXTRA_CA_CERTS": "/path/to/ca.pem"
}仅用于本地调试，您可以禁用 Node 中的 TLS 验证。这绝不应在生产环境中使用，因为它会禁用 HTTPS 安全性并将流量暴露给拦截风险。
export NODE_TLS_REJECT_UNAUTHORIZED=0或者在 MCP 配置 env 中：
"env": {
"WOPEE_PROJECT_UUID": "your-project-uuid-here",
"WOPEE_API_KEY": "your-api-key-here",
"NODE_TLS_REJECT_UNAUTHORIZED": "0"
}请将其视为仅限调试的应急方案，而非正常的设置步骤。
注意： 一些用户报告也设置了 PYTHONHTTPSVERIFY=0。此 MCP 服务器不使用 Python；该变量对其无效。它仅适用于您在同一环境中运行基于 Python 的 MCP 主机或其他执行 HTTPS 的工具时——这超出了本服务器的范围。
Related MCP server: Playwright MCP
此 MCP 服务器中的大多数工具都需要 suiteUuid 才能运行。您有两种入门选择：
首先获取您现有的分析套件：
Use the wopee_fetch_analysis_suites tool to retrieve all available suites for your project.这将返回所有分析套件及其 UUID 的列表，您可以将其用于其他工具。
如果您还没有任何套件，有两个选择：
自动分析： 创建并分发完整的分析/爬取套件：
Use the wopee_dispatch_analysis tool to create and dispatch a new analysis/crawling suite.空白套件： 创建一个空套件以进行手动配置：
Use the wopee_create_blank_suite tool to create a blank analysis suite.这两个选项都会返回一个套件 UUID，您可以将其用于后续操作。
wopee_fetch_analysis_suites获取您项目的所有分析套件。这是查看可用套件的良好起点。
返回： 包含 UUID、名称、状态和元数据的分析套件数组
使用示例：
Fetch all existing analysis suites for my projectwopee_dispatch_analysis为您的项目创建并分发新的分析/爬取套件，或重新运行现有套件。使用此工具启动新的分析会话或重新触发之前的分析。
参数：
additionalInstructions (可选) - 指导代理在分析/爬取阶段的额外说明（例如重点区域、忽略事项、登录步骤等）
additionalVariables (可选) - 传递给分析的额外环境变量。对象数组，每个包含：
key - 变量名，必须仅包含大写字母和下划线（例如 MY_VAR, BASE_URL）
value - 变量值（非空字符串）
rerun (可选) - 如果提供，则重新运行现有的分析套件而不是创建新套件。对象包含：
suiteUuid - 要重新运行的现有套件的 UUID
analysisIdentifier - 现有套件的分析标识符
mode - 重新运行模式：FULL（重新运行整个分析，包括爬取和生成）或 CRAWLING（仅重新运行爬取阶段）
返回： 包含创建/重新运行的套件信息的成功消息
使用示例：
Dispatch a new analysis suiteDispatch a new analysis suite and focus on the checkout flowDispatch a new analysis suite with additional variables CARD_FILAMENT=123321123 and AUTH_TOKEN=abc123Rerun the full analysis for suite <suiteUuid> with analysis identifier <analysisIdentifier>Rerun only the crawling phase for suite <suiteUuid> with analysis identifier <analysisIdentifier>wopee_create_blank_suite为您的项目创建一个空白分析套件。当您想手动配置和填充套件而不是自动分析时，请使用此工具。
返回： 包括其 UUID 在内的已创建套件信息
使用示例：
Create a blank analysis suite for my project这些工具为特定套件生成各种工件。所有工具都需要 suiteUuid 和 type 才能生成。
wopee_generate_artifact为选定套件生成特定文件（工件）。
参数：
suiteUuid - 套件的 UUID
type - "APP_CONTEXT" | "GENERAL_USER_STORIES" | "USER_STORIES_WITH_TEST_CASES" | "TEST_CASES" | "TEST_CASE_STEPS" | "REUSABLE_TEST_CASES" | "REUSABLE_TEST_CASE_STEPS"
返回： 生成成功时的输出内容。
使用示例：
Generate app context for my most recent analysis suite这些工具用于检索特定套件生成的工件。所有工具都需要 suiteUuid 和 type。
wopee_fetch_artifact从选定套件中获取查询的文件（工件）。
参数：
suiteUuid - 套件的 UUID
type - "APP_CONTEXT" | "GENERAL_USER_STORIES" | "USER_STORIES" | "PLAYWRIGHT_CODE" | "PROJECT_CONTEXT"
identifier - 获取 Playwright 代码的测试用例标识符，例如 US003:TC004
返回： 获取成功时的文件内容。
使用示例：
Fetch user stories for the latest suite这些工具用于更新或设置特定套件的某些文件（工件）。需要 suiteUuid、type 和 content。
wopee_update_artifact更新/替换特定套件的现有文件（工件）
参数：
suiteUuid - 套件的 UUID
type - "APP_CONTEXT" | "GENERAL_USER_STORIES" | "USER_STORIES" | "PLAYWRIGHT_CODE" | "PROJECT_CONTEXT"
content - app context、general user stories 和 project context 的 Markdown 内容，user stories 的结构化 JSON
identifier - 获取 Playwright 代码的测试用例标识符，例如 US003:TC004
返回： 基于工具调用成功状态的布尔值
使用示例：
Update app context file for the most recent suite with this content: <YourMarkdown>wopee_dispatch_agent分发自主测试代理以执行选定套件的测试用例。
参数：
suiteUuid - 包含测试用例的套件 UUID
analysisIdentifier - 套件的分析标识符
testCases - 要执行的测试用例对象数组，每个包含：
testCaseId - 测试用例 ID
userStoryId - 关联的用户故事 ID
返回： 包含初始执行状态（uuid, executionStatus, agentReportStatus, codeReportStatus 等）的已执行测试用例对象数组
使用示例：
Dispatch agent for my latest suite's user story US001 and test case TC003wopee_fetch_executed_test_cases获取给定分析套件的已执行测试用例及其结果。使用此工具检查已分发代理运行的状态和报告。
参数：
suiteUuid - 要获取结果的分析套件 UUID
analysisIdentifier (可选) - 用于缩小结果范围的分析标识符（例如 A068）
返回： 按用户故事分组的结果数组，每个包含已执行的测试用例及其执行状态、代理报告、代理报告状态、代码报告和代码报告状态
使用示例：
Fetch test results for suite <suiteUuid>Show me the executed test cases for my latest analysis suite从套件开始：
使用 wopee_fetch_analysis_suites 查看现有套件，或
使用 wopee_dispatch_analysis 创建新套件
生成工件：
生成应用上下文：使用 APP_CONTEXT 和特定 suiteUuid 调用 wopee_generate_artifact
生成通用用户故事：使用 GENERAL_USER_STORIES 和特定 suiteUuid 调用 wopee_generate_artifact
生成带测试用例的用户故事：使用 USER_STORIES_WITH_TEST_CASES 和特定 suiteUuid 调用 wopee_generate_artifact
生成可重用测试用例：使用 REUSABLE_TEST_CASES 和特定 suiteUuid 调用 wopee_generate_artifact
生成可重用测试用例步骤：使用 REUSABLE_TEST_CASE_STEPS 和特定 suiteUuid 调用 wopee_generate_artifact
生成测试用例步骤：使用 TEST_CASE_STEPS 和特定 suiteUuid 调用 wopee_generate_artifact
获取生成的内容：
使用获取工具检索生成的 Markdown/JSON 文件
运行测试：
使用 wopee_dispatch_agent 通过自主测试代理执行测试用例
检查结果：
使用 wopee_fetch_executed_test_cases 检查已分发代理运行的状态和报告
或使用 fetch-test-results 提示词获取所有测试结果的格式化摘要
fetch-project-summary获取分析套件及其用户故事/测试用例，然后显示包含两个 Markdown 表格的格式化摘要：套件概览和详细的测试用例分解。
fetch-test-results获取分析套件及其已执行的测试用例结果，然后显示格式化的 Markdown 表格，展示每个测试用例的执行状态、代理报告状态和代码报告状态。同时显示失败的报告详情。
大多数工具需要 suiteUuid。请务必从获取或创建套件开始。
wopee_dispatch_analysis 工具将完成整个处理周期——爬取应用程序并逐一生成所有文件（工件）。
建议使用 cmd.wopee.io 以方便地直观展示生成的数据和代理运行结果。
Create a new empty analysis suite in the current project. Use this as the first step when you want to manually build a test suite — the returned suite UUID is needed by wopee_generate_artifact, wopee_fetch_artifact, wopee_update_artifact, and wopee_dispatch_agent. If you want to auto-analyze a web app instead, use wopee_dispatch_analysis which creates and populates a suite in one step. Takes no input parameters; uses WOPEE_PROJECT_UUID from environment. Not idempotent: each call creates a new suite. Returns the suite object with UUID, name, type, and status. Fails if WOPEE_PROJECT_UUID is not configured.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool is not idempotent (each call creates a new suite), uses the WOPEE_PROJECT_UUID environment variable, returns a suite object with specific fields, and fails if the environment variable is not configured. No annotations are provided, so the description fully covers behavioral aspects.
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?
Four sentences, each packed with essential information. Front-loaded with purpose and immediate usage context. No wasted words; every sentence serves a clear function.
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 simple schema (no parameters, no output schema) and the presence of sibling tools, the description thoroughly covers purpose, usage context, behavioral traits, parameter details, return value, and failure conditions. It is fully self-contained.
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 input schema is empty, and the description adds significant meaning by stating that no input parameters are required, that it uses WOPEE_PROJECT_UUID from environment, and that it returns a suite object with UUID, name, type, and status. This exceeds the baseline expectation for zero-parameter tools.
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 creates a new empty analysis suite, using the verb 'create' and the resource 'analysis suite'. It distinguishes itself from the sibling tool wopee_dispatch_analysis by specifying that this is for manual building while the other auto-populates.
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?
Explicitly states to use this as the first step for manually building a test suite, and provides an alternative: wopee_dispatch_analysis for auto-analysis. It also lists tools that depend on the returned suite UUID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new GitHub issue in the project's connected repository. Use this to report bugs found during testing, track test failures, or create action items from chat discussions. For a failed test, pass its executedTestCaseUuid so the issue carries the run's evidence (failing step, expected vs actual, screenshot, report link). The issue is created by the Wopee.io GitHub App and names the requester in its body. Requires a GitHub repository linked to the project and WOPEE_PROJECT_UUID to be set.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | The body/description of the GitHub issue (supports Markdown). Kept verbatim, above anything Wopee.io adds from the test run. | |
| title | Yes | The title of the GitHub issue | |
| labels | No | Optional labels to apply to the issue (e.g., ['bug', 'testing']) | |
| executedTestCaseUuid | No | UUID of the executed test case the issue is about (the executedTestCaseUuid shown by wopee_fetch_recent_executions and wopee_dispatch_agent, or uuid in wopee_fetch_executed_test_cases). When set, Wopee.io adds the failing step, expected vs actual, the failing step's screenshot and a link to the run in Commander, so the body only needs your own analysis. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that the Wopee.io GitHub App authors the issue, that the requester is named in the body, that the body is kept verbatim above injected content, and that executedTestCaseUuid triggers addition of failing step, expected vs actual, screenshot, and run link. Prerequisites (linked repo, WOPEE_PROJECT_UUID) are stated. It omits what the call returns (issue number/URL) and failure behavior when no repo is linked.
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?
Five sentences, front-loaded with the action, then use cases, then the key optional parameter's effect, then prerequisites. Each sentence contributes; nothing is filler, though the 'names the requester in its body' detail is the least essential.
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?
For a 4-param mutation with no annotations and no output schema, the description covers purpose, triggers, side effects of augmentation, and prerequisites. The main gap is the return value (issue number/URL) and error conditions when the GitHub link or env var is missing, which the agent would need to report success or failure.
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?
Schema coverage is 100%, so baseline is 3, but the description adds rationale beyond field definitions: it frames executedTestCaseUuid as the way to attach run evidence and clarifies that 'the body only needs your own analysis' because Wopee appends the rest. That interplay between body and executedTestCaseUuid is meaningful interpretation, not repetition.
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?
States a specific verb+resource ('Create a new GitHub issue in the project's connected repository') and enumerates concrete use cases (report bugs, track test failures, create action items). No sibling does issue creation, so no competing tool needs naming, and the agent can distinguish intent immediately.
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?
Gives clear triggers for use (bugs found during testing, test failures, action items from chat) and a conditional directive: 'For a failed test, pass its executedTestCaseUuid.' It stops short of explicit exclusions or 'when not to use', but there are no near-alternatives among siblings that would require them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dispatch an autonomous AI agent to execute specific test cases. The agent opens a real browser, navigates the app, follows test steps, and reports results. Tests run ASYNCHRONOUSLY (1-3 minutes). This tool returns tracking info confirming dispatch — NOT final results. Do NOT interpret the response as pass/fail. Results arrive later via chat notifications. Prerequisite: test cases must exist in the suite (generate with wopee_generate_artifact type USER_STORIES_WITH_TEST_CASES). Use wopee_fetch_recent_executions or wopee_fetch_executed_test_cases to check status later.
| Name | Required | Description | Default |
|---|---|---|---|
| suiteUuid | Yes | UUID of the suite to dispatch the agent for | |
| testCases | Yes | Chosen test cases to dispatch the agent for | |
| analysisIdentifier | Yes | Analysis identifier of the suite to dispatch the agent for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so: async execution, 1-3 minute duration, the response is tracking info only, and final results arrive later through chat notifications. This is exactly the behavioral context an agent cannot infer from the schema.
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 async/returns-tracking caveat is front-loaded in the second half of the opening, and the misuse warning is placed immediately after it. Every sentence contributes a distinct operational fact; no filler.
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?
Although there is no output schema, the description explicitly explains what the return value is (dispatch confirmation/tracking info) and where the real results appear. Combined with the prerequisite and polling alternative, an agent has everything it needs to invoke and follow up correctly.
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?
Schema description coverage is 100%, so suiteUuid, analysisIdentifier, and the nested testCases array (testCaseId/userStoryId) are already documented in the schema. The description adds the conceptual prerequisite that cases must belong to an existing suite, but no extra format or value guidance beyond the schema — the baseline 3 applies.
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 uses a specific verb and resource ("Dispatch an autonomous AI agent to execute specific test cases") and immediately clarifies the mechanism (real browser, navigation, test steps, result reporting). This makes it distinguishable from the other dispatch tool (wopee_dispatch_analysis) and from the fetch tools.
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?
It states a hard precondition (test cases must exist; generate via wopee_generate_artifact with type USER_STORIES_WITH_TEST_CASES), gives the follow-up path for status (wopee_fetch_recent_executions / wopee_fetch_executed_test_cases), and explicitly warns against a misuse (treating the response as pass/fail).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new analysis suite AND dispatch an AI crawling agent in one step. The agent opens a real browser, navigates from the starting URL, discovers pages, and maps the application structure. Use this when you want to auto-analyze a web app — it combines suite creation and crawling. Use wopee_create_blank_suite instead if you want to manually populate the suite. Optionally accepts starting URL, login credentials, cookie preferences (ACCEPT_ALL, DECLINE_ALL, IGNORE), custom variables, and free-text instructions to guide the crawl. Not idempotent: each call creates a new suite and starts a new crawl. Side effects: creates a suite and execution records on the platform. Rate limit: 10 seconds between dispatches per project; concurrent calls auto-retry with exponential backoff. Returns the created suite object on success.
| Name | Required | Description | Default |
|---|---|---|---|
| rerun | No | If provided, reruns an existing analysis suite instead of creating a new one. Requires suiteUuid, analysisIdentifier, and mode. | |
| additionalVariables | No | Additional environment variables for the analysis. Each variable needs a key (uppercase, e.g. BASE_URL) and a non-empty value. | |
| additionalInstructions | No | Additional instructions for the agent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does meaningful work by disclosing side effects (suite and execution records), rate limiting, retry behavior, and the return value. However, it misstates behavior by saying 'each call creates a new suite' and 'not idempotent,' while the schema allows rerunning an existing suite via the rerun parameter.
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 front-loaded and mostly efficient, covering purpose, alternative, side effects, rate limits, and return value in a compact block. A few details are inaccurate rather than verbose, so structure is strong but content quality is reduced.
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?
For a complex dispatch-and-create tool with no annotations and no output schema, the description covers many operational details. It is still incomplete and somewhat misleading because it does not explain the rerun mode and references crawl parameters that the schema does not expose.
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?
Schema coverage is 100%, so the baseline would be 3. But the description actively mentions parameters that are not present in the schema (starting URL, login credentials, cookie preferences) and omits the important rerun parameter, creating confusion about what inputs are actually accepted.
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 a specific verb and resource: creating an analysis suite and dispatching an AI crawling agent. It distinguishes itself from wopee_create_blank_suite and explains the crawling behavior. However, it says each call creates a new suite even though the schema exposes a rerun path for existing suites, which weakens precision.
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?
It gives clear usage context: use this for automatic web-app analysis, and use wopee_create_blank_suite instead when populating a suite manually. The main gap is that it does not explain when to use the rerun parameter versus a fresh dispatch, despite rerun being part of the input schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all analysis suites in the current project. Returns an array of suite objects with UUIDs, names, types (ANALYSIS, AGENT, etc.), and running statuses (IDLE, IN_PROGRESS, FINISHED). Use this to discover existing suites before calling other tools — you need a suite UUID for wopee_generate_artifact, wopee_fetch_artifact, wopee_update_artifact, and wopee_dispatch_agent. Read-only: does not create or modify anything. Takes no input; uses WOPEE_PROJECT_UUID from environment. Returns an empty array if no suites exist. Fails if WOPEE_PROJECT_UUID is not configured.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavior: read-only (does not create or modify), takes no input (uses WOPEE_PROJECT_UUID from environment), returns empty array if no suites, and fails if WOPEE_PROJECT_UUID 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?
Concise and front-loaded: first sentence states purpose, then details return values, usage guidance, read-only nature, error condition. Every sentence provides essential information with no redundancy.
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 zero parameters and no output schema, the description is fully complete: it covers what is returned (array of suite objects with fields), how to use (prerequisite for sibling tools), side effects (none), and failure mode (missing env var). No gaps remain.
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?
Input schema has zero parameters with 100% schema description coverage. The description adds value by explaining that the tool uses an environment variable (WOPEE_PROJECT_UUID) implicitly, which is beyond the schema.
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 lists all analysis suites in the current project and describes the returned data (UUIDs, names, types, statuses). It distinguishes itself from siblings by explicitly noting that other tools require a suite UUID from this tool.
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?
Explicitly states when to use: 'Use this to discover existing suites before calling other tools'. Lists the sibling tools that depend on the output (wopee_generate_artifact, etc.). Provides a clear use case and prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a specific test artifact from a suite. Returns the artifact content as text. Use this to review what wopee_generate_artifact created, or to retrieve existing artifacts before editing with wopee_update_artifact. Does NOT modify any data — this is a read-only operation. If the requested artifact type has not been generated yet for this suite, returns an empty result. For PLAYWRIGHT_CODE, you must provide the test case identifier (e.g. 'US004:TC006'); omitting it returns an error. For all other types, the identifier parameter is ignored.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Type of test artifact to retrieve. One of: APP_CONTEXT (application description), GENERAL_USER_STORIES (stories without test cases), USER_STORIES (stories with test cases), PLAYWRIGHT_CODE (generated test code — requires identifier), PROJECT_CONTEXT (project-level context). | |
| suiteUuid | Yes | UUID of the analysis suite to fetch artifacts from. Get this from wopee_fetch_analysis_suites. | |
| identifier | No | Test case identifier in format 'US004:TC006'. Required only when type is PLAYWRIGHT_CODE. Ignored for all other artifact types. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does the heavy lifting: it declares the operation read-only ('Does NOT modify any data'), discloses the empty-result behavior for ungenerated types, and warns that PLAYWRIGHT_CODE without an identifier errors out. It stops short of mentioning auth requirements, payload size limits, or error shapes for invalid suiteUuid.
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 read-only guarantee and primary use case are front-loaded, and each sentence carries information. It is slightly longer than necessary, since the identifier rule is stated twice (once generally, once per-type).
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?
Without an output schema, the description correctly compensates by describing the return value (artifact content as text) and the empty-result case. The remaining gap is handling of error conditions beyond the missing-identifier case, which is minor for a three-parameter read tool.
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?
Schema coverage is 100%, so every parameter and the type enum are already documented. The description's note about identifier being required for PLAYWRIGHT_CODE and ignored otherwise largely restates the schema, though it adds the concrete consequence ('omitting it returns an error'). Baseline 3 is appropriate.
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 opens with a specific verb plus resource ('Retrieve a specific test artifact from a suite') and states the return shape ('content as text'). It is clearly distinguishable from the sibling write tools wopee_generate_artifact and wopee_update_artifact.
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?
It names explicit use cases — reviewing what wopee_generate_artifact produced and fetching before editing with wopee_update_artifact — and states the read-only nature, so the agent knows when this is the right tool versus the mutation siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve results of test cases executed by the autonomous agent. Returns each test case with its execution status (IN_PROGRESS, FINISHED, FAILED), agent report (natural language findings), and code report (technical details). Read-only: does not trigger any execution. Use this after wopee_dispatch_agent to check results — if status is IN_PROGRESS, wait and call again. Requires suite UUID. Optionally accepts an analysis identifier (e.g. A068, found in suite data) to filter to a specific analysis run. Returns an empty array if no test cases have been executed in this suite. Do NOT use this to fetch test artifacts like user stories or code — use wopee_fetch_artifact for that.
| Name | Required | Description | Default |
|---|---|---|---|
| suiteUuid | Yes | UUID of the analysis suite to fetch executed test cases for | |
| analysisIdentifier | No | Analysis identifier of the suite (ex. A068). Can be found in the analysis suite data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and does well: it declares read-only behavior ('does not trigger any execution'), documents the observable status values, and states the empty-array case so the agent can distinguish 'nothing ran' from an error. It stops short of covering pagination, result-set size limits, or auth/rate-limit expectations for a repeatedly polled call.
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?
Front-loaded with the core action, then behavior, then invocation order, then the exclusion. It is dense but every clause carries operational information — no filler or restatement of the name.
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?
No output schema exists, so the description compensates by naming the returned fields (execution status with its enumerable values, agent report as natural-language findings, code report as technical details) and the empty-result behavior. Combined with the required parameter and the dispatch follow-up workflow, an agent has enough to call and interpret it correctly.
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?
Schema coverage is 100%, so the baseline is 3. The description adds modest value by restating the required suite UUID and by clarifying that analysisIdentifier narrows results 'to a specific analysis run' and can be found in suite data — useful intent that the schema field text alone only partially conveys.
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?
States a specific verb (retrieve) and resource (results of test cases executed by the autonomous agent) and enumerates what each result carries (status, agent report, code report). It is clearly demarcated from siblings by naming wopee_dispatch_agent as the producer and wopee_fetch_artifact as the non-overlapping alternative.
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?
Gives explicit sequencing ('Use this after wopee_dispatch_agent'), a polling rule ('if status is IN_PROGRESS, wait and call again'), and an explicit exclusion with the correct alternative ('Do NOT use this to fetch test artifacts ... use wopee_fetch_artifact'). Prerequisites (suite UUID) and the optional filter condition are also spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the most recent test case executions for the current project (up to 20, newest first). Use this to check the status of recently dispatched tests without needing to remember specific suite UUIDs. Returns each run's verdict (PASSED, FAILED, or INCOMPLETE — the run never established a result, e.g. an infrastructure error, and says nothing about the application) or, for a run with no verdict yet, its execution status (IN_QUEUE, IN_PROGRESS, FINISHED, FAILED, STOPPED), plus agent reports. Takes no input; uses WOPEE_PROJECT_UUID from environment. Prefer this tool when the user asks 'what's the status?' or 'how did the tests go?' and you don't have the specific suite UUID handy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does substantial work: it discloses the result shape (verdict PASSED/FAILED/INCOMPLETE, fallback execution status IN_QUEUE/IN_PROGRESS/FINISHED/FAILED/STOPPED) and explains the important semantic that INCOMPLETE is an infrastructure failure saying nothing about the application. It stops short of stating read-only safety, rate limits, or pagination beyond the 20-item cap.
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?
Front-loaded with the core action and scope in the first sentence, then usage routing, then return semantics. The verdict/status enumeration parenthetical is long and slightly run-on, but every element carries information the agent needs given there is no output schema.
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?
No output schema exists, so the description must explain returns, and it does so thoroughly (verdict, status fallback, agent reports). Combined with the env-var note and usage triggers, an agent has everything needed to call and interpret this tool correctly.
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?
Zero parameters, so the baseline is 4. The description adds useful context by stating 'Takes no input; uses WOPEE_PROJECT_UUID from environment', which documents an implicit configuration dependency an agent would otherwise have no way of knowing.
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?
Specific verb (Fetch) + resource (recent test case executions) with explicit scope ('up to 20, newest first') and project scoping. It is clearly distinguishable from siblings like wopee_fetch_executed_test_cases and wopee_fetch_analysis_suites because it states the recency window and the no-UUID-required angle.
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?
Gives explicit when-to-use triggers ('what's the status?', 'how did the tests go?') and the condition that selects it ('without needing to remember specific suite UUIDs' / 'don't have the specific suite UUID handy'). That directly routes the agent away from UUID-keyed siblings when no UUID is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The authoritative tool for how many tests exist and their latest status. Returns, per analysis, the FULL list of authored test cases joined with their latest execution status — including never-run ones as NOT_RUN. Use this for questions like 'how many tests do I have', 'list the scenarios/test cases in A001', or 'show executed and not-run tests in one table'. Terminology: a 'scenario' is a test case; test cases are grouped under user stories (US001) and identified as US001:TC001. Reusable blocks (user story R001) are counted separately (reusableBlockCount) and are building blocks, not runnable, so they never carry an execution status. Regular tests are all non-R001 test cases. Read-only. Takes an optional analysisIdentifier (e.g. A001) to scope to one analysis; omit to cover every analysis in the project. Prefer this over wopee_fetch_recent_executions / wopee_fetch_executed_test_cases when the user asks about totals or the complete list — those return only test cases that have already run. Each test case carries executedTestCaseUuid (the latest run's uuid, the same one wopee_dispatch_agent returns) and verdictGateDisagreed (true when a verdict gate disagreed with a PASSED verdict — report it alongside the pass). Status UNKNOWN means the execution history could not be read (the reason is in the analysis's executionHistoryError); do not report such tests as not run.
| Name | Required | Description | Default |
|---|---|---|---|
| analysisIdentifier | No | Optional analysis identifier (e.g. A001) to scope the inventory to a single analysis. Omit to include every analysis in the project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does most of it: declares read-only, explains NOT_RUN vs UNKNOWN semantics, warns not to report UNKNOWN tests as not run, and documents verdictGateDisagreed and executedTestCaseUuid. Gaps remain on response volume/pagination and any permission requirements for a project-wide fetch with no scoping.
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?
Dense but nearly every clause carries information an agent needs (terminology, edge cases, sibling routing). The one flaw is structure: it is a single long paragraph rather than front-loaded sections, so the terminology and edge-case material competes with the core purpose statement.
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?
For a one-parameter read tool with no output schema, the description supplies return-field semantics (executedTestCaseUuid, verdictGateDisagreed, reusableBlockCount), terminology mapping (scenario = test case, US001:TC001), and error handling guidance. What it omits is expected result size/pagination for a project-wide inventory, which matters given 'FULL list' wording.
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?
Schema coverage is 100% and the single parameter is already documented, so the baseline is 3; the description adds value by reinforcing the omit-means-every-analysis semantics and giving a concrete example (A001). It adds little beyond the schema text, which caps it below 5.
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?
Opens with a specific verb+resource framing ('how many tests exist and their latest status') and immediately states the distinguishing behavior: returns the FULL list of authored test cases joined with latest execution status, including never-run ones. It explicitly names the two siblings that return a narrower set, so an agent can differentiate without opening either schema.
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?
Gives concrete trigger phrasings ('how many tests do I have', 'list the scenarios/test cases in A001') and an explicit exclusion rule: prefer this over wopee_fetch_recent_executions / wopee_fetch_executed_test_cases when the user asks about totals or the complete list. It also explains the optional scoping parameter's use case (omit to cover every analysis).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the run-time variables (additionalVariables) that drive analysis/agent runs, at either level. level: PROJECT returns the project-level variables (uses WOPEE_PROJECT_UUID from the environment); level: ANALYSIS returns a specific analysis suite's variables and requires suiteUuid. Read-only. Returns a JSON string array of { key, value, sourceType } entries, or [] when none are set. Use wopee_fetch_analysis_suites to discover suite UUIDs.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | Which variable set to read. PROJECT reads the project-level variables (uses WOPEE_PROJECT_UUID from the environment). ANALYSIS reads a specific analysis suite's variables and requires suiteUuid. | |
| suiteUuid | No | UUID of the analysis suite to read variables from. Required when level is ANALYSIS; ignored when level is PROJECT. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the burden, and it does well: declares the operation read-only, names the environment dependency (WOPEE_PROJECT_UUID), specifies the return shape ({key, value, sourceType}) and the empty-result case ([]). It omits error/auth behavior for a missing or invalid suiteUuid, which keeps it short of a 5.
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 key information (what it reads, the level split, read-only, return format, sibling pointer) is front-loaded in a compact sequence of short sentences. Slightly dense, but every clause — including the environment-variable note and [] case — carries information.
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?
With only two simple parameters, no output schema, and no annotations, the description covers the important gaps: return value shape, empty case, environment dependency, and the discovery path for suiteUuid. Error handling for an invalid or absent suiteUuid is the main remaining omission.
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?
Schema description coverage is 100% and the schema already spells out the enum semantics and the 'required when ANALYSIS / ignored when PROJECT' rule, so the description's restatement adds little beyond the structured fields. Baseline 3 is appropriate.
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?
States a specific verb and resource (read run-time variables / additionalVariables) and precisely scopes the two variants via the level enum, so the agent can distinguish this from sibling tools like wopee_update_variables without consulting the schema.
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?
Explains what each level returns and the prerequisite (suiteUuid required for ANALYSIS, project UUID from environment for PROJECT), plus routes to wopee_fetch_analysis_suites for UUID discovery. It never explicitly contrasts with wopee_update_variables as the write counterpart, but 'Read-only' plus the fetch naming makes the boundary clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate AI-powered test artifacts for a suite using the Wopee.io AI engine. Each call creates one artifact type — call multiple times for different types. Generation order matters: APP_CONTEXT must be generated before user stories, and user stories before test cases. If called out of order, the AI may produce lower quality results. On success, returns confirmation that generation started. Use wopee_fetch_artifact to retrieve the generated content once ready. Do NOT use this to hand-edit existing artifacts — use wopee_update_artifact instead. TEST_CASES runs in UPDATE mode by default: existing test cases keep their steps and run history, and instructions says what to add or change. Destructive generations are mode CREATE (replaces the test cases in scope and deletes their steps, runs and code), USER_STORIES_WITH_TEST_CASES (rebuilds every story and test case) and TEST_CASE_STEPS (replaces the steps of the test cases in scope): use them only when the user explicitly asks for that, and scope them with selectedUserStories / selectedTestCases when the user named stories or test cases.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | TEST_CASES only. UPDATE (default) keeps every existing test case with its steps and run history, and adds or changes test cases around them. CREATE replaces the test cases of the stories in scope — of the whole suite when selectedUserStories is empty — and deletes their steps, run history and Playwright code. Use CREATE only when the user explicitly asks to start over. | UPDATE |
| type | Yes | Type of test artifact to generate. One of: APP_CONTEXT, GENERAL_USER_STORIES, USER_STORIES_WITH_TEST_CASES, TEST_CASES, TEST_CASE_STEPS, REUSABLE_TEST_CASES, REUSABLE_TEST_CASE_STEPS. Start with APP_CONTEXT, then generate stories and test cases from it. | |
| async | No | TEST_CASES and USER_STORIES_WITH_TEST_CASES only. true returns as soon as the generation is queued instead of waiting for it (a large suite can take several minutes); the content is then read later with wopee_fetch_artifact. Default false: wait and return the generated artifact. | |
| suiteUuid | Yes | UUID of the analysis suite to generate artifacts for. Get this from wopee_create_blank_suite or wopee_fetch_analysis_suites. | |
| instructions | No | What the user asked for, in their words, e.g. 'add a negative test for an expired card'. Passed to the AI engine as the change request; without it, UPDATE removes no test case. | |
| selectedTestCases | No | Test case identifiers to limit TEST_CASE_STEPS to, e.g. ['US001:TC002']. Leave empty for every test case in scope. Regenerating steps replaces the steps those test cases have. | |
| selectedUserStories | No | User story ids to limit the generation to, e.g. ['US001', 'US003']. Leave empty for every story in the suite. Used by TEST_CASES and TEST_CASE_STEPS. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well by explaining generation order, UPDATE-vs-CREATE behavior, destructive replacement effects, and scoping. However, the return behavior is slightly inconsistent: it says success returns confirmation that generation started and directs the agent to fetch later, while the schema says async defaults to false and waits to return the generated artifact.
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 front-loaded with purpose and then covers ordering, alternatives, and destructive modes. It is dense but mostly earns its length given the complexity, though the long destructive-mode sentence could be more scannable and the return statement is slightly misleading.
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?
For a seven-parameter generation tool with no annotations and no output schema, the description covers purpose, generation ordering, destructive modes, retrieval via wopee_fetch_artifact, and alternatives. The main gap is that its return-value explanation conflicts with the schema's async behavior and does not fully describe what the caller receives.
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?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful cross-call ordering semantics for type, maps destructive generation types beyond the mode schema, and explains scoping with selectedUserStories and selectedTestCases. It does not add much for async or suiteUuid, which are left to the schema.
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 states a specific verb and resource: generate AI-powered test artifacts for a suite using the Wopee.io AI engine. It also clarifies that each call creates one artifact type and distinguishes the tool from wopee_update_artifact and wopee_fetch_artifact.
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?
It explicitly states the required generation order, when to call multiple times, and that hand-editing should use wopee_update_artifact instead. It also names destructive generation modes and says to use them only when the user explicitly requests them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read recent messages from the current project's chat room. Returns the last N messages in chronological order, including sender info and timestamps. Use this to understand the conversation context or review what has been discussed. Requires WOPEE_PROJECT_UUID to be configured.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of recent messages to fetch (default: 20, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well: it discloses ordering (chronological), the shape of returned content (sender info, timestamps), and a real prerequisite (WOPEE_PROJECT_UUID must be configured). It does not mention rate limits, pagination/cursor behavior, or what happens when the room has fewer than N messages.
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?
Three tight sentences: purpose, return shape, and usage, with the configuration prerequisite at the end. No repetition of the title and nothing that could be cut.
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?
For a one-parameter read tool with no output schema, the description covers purpose, return contents, ordering, and the environment prerequisite. The remaining gap is minor: it doesn't say what an empty or unconfigured project yields, but an agent has enough to call it correctly.
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?
Schema coverage is 100% and the single optional limit parameter already documents default 20, max 100, and semantics. The description's "last N messages in chronological order" reinforces the meaning of the limit but adds no syntax or behavior beyond the schema, so the baseline 3 applies.
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?
States a specific verb and resource ("Read recent messages from the current project's chat room") plus the scope of the read (current project). The read semantics cleanly separate it from the sibling wopee_send_chat_message without needing to name it.
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?
"Use this to understand the conversation context or review what has been discussed" gives a clear use case for when to call it. It stops short of exclusions or pointing to alternatives, but for a single-purpose read tool the intended context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a message to the current project's chat room. Use this to post status updates (e.g., 'Test run started...', 'Analysis complete') or informational messages to the chat. The message will appear as a SYSTEM message in the chat room. Requires WOPEE_PROJECT_UUID to be configured.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The message content to send to the chat room | |
| contentType | No | The type of message: TEXT for regular messages, STATUS_UPDATE for status notifications | TEXT |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must carry the behavioral load. It provides crucial context that isn't in the schema, specifically that the message appears as a 'SYSTEM message' and that the 'WOPEE_PROJECT_UUID' is a mandatory configuration prerequisite.
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?
While all information is necessary, the description is slightly wordy. The definition could be tightened by reducing conversational filler while retaining the technical requirements and usage examples.
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?
The description is very complete for this simple tool. It specifies the target, the behavioral output (System message), and the necessary setup (UUID configuration), leaving no major gaps for the agent.
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?
With 100% schema coverage, the description must add depth. It succeeds by semantically differentiating the 'content' and 'contentType' parameters, giving concrete examples of status updates vs. regular messages.
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 action ('Send a message') and the target resource ('current project's chat room'). It is easily distinguishable from other sibling tools like read_chat_history or issue creation.
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?
It provides strong usage context by suggesting concrete scenarios, such as posting status updates or informational messages. It is clear when this tool should be employed for chat communication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or overwrite a test artifact in a suite with caller-supplied content. The full content is replaced, not patched. Use this to upload your own APP_CONTEXT (e.g. built from JIRA / Confluence), user stories, project context, or Playwright code, or to fix / refine an artifact previously authored by wopee_generate_artifact. Works on any suite, including freshly-created blank suites with no prior generation — the artifact does not need to exist beforehand. Use wopee_generate_artifact instead when you want the Wopee.io AI engine to author the content from scratch. On success, returns confirmation. On failure (e.g. invalid suite UUID, storage misconfiguration), returns an error message. Idempotent: calling with the same content multiple times produces the same result.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Type of test artifact to update. One of: APP_CONTEXT, GENERAL_USER_STORIES, USER_STORIES, PLAYWRIGHT_CODE (requires identifier), PROJECT_CONTEXT. Must match the type used when the artifact was generated. | |
| content | Yes | The complete new content to replace the existing artifact. This is a destructive overwrite — the entire previous content is replaced. Pass the full updated content, not a partial diff. | |
| suiteUuid | Yes | UUID of the analysis suite containing the artifact to update. Get this from wopee_fetch_analysis_suites. | |
| identifier | No | Test case identifier in format 'US004:TC006'. Required only when type is PLAYWRIGHT_CODE. Ignored for all other artifact types. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and does so: it discloses destructive full-content replacement, idempotency under repeated identical calls, success/failure return shape, and example failure modes (invalid suite UUID, storage misconfiguration). The pre-existence behavior — create-or-overwrite on a blank suite — is exactly the kind of trait an agent cannot infer from the schema.
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?
Front-loaded with the action and the destructive semantics, and the positive/negative routing plus idempotency notes all carry information. It runs long and the return-value sentences are slightly padded, but no sentence is filler.
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?
With no annotations and no output schema, the description steps in to cover write semantics, idempotency, and the success/error response contract, so an agent has everything needed to invoke it correctly. Nothing material about this mutation tool is left unstated.
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?
Schema coverage is 100%, so the baseline is 3; the description earns a bump by grounding the abstract enum in concrete usage — APP_CONTEXT built from JIRA/Confluence, user stories, project context, or Playwright code — which helps the agent decide which type value to send and what content shape is expected. It does not restate the 'identifier' rule for PLAYWRIGHT_CODE, but the schema already covers that fully.
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?
States a specific verb and resource — 'Create or overwrite a test artifact in a suite with caller-supplied content' — and immediately clarifies it is a full replacement, not a patch. It is clearly separable from wopee_generate_artifact and from wopee_fetch_artifact by naming the authoring-responsibility split.
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?
Explicitly names the alternative ('Use wopee_generate_artifact instead when you want the Wopee.io AI engine to author the content from scratch') and the positive case (uploading your own APP_CONTEXT from JIRA/Confluence, user stories, Playwright code, or refining a generated artifact). It also removes a likely false blocker by stating the artifact need not pre-exist, including on blank suites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upsert the run-time variables (additionalVariables) that drive analysis/agent runs, at either level. level: PROJECT writes the project-level variables (uses WOPEE_PROJECT_UUID from the environment); level: ANALYSIS writes a specific analysis suite's variables and requires suiteUuid. Merge semantics: keys in variables[] are added or overwritten, existing keys not listed are preserved. Keys must be uppercase (e.g. BASE_URL); the server re-sanitizes and drops invalid keys. Returns a confirmation on success.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | Which variable set to write. PROJECT writes the project-level variables (uses WOPEE_PROJECT_UUID from the environment). ANALYSIS writes a specific analysis suite's variables and requires suiteUuid. | |
| suiteUuid | No | UUID of the analysis suite to write variables to. Required when level is ANALYSIS; ignored when level is PROJECT. | |
| variables | Yes | Variables to upsert. Each needs an uppercase key (e.g. BASE_URL) and a non-empty value. Merge semantics: keys listed here are added or overwritten; existing keys not listed here are preserved. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses merge/upsert semantics (existing unlisted keys are preserved, so this is not a full replace), server-side key sanitization that silently drops invalid keys, the WOPEE_PROJECT_UUID environment dependency, and a success confirmation. It stops short of stating whether overwriting an existing key is reversible or what auth/permissions are required.
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?
Front-loaded with the verb and resource, then the level routing and merge semantics, each sentence carrying distinct information. Slightly dense with parentheticals but nothing purely redundant.
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?
For a mutation tool with no annotations and no output schema, the description covers the key risks: merge (not replace) behavior, silent dropping of invalid keys, env-var dependency, and a return confirmation. Missing only error/permission behavior and reversibility, which keeps it from a 5.
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?
Schema description coverage is 100%, so the schema already explains level, suiteUuid, and the variables[] merge behavior. The description largely restates those same rules (uppercase keys, suiteUuid required for ANALYSIS) rather than adding format or constraint detail beyond the schema; baseline 3 applies.
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?
States a specific verb (upsert) and resource (run-time variables / additionalVariables) with scope ('at either level') and purpose ('drive analysis/agent runs'). An agent can immediately distinguish it from the read-side sibling wopee_fetch_variables and from the artifact/dispatch tools.
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?
It clearly routes between the two levels (PROJECT vs ANALYSIS requires suiteUuid), which is useful conditional guidance. However, it never names an alternative tool or says when not to use this one (e.g., 'to inspect values use wopee_fetch_variables'), so usage is only implied.
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.
v1.32.1wopee_create_github_issue1 field changedInput schema / additionalPropertiesRemoved value: -falsewopee_dispatch_agent2 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / testCases / items / additionalPropertiesRemoved value: -falsewopee_dispatch_analysis3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / additionalVariables / anyOfPrevious value: -[
- {
- "description": "Additional environment variables for the analysis. Each variable needs a key (uppercase, e.g. BASE_URL) and a non-empty value.",
- "items": {
- "additionalProperties": false,
- "properties": {
- "key": {
- "description": "Variable name. Must be uppercase with underscores only (e.g. MY_VAR, BASE_URL).",
- "pattern": "^[A-Z_][A-Z0-9_]*$",
- "type": "string"
- },
- "value": {
- "description": "Variable value. Must be a non-empty string.",
- "minLength": 1,
- "type": "string"
- }
- },
- "required": [
- "key",
- "value"
- ],
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "items": {
+ "properties": {
+ "key": {
+ "description": "Variable name. Must be uppercase with underscores only (e.g. MY_VAR, BASE_URL).",
+ "pattern": "^[A-Z_][A-Z0-9_]*$",
+ "type": "string"
+ },
+ "value": {
+ "description": "Variable value. Must be a non-empty string.",
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "key",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / rerun / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "analysisIdentifier": {
- "description": "Analysis identifier of the existing suite to rerun.",
- "minLength": 1,
- "type": "string"
- },
- "mode": {
- "description": "Rerun mode: FULL reruns the entire analysis (crawling + analysis), CRAWLING reruns only the crawling phase.",
- "enum": [
- "FULL",
- "CRAWLING"
- ],
- "type": "string"
- },
- "suiteUuid": {
- "description": "UUID of the existing suite to rerun.",
- "minLength": 1,
- "type": "string"
- }
- },
- "required": [
- "suiteUuid",
- "analysisIdentifier",
- "mode"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "properties": {
+ "analysisIdentifier": {
+ "description": "Analysis identifier of the existing suite to rerun.",
+ "minLength": 1,
+ "type": "string"
+ },
+ "mode": {
+ "description": "Rerun mode: FULL reruns the entire analysis (crawling + analysis), CRAWLING reruns only the crawling phase.",
+ "enum": [
+ "FULL",
+ "CRAWLING"
+ ],
+ "type": "string"
+ },
+ "suiteUuid": {
+ "description": "UUID of the existing suite to rerun.",
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "suiteUuid",
+ "analysisIdentifier",
+ "mode"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]wopee_fetch_artifact1 field changedInput schema / additionalPropertiesRemoved value: -falsewopee_fetch_executed_test_cases1 field changedInput schema / additionalPropertiesRemoved value: -falsewopee_fetch_test_inventory1 field changedInput schema / additionalPropertiesRemoved value: -falsewopee_fetch_variables1 field changedInput schema / additionalPropertiesRemoved value: -falsewopee_generate_artifact6 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / asyncAdded value: +{
+ "description": "TEST_CASES and USER_STORIES_WITH_TEST_CASES only. true returns as soon as the generation is queued instead of waiting for it (a large suite can take several minutes); the content is then read later with wopee_fetch_artifact. Default false: wait and return the generated artifact.",
+ "type": "boolean"
+}Input schema / properties / instructionsAdded value: +{
+ "description": "What the user asked for, in their words, e.g. 'add a negative test for an expired card'. Passed to the AI engine as the change request; without it, UPDATE removes no test case.",
+ "type": "string"
+}Input schema / properties / modeAdded value: +{
+ "default": "UPDATE",
+ "description": "TEST_CASES only. UPDATE (default) keeps every existing test case with its steps and run history, and adds or changes test cases around them. CREATE replaces the test cases of the stories in scope — of the whole suite when selectedUserStories is empty — and deletes their steps, run history and Playwright code. Use CREATE only when the user explicitly asks to start over.",
+ "enum": [
+ "UPDATE",
+ "CREATE"
+ ],
+ "type": "string"
+}Input schema / properties / selectedTestCasesAdded value: +{
+ "description": "Test case identifiers to limit TEST_CASE_STEPS to, e.g. ['US001:TC002']. Leave empty for every test case in scope. Regenerating steps replaces the steps those test cases have.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / selectedUserStoriesAdded value: +{
+ "description": "User story ids to limit the generation to, e.g. ['US001', 'US003']. Leave empty for every story in the suite. Used by TEST_CASES and TEST_CASE_STEPS.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}wopee_read_chat_history1 field changedInput schema / additionalPropertiesRemoved value: -falsewopee_send_chat_message1 field changedInput schema / additionalPropertiesRemoved value: -falsewopee_update_artifact1 field changedInput schema / additionalPropertiesRemoved value: -falsewopee_update_variables2 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / variables / items / additionalPropertiesRemoved value: -falsev1.31.0wopee_create_github_issue3 fields changedInput schema / properties / body / descriptionPrevious value: -"The body/description of the GitHub issue (supports Markdown)"New value: +"The body/description of the GitHub issue (supports Markdown). Kept verbatim, above anything Wopee.io adds from the test run."Input schema / properties / executedTestCaseUuidAdded value: +{
+ "description": "UUID of the executed test case the issue is about (the executedTestCaseUuid shown by wopee_fetch_recent_executions and wopee_dispatch_agent, or uuid in wopee_fetch_executed_test_cases). When set, Wopee.io adds the failing step, expected vs actual, the failing step's screenshot and a link to the run in Commander, so the body only needs your own analysis.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "title",
- "body"
-]New value: +[
+ "title"
+]v1.29.1wopee_fetch_test_inventorywopee_fetch_variableswopee_update_variablesv1.26.3wopee_fetch_recent_executionsv1.26.1wopee_create_github_issuewopee_read_chat_historywopee_send_chat_messagev1.0.1wopee_fetch_artifact3 fields changedInput schema / properties / identifier / descriptionPrevious value: -"Identifier for the test case to fetch playwright code for, ex. `US004:TC006`, should be provided only for `PLAYWRIGHT_CODE` artifact type"New value: +"Test case identifier in format 'US004:TC006'. Required only when type is PLAYWRIGHT_CODE. Ignored for all other artifact types."Input schema / properties / suiteUuid / descriptionPrevious value: -"UUID of the suite to fetch the file from"New value: +"UUID of the analysis suite to fetch artifacts from. Get this from wopee_fetch_analysis_suites."Input schema / properties / type / descriptionPrevious value: -"Chosen file(artifact) to fetch"New value: +"Type of test artifact to retrieve. One of: APP_CONTEXT (application description), GENERAL_USER_STORIES (stories without test cases), USER_STORIES (stories with test cases), PLAYWRIGHT_CODE (generated test code — requires identifier), PROJECT_CONTEXT (project-level context)."wopee_generate_artifact2 fields changedInput schema / properties / suiteUuid / descriptionPrevious value: -"UUID of the suite to generate file(artifact) for"New value: +"UUID of the analysis suite to generate artifacts for. Get this from wopee_create_blank_suite or wopee_fetch_analysis_suites."Input schema / properties / type / descriptionPrevious value: -"Chosen type of file(artifact) to generate"New value: +"Type of test artifact to generate. One of: APP_CONTEXT, GENERAL_USER_STORIES, USER_STORIES_WITH_TEST_CASES, TEST_CASES, TEST_CASE_STEPS, REUSABLE_TEST_CASES, REUSABLE_TEST_CASE_STEPS. Start with APP_CONTEXT, then generate stories and test cases from it."wopee_update_artifact4 fields changedInput schema / properties / content / descriptionPrevious value: -"Content of the file(artifact) to update"New value: +"The complete new content to replace the existing artifact. This is a destructive overwrite — the entire previous content is replaced. Pass the full updated content, not a partial diff."Input schema / properties / identifier / descriptionPrevious value: -"Identifier for the test case to update playwright code for, ex. `US004:TC006`, should be provided only for `PLAYWRIGHT_CODE` artifact type"New value: +"Test case identifier in format 'US004:TC006'. Required only when type is PLAYWRIGHT_CODE. Ignored for all other artifact types."Input schema / properties / suiteUuid / descriptionPrevious value: -"UUID of the suite to update the file for"New value: +"UUID of the analysis suite containing the artifact to update. Get this from wopee_fetch_analysis_suites."Input schema / properties / type / descriptionPrevious value: -"Chosen file(artifact) to update"New value: +"Type of test artifact to update. One of: APP_CONTEXT, GENERAL_USER_STORIES, USER_STORIES, PLAYWRIGHT_CODE (requires identifier), PROJECT_CONTEXT. Must match the type used when the artifact was generated."v1.0.0wopee_create_blank_suitewopee_dispatch_agentwopee_dispatch_analysiswopee_fetch_analysis_suiteswopee_fetch_artifactwopee_fetch_executed_test_caseswopee_generate_artifactwopee_update_artifactScored across 15 tools
Most tools target clearly distinct resources or actions, and the descriptions explicitly differentiate similar operations such as fetch_recent_executions, fetch_executed_test_cases, and fetch_test_inventory. However, the three execution-reading tools still have enough conceptual overlap that an agent could occasionally misselect, and create_blank_suite versus dispatch_analysis requires careful reading.
All tools use the consistent wopee_ prefix and snake_case verb_noun naming, e.g. wopee_fetch_artifact, wopee_update_variables, wopee_dispatch_agent. The minor read versus fetch distinction for chat history does not disrupt the otherwise predictable pattern.
The 15 tools are well-scoped for a testing platform covering chat, suites, executions, artifacts, variables, GitHub issues, and agent dispatch. Each functional area has a small set of necessary operations without excessive redundancy.
The tool set covers the core Wopee lifecycle: creating suites, generating and editing artifacts, dispatching analysis/agent runs, reading results, managing variables, chatting, and creating GitHub issues. Minor gaps remain around deletion/cleanup, cancellation of runs, and broader GitHub issue management, but these are not likely to block common agent workflows.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Official Browserless MCP server: browser automation, scraping, screenshots and PDFs for AI agents.
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
Hosted Web Crawler MCP server for Claude, ChatGPT and Cursor, with each action switched per account.
