Pruebas autónomas impulsadas por IA para tus aplicaciones: conecta Claude, Cursor o cualquier agente de IA compatible con MCP a Wopee.io y genera casos de prueba, historias de usuario y ejecuta pruebas autónomas en segundos.
npx wopee-mcpNode.js (se recomienda v18 o superior)
Un IDE que soporte MCP (Model Context Protocol), como Cursor o VSCode
Añade este servidor a tu configuración de 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 - El UUID de tu proyecto en Wopee. Identifica con qué proyecto estás trabajando.
WOPEE_API_KEY - Tu clave de API de Wopee. Puedes crear una en cmd.wopee.io, en la configuración de tu proyecto.
WOPEE_API_URL - La URL del endpoint de la API de Wopee. Solo debe especificarse para fines de prueba/desarrollo.
Si estás detrás de un proxy/VPN corporativo y experimentas tiempos de espera en la conexión, puedes configurar los ajustes del proxy usando variables de entorno estándar:
{
"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 o https_proxy - URL del servidor proxy para conexiones HTTPS (recomendado)
HTTP_PROXY o http_proxy - URL del servidor proxy de respaldo
Si no estás seguro de tus ajustes de proxy, revisa la configuración de tu VS Code (settings.json) para el valor http.proxy, o consulta a tu departamento de TI. Formatos comunes de proxy corporativo:
http://proxy.company.com:8080
http://10.x.x.x:8080
http://usuario:contraseña@proxy.company.com:8080 (si se requiere autenticación)
Esto no es necesario para que MCP funcione. Si ves errores relacionados con HTTPS o certificados, eso indica un problema de confianza de TLS o certificados en tu entorno.
Si el servidor falla con errores como UNABLE_TO_VERIFY_LEAF_SIGNATURE o certificate has expired, puede deberse a:
Certificados autofirmados (p. ej., cuando WOPEE_API_URL apunta a un servidor interno o de desarrollo)
Proxy corporativo / Inspección SSL (tráfico re-encriptado con una CA corporativa en la que tu máquina no confía)
Certificados CA faltantes en el almacén de confianza de Node
Usa un certificado TLS válido – p. ej., Let’s Encrypt, o una CA interna – y asegúrate de que se sirva la cadena de certificados completa.
Instala la CA corporativa o interna para que Node confíe en ella:
Ejemplo:
export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/internal-ca.pemEn la configuración env de MCP:
"env": {
"WOPEE_PROJECT_UUID": "your-project-uuid-here",
"WOPEE_API_KEY": "your-api-key-here",
"NODE_EXTRA_CA_CERTS": "/path/to/ca.pem"
}Solo para depuración local, puedes deshabilitar la verificación TLS en Node. Esto nunca debe usarse en producción, ya que deshabilita la seguridad HTTPS y expone el tráfico a interceptación.
export NODE_TLS_REJECT_UNAUTHORIZED=0O en la configuración env de MCP:
"env": {
"WOPEE_PROJECT_UUID": "your-project-uuid-here",
"WOPEE_API_KEY": "your-api-key-here",
"NODE_TLS_REJECT_UNAUTHORIZED": "0"
}Trata esto como una vía de escape solo para depuración, no como un paso de configuración normal.
Nota: Algunos usuarios han reportado configurar también PYTHONHTTPSVERIFY=0. Este servidor MCP no usa Python; esa variable no tiene efecto en él. Solo aplicaría si ejecutas un host MCP basado en Python u otras herramientas que también realicen HTTPS en el mismo entorno, fuera del alcance de este servidor.
Related MCP server: Playwright MCP
La mayoría de las herramientas en este servidor MCP requieren un suiteUuid para operar. Tienes dos opciones para empezar:
Comienza obteniendo tus suites de análisis existentes:
Use the wopee_fetch_analysis_suites tool to retrieve all available suites for your project.Esto devolverá una lista de todas las suites de análisis con sus UUIDs, que luego podrás usar con otras herramientas.
Si aún no tienes ninguna suite, tienes dos opciones:
Análisis automático: Crea y envía una suite completa de análisis/rastreo:
Use the wopee_dispatch_analysis tool to create and dispatch a new analysis/crawling suite.Suite en blanco: Crea una suite vacía para configuración manual:
Use the wopee_create_blank_suite tool to create a blank analysis suite.Ambas opciones devolverán un UUID de suite, que puedes usar para operaciones posteriores.
wopee_fetch_analysis_suitesObtiene todas las suites de análisis para tu proyecto. Este es un buen punto de partida para ver qué suites están disponibles.
Retorna: Matriz de suites de análisis con sus UUIDs, nombres, estados y metadatos
Ejemplo de uso:
Fetch all existing analysis suites for my projectwopee_dispatch_analysisCrea y envía una nueva suite de análisis/rastreo para tu proyecto, o vuelve a ejecutar una existente. Úsalo para iniciar una nueva sesión de análisis o para volver a activar un análisis previo.
Parámetros:
additionalInstructions (opcional) - Instrucciones adicionales para guiar al agente durante la fase de análisis/rastreo (p. ej., áreas de enfoque, cosas a ignorar, pasos de inicio de sesión, etc.)
additionalVariables (opcional) - Variables de entorno adicionales para pasar al análisis. Matriz de objetos, cada uno con:
key - Nombre de la variable, debe estar en mayúsculas y solo con guiones bajos (p. ej., MY_VAR, BASE_URL)
value - Valor de la variable (cadena no vacía)
rerun (opcional) - Si se proporciona, vuelve a ejecutar una suite de análisis existente en lugar de crear una nueva. Objeto con:
suiteUuid - UUID de la suite existente a reejecutar
analysisIdentifier - Identificador de análisis de la suite existente
mode - Modo de reejecución: FULL (reejecuta todo el análisis incluyendo rastreo y generación) o CRAWLING (reejecuta solo la fase de rastreo)
Retorna: Mensaje de éxito con la información de la suite creada/reejecutada
Ejemplo de uso:
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_suiteCrea una suite de análisis en blanco para tu proyecto. Úsalo cuando quieras configurar y completar manualmente una suite en lugar de que sea analizada automáticamente.
Retorna: La información de la suite creada incluyendo su UUID
Ejemplo de uso:
Create a blank analysis suite for my projectEstas herramientas generan varios artefactos para una suite específica. Todas requieren un suiteUuid y un type para generar.
wopee_generate_artifactGenera un archivo (artefacto) específico para la suite seleccionada.
Parámetros:
suiteUuid - El UUID de la suite
type - "APP_CONTEXT" | "GENERAL_USER_STORIES" | "USER_STORIES_WITH_TEST_CASES" | "TEST_CASES" | "TEST_CASE_STEPS" | "REUSABLE_TEST_CASES" | "REUSABLE_TEST_CASE_STEPS"
Retorna: Salida generada en caso de generación exitosa.
Ejemplo de uso:
Generate app context for my most recent analysis suiteEstas herramientas recuperan artefactos generados para una suite específica. Todas requieren un suiteUuid y un type.
wopee_fetch_artifactObtiene el archivo (artefacto) solicitado de la suite seleccionada.
Parámetros:
suiteUuid - El UUID de la suite
type - "APP_CONTEXT" | "GENERAL_USER_STORIES" | "USER_STORIES" | "PLAYWRIGHT_CODE" | "PROJECT_CONTEXT"
identifier - Identificador del caso de prueba para obtener el código de Playwright, ej. US003:TC004
Retorna: El contenido del archivo en caso de obtención exitosa.
Ejemplo de uso:
Fetch user stories for the latest suiteEstas herramientas se utilizan para actualizar o establecer ciertos archivos (artefactos) para una suite específica. Se requiere suiteUuid, type y content.
wopee_update_artifactActualiza/reemplaza un archivo (artefacto) existente para una suite específica
Parámetros:
suiteUuid - El UUID de la suite
type - "APP_CONTEXT" | "GENERAL_USER_STORIES" | "USER_STORIES" | "PLAYWRIGHT_CODE" | "PROJECT_CONTEXT"
content - Contenido Markdown para app context, general user stories y project context, JSON estructurado para user stories
identifier - Identificador del caso de prueba para obtener el código de Playwright, ej. US003:TC004
Retorna: Booleano basado en el estado de éxito de la llamada a la herramienta
Ejemplo de uso:
Update app context file for the most recent suite with this content: <YourMarkdown>wopee_dispatch_agentEnvía un agente de pruebas autónomo para ejecutar casos de prueba para una suite seleccionada.
Parámetros:
suiteUuid - El UUID de la suite que contiene los casos de prueba
analysisIdentifier - El identificador de análisis para la suite
testCases - Matriz de objetos de casos de prueba a ejecutar, cada uno conteniendo:
testCaseId - El ID del caso de prueba
userStoryId - El ID de la historia de usuario asociada
Retorna: Matriz de objetos de casos de prueba ejecutados con su estado de ejecución inicial (uuid, executionStatus, agentReportStatus, codeReportStatus, etc.)
Ejemplo de uso:
Dispatch agent for my latest suite's user story US001 and test case TC003wopee_fetch_executed_test_casesObtiene los casos de prueba ejecutados y sus resultados para una suite de análisis dada. Úsalo para verificar el estado y los informes de las ejecuciones de agentes enviadas.
Parámetros:
suiteUuid - El UUID de la suite de análisis para obtener resultados
analysisIdentifier (opcional) - Identificador de análisis para limitar los resultados (p. ej., A068)
Retorna: Matriz de resultados agrupados por historia de usuario, cada uno conteniendo casos de prueba ejecutados con estado de ejecución, informe del agente, estado del informe del agente, informe de código y estado del informe de código
Ejemplo de uso:
Fetch test results for suite <suiteUuid>Show me the executed test cases for my latest analysis suiteComienza con una suite:
Usa wopee_fetch_analysis_suites para ver las suites existentes, O
Usa wopee_dispatch_analysis para crear una nueva suite
Genera artefactos:
Genera contexto de la aplicación: wopee_generate_artifact con APP_CONTEXT y un suiteUuid específico
Genera historias de usuario generales: wopee_generate_artifact con GENERAL_USER_STORIES y un suiteUuid específico
Genera historias de usuario con casos de prueba: wopee_generate_artifact con USER_STORIES_WITH_TEST_CASES y un suiteUuid específico
Genera casos de prueba reutilizables: wopee_generate_artifact con REUSABLE_TEST_CASES y un suiteUuid específico
Genera pasos de casos de prueba reutilizables: wopee_generate_artifact con REUSABLE_TEST_CASE_STEPS y un suiteUuid específico
Genera pasos de casos de prueba: wopee_generate_artifact con TEST_CASE_STEPS y un suiteUuid específico
Obtén contenido generado:
Usa las herramientas de obtención para recuperar archivos markdown/JSON generados
Ejecuta pruebas:
Usa wopee_dispatch_agent para ejecutar casos de prueba con el agente de pruebas autónomo
Verifica resultados:
Usa wopee_fetch_executed_test_cases para verificar el estado y los informes de las ejecuciones de agentes enviadas
O usa el prompt fetch-test-results para un resumen formateado de todos los resultados de las pruebas
fetch-project-summaryObtiene las suites de análisis y sus historias de usuario/casos de prueba, luego muestra un resumen formateado con dos tablas markdown: una visión general de la suite y un desglose detallado de los casos de prueba.
fetch-test-resultsObtiene las suites de análisis y los resultados de sus casos de prueba ejecutados, luego muestra tablas markdown formateadas que muestran el estado de ejecución, el estado del informe del agente y el estado del informe de código para cada caso de prueba. También muestra detalles de los informes fallidos.
La mayoría de las herramientas requieren un suiteUuid. Comienza siempre obteniendo o creando una suite.
La herramienta wopee_dispatch_analysis pasará por todo el ciclo de procesamiento: rastrear la aplicación y generar todos los archivos (artefactos) uno por uno.
Es recomendable usar cmd.wopee.io para una representación visual conveniente de los datos generados y los resultados de las ejecuciones del agente.
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
