Skip to main content
Glama
Sign In
wopee-mcp

wopee-mcp

Official
by Wopee-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Fetch test artifacts

wopee_fetch_artifact

Fetch a test artifact (app context, user stories, or Playwright code) from a suite as read-only text to review or edit. For Playwright code, provide the test case identifier.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
typeYesType 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).
suiteUuidYesUUID of the analysis suite to fetch artifacts from. 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. Changed3 schema fields changedv1.0.1
    • changedInput schema / properties / identifier / description
      Previous 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."
    • changedInput schema / properties / suiteUuid / description
      Previous 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."
    • changedInput schema / properties / type / description
      Previous 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)."
  3. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description does the heavy lifting: it declares the operation read-only ('Does NOT modify any data'), discloses the empty-result behavior for ungenerated types, and warns that PLAYWRIGHT_CODE without an identifier errors out. It stops short of mentioning auth requirements, payload size limits, or error shapes for invalid suiteUuid.

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

Conciseness4/5

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

The read-only guarantee and primary use case are front-loaded, and each sentence carries information. It is slightly longer than necessary, since the identifier rule is stated twice (once generally, once per-type).

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

Completeness4/5

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

Without an output schema, the description correctly compensates by describing the return value (artifact content as text) and the empty-result case. The remaining gap is handling of error conditions beyond the missing-identifier case, which is minor for a three-parameter read tool.

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

Parameters3/5

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

Schema coverage is 100%, so every parameter and the type enum are already documented. The description's note about identifier being required for PLAYWRIGHT_CODE and ignored otherwise largely restates the schema, though it adds the concrete consequence ('omitting it returns an error'). Baseline 3 is appropriate.

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

Purpose5/5

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

The description opens with a specific verb plus resource ('Retrieve a specific test artifact from a suite') and states the return shape ('content as text'). It is clearly distinguishable from the sibling write tools wopee_generate_artifact and wopee_update_artifact.

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

Usage Guidelines5/5

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

It names explicit use cases — reviewing what wopee_generate_artifact produced and fetching before editing with wopee_update_artifact — and states the read-only nature, so the agent knows when this is the right tool versus the mutation siblings.

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

Deploy Server

Other Tools