The wopee-mcp server connects to Wopee.io for AI-powered autonomous testing, enabling you to create analysis suites, generate test artifacts, dispatch AI test agents, and review results.
Suite Management
List existing suites (wopee_fetch_analysis_suites): discover all suites with UUIDs, names, types, and statuses
Create a blank suite (wopee_create_blank_suite): set up an empty suite for manual configuration
Dispatch an analysis crawl (wopee_dispatch_analysis): launch an AI agent to crawl a web app and map its structure, with optional login steps, custom instructions, and variables
Artifact Generation & Management
Generate artifacts (wopee_generate_artifact): AI-driven generation of app context, user stories, test cases, and test steps
Fetch artifacts (wopee_fetch_artifact): retrieve generated content such as app context, user stories, and Playwright code
Update artifacts (wopee_update_artifact): create or overwrite artifacts with custom content (e.g., from JIRA/Confluence)
Autonomous Testing & Results
Dispatch a testing agent (wopee_dispatch_agent): execute test cases in a real browser, capturing screenshots and reporting pass/fail results
Fetch recent executions (wopee_fetch_recent_executions): check the status of recently dispatched tests
Fetch detailed results (wopee_fetch_executed_test_cases): retrieve per-suite results including agent reports and code reports
Communication & Integrations
Send/read chat messages (wopee_send_chat_message, wopee_read_chat_history): post updates and review history in the project's chat room
Create GitHub issues (wopee_create_github_issue): report bugs or failures directly to the connected repository
Built-in Prompts
fetch-project-summary: formatted overview of suites and their test cases
fetch-test-results: formatted summary of test execution statuses and failed report details
Provides tools to fetch and update application context, project context, and general user stories in Markdown format.
AI-powered autonomous testing for your apps -- connect Claude, Cursor, or any MCP-compatible AI agent to Wopee.io and generate test cases, user stories, and run autonomous tests in seconds.
npx wopee-mcpNode.js (v18 or higher recommended)
An IDE that supports MCP (Model Context Protocol), such as Cursor or VSCode
Add this server to your MCP configuration.
{
"mcpServers": {
"wopee": {
"command": "npx wopee-mcp",
"env": {
"WOPEE_PROJECT_UUID": "your-project-uuid-here",
"WOPEE_API_KEY": "your-api-key-here"
}
}
}
}WOPEE_PROJECT_UUID - Your Wopee project UUID. This identifies which project you're working with.
WOPEE_API_KEY - Your Wopee API key. You can create one at cmd.wopee.io, in your project's settings.
WOPEE_API_URL - The Wopee API endpoint URL. Should be specified only for testing/development purposes.
If you're behind a corporate proxy/VPN and experiencing connection timeouts, you can configure proxy settings using standard environment variables:
{
"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 or https_proxy - Proxy server URL for HTTPS connections (recommended)
HTTP_PROXY or http_proxy - Fallback proxy server URL
If you're unsure about your proxy settings, check your VS Code settings (settings.json) for http.proxy value, or consult your IT department. Common corporate proxy formats:
http://proxy.company.com:8080
http://10.x.x.x:8080
http://username:password@proxy.company.com:8080 (if authentication is required)
This is not required for MCP to work. If you see HTTPS or certificate-related errors, that indicates a TLS or certificate trust issue in your environment.
If the server fails with errors such as UNABLE_TO_VERIFY_LEAF_SIGNATURE or certificate has expired, it may be due to:
Self-signed certificates (e.g. when WOPEE_API_URL points to an internal or dev server)
Corporate proxy / SSL inspection (traffic re-encrypted with a corporate CA your machine doesn’t trust)
Missing CA certificates in Node’s trust store
Use a valid TLS certificate – e.g. Let’s Encrypt, or an internal CA – and ensure the full certificate chain is served.
Install the corporate or internal CA so Node trusts it:
Example:
export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/internal-ca.pemIn MCP config env:
"env": {
"WOPEE_PROJECT_UUID": "your-project-uuid-here",
"WOPEE_API_KEY": "your-api-key-here",
"NODE_EXTRA_CA_CERTS": "/path/to/ca.pem"
}For local debugging only, you may disable TLS verification in Node. This should never be used in production, as it disables HTTPS security and exposes traffic to interception.
export NODE_TLS_REJECT_UNAUTHORIZED=0Or in MCP config env:
"env": {
"WOPEE_PROJECT_UUID": "your-project-uuid-here",
"WOPEE_API_KEY": "your-api-key-here",
"NODE_TLS_REJECT_UNAUTHORIZED": "0"
}Treat this as a debug-only escape hatch, not a normal setup step.
Note: Some users have reported setting PYTHONHTTPSVERIFY=0 as well. This MCP server does not use Python; that variable has no effect on it. It would only apply if you run a Python-based MCP host or other tooling that also performs HTTPS in the same environment—outside the scope of this server.
Related MCP server: Playwright MCP
Most tools in this MCP server require a suiteUuid to operate. You have two options to get started:
Start by fetching your existing analysis suites:
Use the wopee_fetch_analysis_suites tool to retrieve all available suites for your project.This will return a list of all analysis suites with their UUIDs, which you can then use with other tools.
If you don't have any suites yet, you have two options:
Automatic Analysis: Create and dispatch a full analysis/crawling suite:
Use the wopee_dispatch_analysis tool to create and dispatch a new analysis/crawling suite.Blank Suite: Create an empty suite for manual configuration:
Use the wopee_create_blank_suite tool to create a blank analysis suite.Both options will return a suite UUID, which you can use for subsequent operations.
wopee_fetch_analysis_suitesFetches all analysis suites for your project. This is a good starting point to see what suites are available.
Returns: Array of analysis suites with their UUIDs, names, statuses, and metadata
Example Usage:
Fetch all existing analysis suites for my projectwopee_dispatch_analysisCreates and dispatches a new analysis/crawling suite for your project, or reruns an existing one. Use this to start a fresh analysis session or to re-trigger a previous analysis.
Parameters:
additionalInstructions (optional) - Additional instructions to guide the agent during the analysis/crawling phase (e.g. focus areas, things to ignore, login steps, etc.)
additionalVariables (optional) - Additional environment variables to pass to the analysis. Array of objects, each with:
key - Variable name, must be uppercase with underscores only (e.g. MY_VAR, BASE_URL)
value - Variable value (non-empty string)
rerun (optional) - If provided, reruns an existing analysis suite instead of creating a new one. Object with:
suiteUuid - UUID of the existing suite to rerun
analysisIdentifier - Analysis identifier of the existing suite
mode - Rerun mode: FULL (reruns the entire analysis including crawling and generation) or CRAWLING (reruns only the crawling phase)
Returns: Success message with the created/rerun suite information
Example Usage:
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_suiteCreates a blank analysis suite for your project. Use this when you want to manually configure and populate a suite rather than having it automatically analyzed.
Returns: The created suite information including its UUID
Example Usage:
Create a blank analysis suite for my projectThese tools generate various artifacts for a specific suite. All require a suiteUuid and type to generate.
wopee_generate_artifactGenerates a specific file(artifact) for the selected suite.
Parameters:
suiteUuid - The UUID of the suite
type - "APP_CONTEXT" | "GENERAL_USER_STORIES" | "USER_STORIES_WITH_TEST_CASES" | "TEST_CASES" | "TEST_CASE_STEPS" | "REUSABLE_TEST_CASES" | "REUSABLE_TEST_CASE_STEPS"
Returns: Generated output in case of successful generation.
Example Usage:
Generate app context for my most recent analysis suiteThese tools retrieve generated artifacts for a specific suite. All require a suiteUuid and type.
wopee_fetch_artifactFetches the enquired file(artifact) from the selected suite.
Parameters:
suiteUuid - The UUID of the suite
type - "APP_CONTEXT" | "GENERAL_USER_STORIES" | "USER_STORIES" | "PLAYWRIGHT_CODE" | "PROJECT_CONTEXT"
identifier - Identifier of the test case to fetch Playwright code for, ex. US003:TC004
Returns: The file contents in case of successful fetch.
Example Usage:
Fetch user stories for the latest suiteThese tools are used to update or set certain files(artifacts) for a specific suite. suiteUuid, type and content is required.
wopee_update_artifactUpdates/replaces existing file(artifact) for a specific suite
Parameters:
suiteUuid - The UUID of the suite
type - "APP_CONTEXT" | "GENERAL_USER_STORIES" | "USER_STORIES" | "PLAYWRIGHT_CODE" | "PROJECT_CONTEXT"
content - Markdown content for app context, general user stories and project context, structured JSON for user stories
identifier - Identifier of the test case to fetch Playwright code for, ex. US003:TC004
Returns: Boolean based of success status of the tool call
Example Usage:
Update app context file for the most recent suite with this content: <YourMarkdown>wopee_dispatch_agentDispatches an autonomous testing agent to execute test cases for a selected suite. Tests run asynchronously (typically 1-3 minutes). This tool confirms dispatch and returns tracking info — not final results.
Parameters:
suiteUuid - The UUID of the suite containing the test cases
analysisIdentifier - The analysis identifier for the suite
testCases - Array of test case objects to execute, each containing:
testCaseId - The ID of the test case
userStoryId - The ID of the associated user story
Returns: Dispatch confirmation with tracking info (suite UUID, analysis identifier, per-test-case execution status). Does NOT return pass/fail results — use wopee_fetch_recent_executions or wopee_fetch_executed_test_cases to check results later.
Example Usage:
Dispatch agent for my latest suite's user story US001 and test case TC003wopee_fetch_recent_executionsFetches the most recent test case executions for the current project (up to 20, newest first). Use this to quickly check the status of recently dispatched tests without needing to remember specific suite UUIDs.
Parameters: None (uses WOPEE_PROJECT_UUID from environment)
Returns: List of recent executions with execution status (IN_PROGRESS, IN_QUEUE, FINISHED, FAILED), agent reports, and pass/fail results
Example Usage:
What's the status of my recent test runs?How did my tests go?wopee_fetch_executed_test_casesFetches executed test cases and their results for a given analysis suite. Use this to check the status and reports of dispatched agent runs.
Parameters:
suiteUuid - The UUID of the analysis suite to fetch results for
analysisIdentifier (optional) - Analysis identifier to narrow results (e.g. A068)
Returns: Array of results grouped by user story, each containing executed test cases with execution status, agent report, agent report status, code report, and code report status
Example Usage:
Fetch test results for suite <suiteUuid>Show me the executed test cases for my latest analysis suiteStart with a suite:
Use wopee_fetch_analysis_suites to see existing suites, OR
Use wopee_dispatch_analysis to create a new suite
Generate artifacts:
Generate app context: wopee_generate_artifact with APP_CONTEXT and specific suiteUuid
Generate general user stories: wopee_generate_artifact with GENERAL_USER_STORIES and specific suiteUuid
Generate user stories with test cases: wopee_generate_artifact with USER_STORIES_WITH_TEST_CASES and specific suiteUuid
Generate reusable test cases: wopee_generate_artifact with REUSABLE_TEST_CASES and specific suiteUuid
Generate reusable test case steps: wopee_generate_artifact with REUSABLE_TEST_CASE_STEPS and specific suiteUuid
Generate test case steps: wopee_generate_artifact with TEST_CASE_STEPS and specific suiteUuid
Fetch generated content:
Use the fetch tools to retrieve generated markdown/JSON files
Run tests:
Use wopee_dispatch_agent to execute test cases with the autonomous testing agent
Check results:
Use wopee_fetch_recent_executions to quickly check status of recent test runs
Use wopee_fetch_executed_test_cases to check detailed status and reports for a specific suite
Or use the fetch-test-results prompt for a formatted summary of all test results
fetch-project-summaryFetches analysis suites and their user stories/test cases, then displays a formatted summary with two markdown tables: a suite overview and a detailed test case breakdown.
fetch-test-resultsFetches analysis suites and their executed test case results, then displays formatted markdown tables showing execution status, agent report status, and code report status for each test case. Also surfaces failed report details.
Most tools require a suiteUuid. Always start by fetching or creating a suite.
wopee_dispatch_analysis tool will go through whole cycle of processing - crawling the application and generating all of the files(artifacts) one by one.
It is advisable to use cmd.wopee.io for a convenient visual representation of the generated data and results of the agent runs.
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. The issue will be created in the GitHub repository linked to the current project. Requires the project to have GitHub integration configured and WOPEE_PROJECT_UUID to be set.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The body/description of the GitHub issue (supports Markdown) | |
| title | Yes | The title of the GitHub issue | |
| labels | No | Optional labels to apply to the issue (e.g., ['bug', 'testing']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that issue is created in linked repo and requires integration. Does not mention return value, error handling, or potential side effects, though creation is generally safe.
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 sentences with no redundant information. Purpose, use cases, and prerequisites are front-loaded. Each sentence serves a distinct role.
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?
Simple tool with 3 params and no output schema. Description covers purpose, use scenarios, and prerequisites. Missing mention of return value or success indication, but overall adequate for the complexity.
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 100% description coverage, so baseline 3. Description adds no new semantic meaning beyond schema; it only provides context. No additional parameter details.
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?
Clearly states 'Create a new GitHub issue in the project's connected repository' with specific verb and resource. Lists concrete use cases (bug reports, test failures, action items). Sibling tools have different purposes, so well differentiated.
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 says when to use (reporting bugs, tracking failures, action items) and mentions prerequisites (GitHub integration and WOPEE_PROJECT_UUID). Lacks explicit 'not for' cases, but context is sufficient.
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?
Discloses key behaviors: asynchronous execution (1-3 minutes), real browser usage, return of tracking info not final results, and later delivery via chat notifications. Since no annotations exist, the description fully covers transparency needs.
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 concise (4 sentences) and front-loaded with purpose. Every sentence adds value, though breaking into bullet points could enhance structure slightly. Still efficient for the information provided.
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 async nature and lack of output schema, the description covers prerequisites, result delivery mechanism, and status-checking alternatives. Minor omissions like error handling or exact format of chat notifications keep 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 coverage is 100% and already describes parameters. The description adds the prerequisite that test cases must exist in the suite, but does not add significant new semantic meaning beyond the schema, so 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 clearly states the tool dispatches an autonomous AI agent to execute specific test cases, opening a browser and following steps. It distinguishes from siblings like wopee_dispatch_analysis and wopee_generate_artifact by specifying the action and prerequisite.
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?
Provides explicit when-to-use context: run only after test cases are generated via wopee_generate_artifact. It warns against interpreting immediate response as pass/fail and directs to sibling tools for later status checking, giving clear usage boundaries.
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 provided, the description carries full burden. It explicitly states non-idempotency, side effects (suite and execution records creation), rate limit (10 seconds per project), and concurrent call behavior (auto-retry with exponential backoff).
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 a single focused paragraph that front-loads the main action and covers all essential aspects without redundancy. Every sentence adds value, making it efficient and well-structured.
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 tool's complexity (multiple parameters including optional and rerun, side effects, rate limits), the description is fully complete. It explains what it does, how to use, behavioral details, and expected return value ('returns the created suite object'). No gaps.
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 description adds contextual meaning beyond schema by summarizing optional parameters (cookie preferences, custom variables, instructions) and explaining the rerun parameter. It clarifies that rerun reuses existing suite without creating new one.
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 analysis suite and dispatches an AI crawling agent in one step. It explicitly contrasts with sibling wopee_create_blank_suite, which is for manual population, distinguishing the tool's purpose.
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?
Description tells when to use this tool (auto-analyze a web app) and when not to (use wopee_create_blank_suite for manual population). It also mentions optional parameters like starting URL and login credentials, providing clear usage context.
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 fully describes the read-only behavior, return format (text), empty result for missing artifacts, and identifier handling. No mention of rate limits or auth, but core behavioral traits are covered.
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?
Single paragraph, front-loaded with purpose, then concise usage notes. Every sentence adds value with no redundancy or fluff.
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 no annotations or output schema, the description covers all essential aspects: behavior, parameters, special cases, and differentiation from siblings. Complete for a fetch 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 covers 100% of parameters with descriptions, but the description adds extra context: the special identifier requirement for PLAYWRIGHT_CODE and that identifier is ignored for other types. This adds value beyond 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 uses a specific verb ('Retrieve') and resource ('test artifact from a suite'), clearly distinguishing it from sibling tools like 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?
Explicitly states when to use (review created artifacts, retrieve before editing) and provides alternatives by naming sibling tools. Also clarifies read-only nature and special requirements for PLAYWRIGHT_CODE.
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?
No annotations provided, but description declares read-only nature, mentions empty array return, and fully describes behavioral traits without contradiction.
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 with no wasted sentences. Front-loaded with purpose and progressively adds detail.
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?
Covers return values, edge cases (empty array), and interaction steps despite no output schema. Complete for a tool with 2 parameters.
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%, baseline 3. Description adds value for analysisIdentifier by specifying format (ex. A068) and source (found in suite data), going beyond 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?
Description clearly states it retrieves results of test cases executed by the autonomous agent. It specifies return fields (status, agent report, code report) and distinguishes from sibling tool 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?
Explicitly says to use after wopee_dispatch_agent, advises waiting if IN_PROGRESS, and explicitly warns against using for artifacts, directing to alternative.
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 execution status (IN_PROGRESS, IN_QUEUE, FINISHED, FAILED), agent reports, and pass/fail results. 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 fully discloses behavior: it returns execution statuses, agent reports, pass/fail results, uses an environment variable, and is a read operation. No contradictions or hidden side effects.
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 concise, with a front-loaded main action, followed by use case, return details, and input clarification. Every sentence adds value without 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 the simplicity (no params, no output schema), the description covers return values (statuses, results), limits (20, newest first), and environmental input. It is complete for an agent to use 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?
Despite having zero parameters, the description explains that no input is required and that it uses the WOPEE_PROJECT_UUID from the environment, adding meaning beyond the empty 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 identifies the verb 'Fetch' and resource 'recent test case executions' with constraints (up to 20, newest first). It distinguishes from sibling tools like wopee_fetch_analysis_suites and wopee_fetch_executed_test_cases by specifying exactly what is fetched.
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: 'to check status of recently dispatched tests without needing specific suite UUIDs' and prefers this tool for queries like 'what's the status?' when no UUID is handy. This provides clear guidance versus alternatives.
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.
| 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?
No annotations are provided, so the description carries the full burden — and it delivers. It discloses read-only semantics, that never-run tests appear as NOT_RUN, the reusable-block (R001) exclusion rule with reusableBlockCount, and the scoping behavior of the optional analysisIdentifier.
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 highest-value statement, then progresses logically through return contents, terminology, reusable blocks, read-only note, and parameter behavior. Every sentence carries distinct information without redundancy or fluff despite its length.
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 skillfully covers the return semantics (full inventory, NOT_RUN inclusion, reusableBlockCount) and the domain model anomalies. It could marginally enrich the exact shape of the return object, but is quite complete for a single optional-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%, establishing a baseline of 3. The description adds clarity on the omit-behavior ('to include every analysis in the project') and enriches the conceptual meaning of the parameter with the default scope, making the semantics crisper than the schema description alone.
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 the specific, value-dense claim "The authoritative tool for how many tests exist and their latest status" and clarifies it returns the FULL list of authored tests joined with execution status. It explicitly differentiates from siblings by naming what they lack (only executed tests).
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?
Provides explicit when-to-use guidance with concrete example questions ('how many tests do I have', 'list the scenarios/test cases in A001') and names the exact alternative tools to prefer over, explaining the key distinction: those return only already-run test cases.
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 provided, so the description carries full burden. It discloses read-only behavior, return format (JSON array of {key, value, sourceType} entries), empty list when none set, and the environment variable dependency (WOPEE_PROJECT_UUID) for PROJECT level. This goes beyond minimal disclosure, though it doesn't cover error cases or rate limits.
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 compact and front-loaded: first sentence states the core purpose, second elaborates the level-specific behavior, third covers return format and cross-reference. No redundant or filler content; every sentence earns its place.
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 two-parameter getter with no output schema, the description covers the essential context: purpose, parameter behavior, return shape, and a pointer to the sibling tool for suite discovery. It doesn't explain `sourceType` values or error conditions, but that's acceptable given the tool's simplicity and the absence of annotations.
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%, with both parameters already well-documented: `level` includes the enum and PROJECT/ANALYSIS behavior, and `suiteUuid` details the required/ignored condition. The description repeats this info but adds no new semantics. Baseline of 3 is appropriate since the schema does the heavy lifting.
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 reads run-time variables with a specific verb ('Read') and explicit resource ('run-time variables (additionalVariables)'). It distinguishes itself from siblings by mentioning the two levels and directing to `wopee_fetch_analysis_suites` for discovery, avoiding confusion with update_variables.
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 explicit usage context: explains the difference between PROJECT and ANALYSIS, notes the suiteUuid requirement for ANALYSIS, and points to `wopee_fetch_analysis_suites` as the alternative for discovering UUIDs. The 'Read-only' tag also implicitly tells the agent not to use this tool for modifications.
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 update existing artifacts — use wopee_update_artifact instead. Generating the same type again overwrites the previous version.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| suiteUuid | Yes | UUID of the analysis suite to generate artifacts for. Get this from wopee_create_blank_suite or wopee_fetch_analysis_suites. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description covers ordering dependencies, overwriting behavior, return confirmation, and retrieval mechanism. Complete behavioral context.
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?
Six concise sentences, front-loaded with purpose, each sentence adds unique value. No fluff.
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?
Despite no output schema, description adequately explains return value. Covers ordering, overwrite, retrieval, and alternatives. Sufficient for the tool's complexity.
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 has 100% coverage, and description adds extra guidance: start with APP_CONTEXT, and sources for suiteUuid. Enriches both parameters.
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?
Clearly states the tool generates AI-powered test artifacts, specifies it creates one per call, lists artifact types, and distinguishes from sibling tools (fetch/update).
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 says when to use (generating artifacts), when not to use (updating), provides alternatives (wopee_update_artifact, wopee_fetch_artifact), and gives ordering constraints.
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, description covers key behavior: returns last N messages, order, data included, and required configuration. Lacks error conditions or what happens without UUID.
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?
Two sentences, no fluff. Immediately states verb, object, and key details. Highly efficient.
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 simple read tool with one parameter, description covers return values, configuration requirement, and purpose. No output schema needed.
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 covers 100% with full description of limit. Description does not add beyond what schema provides; 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?
Description clearly states the tool reads recent chat messages, specifies chronological order and included data (sender info, timestamps). Distinguishes from sending messages.
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 says to use for understanding conversation context or review. Mentions prerequisite (WOPEE_PROJECT_UUID). Does not mention when not to use or compare with siblings like wopee_send_chat_message.
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?
The description discloses that the message appears as a SYSTEM message, which is useful behavioral context. However, with no annotations provided, the description could further detail side effects, error handling, or authentication requirements. The information is adequate but not exhaustive.
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 three sentences with no filler. It front-loads the primary action and immediately provides usage context. Every sentence adds value.
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 simple two-parameter tool with no output schema, the description covers the essential aspects: what it does, when to use, prerequisite configuration, and message behavior (SYSTEM message). It is slightly lacking in return value details but overall complete for the tool's complexity.
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 already describes both parameters (content and contentType) with 100% coverage. The description adds minimal extra semantics beyond stating the message type (SYSTEM). The schema descriptions themselves are clear, so the description's contribution is limited.
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?
Description clearly states the tool sends a message to the current project's chat room, specifying the verb 'send' and resource 'chat message'. It contrasts with the sibling tool wopee_read_chat_history, which is for reading, thus avoiding confusion.
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?
Provides explicit examples of when to use (posting status updates or informational messages) and notes the prerequisite of configuring WOPEE_PROJECT_UUID. However, it does not mention when not to use or explicitly name alternatives.
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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It states that content is fully replaced (not patched), that the operation is idempotent, and describes success/error behavior. However, it does not mention authentication requirements or rate limits, though these are minor omissions.
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 concise (4 sentences) and well-structured, with each sentence serving a clear purpose: stating the main function, explaining replacement semantics, providing usage guidance, and describing idempotency and error handling. No unnecessary words.
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 tool's complexity (4 parameters, no output schema, no annotations), the description covers all essential aspects: purpose, behavioral traits (overwrite, idempotent), when to use vs. sibling, error scenarios, and parameter roles. It provides sufficient context for correct invocation.
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 a baseline of 3 is appropriate. The description reinforces the full-replacement nature of the 'content' parameter and mentions the conditional requirement of 'identifier' for PLAYWRIGHT_CODE, but adds little beyond what the schema already 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: 'Create or overwrite a test artifact in a suite with caller-supplied content.' It specifies the verb (create/overwrite) and the resource (test artifact), and explicitly distinguishes from sibling tool wopee_generate_artifact by contrasting when to use each.
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 provides explicit guidance: use this tool for uploading your own content or refining AI-generated artifacts, and use wopee_generate_artifact when you want the AI engine to author from scratch. It also notes that the tool works on any suite, including blank ones, clarifying when it's applicable.
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 provided, the description fully carries the burden. It discloses merge semantics ('keys in variables[] are added or overwritten, existing keys not listed are preserved'), server-side sanitization ('drops invalid keys'), and return behavior ('Returns a confirmation on success'). It could further state that this operation modifies persistent state, but the word 'upsert' and the merge details convey the mutation clearly.
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 three sentences long, each packed with essential information: purpose and levels, level-specific logic, and merge/validation behaviors. There is no fluff or repetition; every sentence adds value, making it highly efficient and well-structured.
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 tool's moderate complexity (3 parameters, no output schema, no annotations), the description covers all critical aspects: purpose, level-specific details, merge behavior, validation, and success confirmation. It omits edge cases like error handling or limits, but for the intended use, it is sufficiently complete.
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 provides 100% coverage for all parameters with detailed descriptions, including the enum for 'level', the conditional requirement for 'suiteUuid', and the pattern for 'key'. The description adds a concise summary of these semantics but does not introduce additional meaning beyond the schema, maintaining the baseline for good schema coverage.
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: 'Upsert the run-time variables (additionalVariables) that drive analysis/agent runs, at either level.' It specifies the two levels (PROJECT and ANALYSIS) and distinguishes itself from related tools like wopee_fetch_variables (reading) and wopee_update_artifact (different resource).
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 usage context by explaining the two levels and their requirements (e.g., 'ANALYSIS requires suiteUuid'), and by contrasting with fetching operations via sibling tools. However, it does not explicitly state when to use this tool over alternatives or when not to use it, so it falls short of a 5.
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. Dates show when Glama detected each change.
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_artifactMost tools have clearly distinct responsibilities, and the descriptions explicitly route an agent to the correct tool for suite discovery, artifact handling, dispatch, or status checks. The only real ambiguity is between the three execution/status retrieval tools: fetch_executed_test_cases, fetch_recent_executions, and fetch_test_inventory all expose overlapping execution/test data and require careful reading to avoid misselection.
Every tool follows a consistent wopee_verb_noun convention using snake_case: create/fetch/update/dispatch/generate/send/read plus a meaningful noun. The mix of read and fetch is not problematic because each action still follows the same underlying pattern and no tool uses camelCase or a wildly divergent verb style.
Fifteen tools is at the upper end of a typical well-scoped server but each tool serves a distinct workflow area: suite management, artifact authoring, dispatch, execution status, variables, chat, and GitHub issue creation. There is no obvious filler tool, and the count reflects the breadth of the platform without becoming overwhelming.
The core workflow is well covering: create suites, generate and update artifacts, dispatch analyses/agents, fetch statuses/results, manage variables, use chat, and file GitHub issues. Notable missing operations are cleanup/cancelation—e.g., deleting a suite or artifact, removing variables, or stopping a running dispatch—so the lifecycle is not fully complete but common agent workflows do not hit unavoidable dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Wopee-io/wopee-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
