Skip to main content
Glama
Sign In
wopee-mcp

wopee-mcp

Official
by Wopee-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Generate test artifacts

wopee_generate_artifact

Generate AI-powered test artifacts for your suite. Use this tool to create app context, user stories, and test cases using the Wopee.io AI engine.

Instructions

Generate AI-powered test artifacts for a suite using the Wopee.io AI engine. Each call creates one artifact type — call multiple times for different types. Generation order matters: APP_CONTEXT must be generated before user stories, and user stories before test cases. If called out of order, the AI may produce lower quality results. On success, returns confirmation that generation started. Use wopee_fetch_artifact to retrieve the generated content once ready. Do NOT use this to hand-edit existing artifacts — use wopee_update_artifact instead. TEST_CASES runs in UPDATE mode by default: existing test cases keep their steps and run history, and instructions says what to add or change. Destructive generations are mode CREATE (replaces the test cases in scope and deletes their steps, runs and code), USER_STORIES_WITH_TEST_CASES (rebuilds every story and test case) and TEST_CASE_STEPS (replaces the steps of the test cases in scope): use them only when the user explicitly asks for that, and scope them with selectedUserStories / selectedTestCases when the user named stories or test cases.

Input Schema

NameRequiredDescriptionDefault
modeNoTEST_CASES only. UPDATE (default) keeps every existing test case with its steps and run history, and adds or changes test cases around them. CREATE replaces the test cases of the stories in scope — of the whole suite when selectedUserStories is empty — and deletes their steps, run history and Playwright code. Use CREATE only when the user explicitly asks to start over.UPDATE
typeYesType 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.
asyncNoTEST_CASES and USER_STORIES_WITH_TEST_CASES only. true returns as soon as the generation is queued instead of waiting for it (a large suite can take several minutes); the content is then read later with wopee_fetch_artifact. Default false: wait and return the generated artifact.
suiteUuidYesUUID of the analysis suite to generate artifacts for. Get this from wopee_create_blank_suite or wopee_fetch_analysis_suites.
instructionsNoWhat the user asked for, in their words, e.g. 'add a negative test for an expired card'. Passed to the AI engine as the change request; without it, UPDATE removes no test case.
selectedTestCasesNoTest case identifiers to limit TEST_CASE_STEPS to, e.g. ['US001:TC002']. Leave empty for every test case in scope. Regenerating steps replaces the steps those test cases have.
selectedUserStoriesNoUser story ids to limit the generation to, e.g. ['US001', 'US003']. Leave empty for every story in the suite. Used by TEST_CASES and TEST_CASE_STEPS.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.32.1
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / async
      Added value: +{
+  "description": "TEST_CASES and USER_STORIES_WITH_TEST_CASES only. true returns as soon as the generation is queued instead of waiting for it (a large suite can take several minutes); the content is then read later with wopee_fetch_artifact. Default false: wait and return the generated artifact.",
+  "type": "boolean"
+}
    • addedInput schema / properties / instructions
      Added value: +{
+  "description": "What the user asked for, in their words, e.g. 'add a negative test for an expired card'. Passed to the AI engine as the change request; without it, UPDATE removes no test case.",
+  "type": "string"
+}
    • addedInput schema / properties / mode
      Added value: +{
+  "default": "UPDATE",
+  "description": "TEST_CASES only. UPDATE (default) keeps every existing test case with its steps and run history, and adds or changes test cases around them. CREATE replaces the test cases of the stories in scope — of the whole suite when selectedUserStories is empty — and deletes their steps, run history and Playwright code. Use CREATE only when the user explicitly asks to start over.",
+  "enum": [
+    "UPDATE",
+    "CREATE"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / selectedTestCases
      Added value: +{
+  "description": "Test case identifiers to limit TEST_CASE_STEPS to, e.g. ['US001:TC002']. Leave empty for every test case in scope. Regenerating steps replaces the steps those test cases have.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / selectedUserStories
      Added value: +{
+  "description": "User story ids to limit the generation to, e.g. ['US001', 'US003']. Leave empty for every story in the suite. Used by TEST_CASES and TEST_CASE_STEPS.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. Changed2 schema fields changedv1.0.1
    • changedInput schema / properties / suiteUuid / description
      Previous 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."
    • changedInput schema / properties / type / description
      Previous 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."
  3. First observedv1.0.0

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden well by explaining generation order, UPDATE-vs-CREATE behavior, destructive replacement effects, and scoping. However, the return behavior is slightly inconsistent: it says success returns confirmation that generation started and directs the agent to fetch later, while the schema says async defaults to false and waits to return the generated artifact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and then covers ordering, alternatives, and destructive modes. It is dense but mostly earns its length given the complexity, though the long destructive-mode sentence could be more scannable and the return statement is slightly misleading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a seven-parameter generation tool with no annotations and no output schema, the description covers purpose, generation ordering, destructive modes, retrieval via wopee_fetch_artifact, and alternatives. The main gap is that its return-value explanation conflicts with the schema's async behavior and does not fully describe what the caller receives.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful cross-call ordering semantics for type, maps destructive generation types beyond the mode schema, and explains scoping with selectedUserStories and selectedTestCases. It does not add much for async or suiteUuid, which are left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: generate AI-powered test artifacts for a suite using the Wopee.io AI engine. It also clarifies that each call creates one artifact type and distinguishes the tool from wopee_update_artifact and wopee_fetch_artifact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states the required generation order, when to call multiple times, and that hand-editing should use wopee_update_artifact instead. It also names destructive generation modes and says to use them only when the user explicitly requests them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools