Skip to main content
Glama
Sign In
wopee-mcp

wopee-mcp

Official
by Wopee-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Update test artifacts

wopee_update_artifact

Create or overwrite a test artifact with caller-supplied content, fully replacing it to upload app context, user stories, project context, or Playwright code or refine existing artifacts.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
typeYesType 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.
contentYesThe 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.
suiteUuidYesUUID of the analysis suite containing the artifact to update. Get this from wopee_fetch_analysis_suites.
identifierNoTest case identifier in format 'US004:TC006'. Required only when type is PLAYWRIGHT_CODE. Ignored for all other artifact types.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.32.1
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed4 schema fields changedv1.0.1
    • changedInput schema / properties / content / description
      Previous 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."
    • changedInput schema / properties / identifier / description
      Previous 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."
    • changedInput schema / properties / suiteUuid / description
      Previous 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."
    • changedInput schema / properties / type / description
      Previous 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."
  3. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so: it discloses destructive full-content replacement, idempotency under repeated identical calls, success/failure return shape, and example failure modes (invalid suite UUID, storage misconfiguration). The pre-existence behavior — create-or-overwrite on a blank suite — is exactly the kind of trait an agent cannot infer from the schema.

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

Conciseness4/5

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

Front-loaded with the action and the destructive semantics, and the positive/negative routing plus idempotency notes all carry information. It runs long and the return-value sentences are slightly padded, but no sentence is filler.

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

Completeness5/5

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

With no annotations and no output schema, the description steps in to cover write semantics, idempotency, and the success/error response contract, so an agent has everything needed to invoke it correctly. Nothing material about this mutation tool is left unstated.

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

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; the description earns a bump by grounding the abstract enum in concrete usage — APP_CONTEXT built from JIRA/Confluence, user stories, project context, or Playwright code — which helps the agent decide which type value to send and what content shape is expected. It does not restate the 'identifier' rule for PLAYWRIGHT_CODE, but the schema already covers that fully.

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

Purpose5/5

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

States a specific verb and resource — 'Create or overwrite a test artifact in a suite with caller-supplied content' — and immediately clarifies it is a full replacement, not a patch. It is clearly separable from wopee_generate_artifact and from wopee_fetch_artifact by naming the authoring-responsibility split.

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

Usage Guidelines5/5

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

Explicitly names the alternative ('Use wopee_generate_artifact instead when you want the Wopee.io AI engine to author the content from scratch') and the positive case (uploading your own APP_CONTEXT from JIRA/Confluence, user stories, Playwright code, or refining a generated artifact). It also removes a likely false blocker by stating the artifact need not pre-exist, including on blank suites.

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

Deploy Server

Other Tools