wopee-mcp
OfficialServer Quality Checklist
- Disambiguation5/5
Each tool targets a distinct phase of the testing lifecycle with explicit cross-references preventing confusion between similar operations. Descriptions clearly distinguish dispatch_agent (test execution) from dispatch_analysis (web crawling), and fetch_artifact (content) from fetch_executed_test_cases (results), leaving no ambiguity about which tool to use.
Naming Consistency5/5All eight tools follow a strict wopee_verb_noun snake_case pattern with predictable action verbs (create, dispatch, fetch, generate, update). The consistent prefix and grammatical structure make it immediately obvious what each tool does and how they relate to one another.
Tool Count5/5Eight tools provide appropriate granularity for an AI-powered testing platform, covering suite management, artifact lifecycle (generate/fetch/update), and test execution without excessive fragmentation. The scope is well-contained and matches the complexity of the domain.
Completeness4/5The surface covers core CRUD operations for test artifacts and suite creation/listing, supporting the full workflow from blank suite to executed tests. Minor gaps exist in deletion capabilities (no delete_suite or delete_artifact) and single-resource retrieval requires filtering the list, but these do not block primary use cases.
Average 4.7/5 across 8 of 8 tools scored.
See the tool scores section below for per-tool breakdowns.
This repository includes a README.md file.
This repository includes a LICENSE file.
Latest release: v1.0.1
Tools from this server were used 5 times in the last 30 days.
This repository includes a glama.json configuration file.
- This server provides 8 tools. View schema
No known security issues or vulnerabilities reported.
This server has been verified by its author.
Tool Scores
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. Effectively reveals: async behavior ('returns confirmation that generation started' implying background processing), destructive potential ('overwrites the previous version'), and quality constraints (order dependency affects output quality). Missing only minor details like rate limits or exact error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly structured and front-loaded. Every sentence earns its place: purpose first, usage pattern (multiple calls), ordering constraints, success behavior, sibling references, and overwrite warning. No redundancy or filler despite covering complex workflow dependencies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Excellent coverage for a generation tool without output schema. Explains return value ('confirmation that generation started'), side effects (overwrite behavior), and full workflow integration (fetch_artifact for retrieval). Only minor gap is lack of error state descriptions or timing estimates for generation completion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline applies. Description loosely references the type parameter ('Each call creates one artifact type') but adds no syntax, format, or constraint details beyond what the schema already documents for the 'type' and 'suiteUuid' parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: 'Generate AI-powered test artifacts' provides clear verb and resource. Explicitly distinguishes from siblings by stating 'Do NOT use this to update existing artifacts — use wopee_update_artifact instead' and directing users to 'wopee_fetch_artifact' for retrieval, clearly delineating the create/update/read separation in the tool suite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Outstanding guidance: explicitly states when-not to use ('Do NOT use this to update'), names the correct alternative ('use wopee_update_artifact instead'), and details critical workflow dependencies ('APP_CONTEXT must be generated before user stories, and user stories before test cases'). Also specifies the async retrieval pattern requiring wopee_fetch_artifact.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and discloses side effects ('creates execution records and screenshots'), rate limiting ('10 seconds between dispatches'), and retry behavior ('concurrent calls auto-retry with exponential backoff'). Could more explicitly categorize the write/modification nature but implies it through 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense with logical flow covering execution mechanism, prerequisites, exclusions, side effects, rate limits, and return handling. Despite length, every sentence provides actionable guidance with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Thoroughly complete for a complex dispatch tool with no output schema. Covers preconditions, error conditions ('invalid suite/test case ID'), side effects, rate limiting, and post-execution workflow integration. Describes return values adequately given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage. The description adds workflow semantics beyond the schema by clarifying relationships between parameters (test cases belong to suites/user stories) and valid input states through the prerequisite section.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ('Execute a specific test case by dispatching an autonomous AI agent') and clearly distinguishes from sibling tool wopee_dispatch_analysis ('Do NOT use this to analyze or crawl an app — use wopee_dispatch_analysis'). Also references prerequisite tool wopee_generate_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite workflow ('generate them first with wopee_generate_artifact'), explicit alternative for different use cases ('use wopee_dispatch_analysis for that'), and explicit follow-up action ('Use wopee_fetch_executed_test_cases afterward').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses non-idempotency ('each call creates a new suite'), implicit dependency ('uses WOPEE_PROJECT_UUID from environment'), failure condition ('Fails if WOPEE_PROJECT_UUID is not configured'), and return structure ('suite object with UUID, name, type, and status').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences covering purpose, workflow dependencies, alternative tools, and behavioral constraints. No redundant information; every clause provides actionable guidance. Well front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description compensates by detailing return fields (UUID, name, type, status). Given 0 parameters and no annotations, it adequately covers prerequisites, failure modes, and sibling relationships necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters (baseline 4). Description adds value by clarifying the implicit input mechanism ('uses WOPEE_PROJECT_UUID from environment') rather than leaving the agent to wonder how project context is determined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb ('Create') + resource ('empty analysis suite') + scope ('current project'). It explicitly distinguishes from sibling tool wopee_dispatch_analysis by contrasting manual suite building vs. auto-analysis workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('first step when you want to manually build a test suite'), names specific dependent tools requiring the returned UUID (wopee_generate_artifact, etc.), and offers clear alternative ('use wopee_dispatch_analysis which creates and populates a suite in one step').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description carries full burden and discloses 'Read-only: does not trigger any execution', explains return behavior ('Returns an empty array if no test cases have been executed'), and documents the polling pattern for async operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose front-loaded, workflow guidance in the middle, and exclusions at the end. Every sentence provides unique value—no repetition of schema details or tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Compensates effectively for missing output schema by detailing return structure (status values IN_PROGRESS/FINISHED/FAILED, agent report, code report) and edge cases (empty array), providing complete workflow context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, description adds valuable context: example analysis identifier format ('A068') and discovery guidance ('found in suite data'), reinforcing where to obtain this optional parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb 'Retrieve' and clear resource 'results of test cases executed by the autonomous agent'. It distinguishes from sibling wopee_fetch_artifact by explicitly stating this is for execution results, not artifacts like user stories or code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit sequencing ('Use this after wopee_dispatch_agent'), polling instructions ('if status is IN_PROGRESS, wait and call again'), and clear alternative tool reference ('Do NOT use this... use wopee_fetch_artifact for that').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully compensates. Discloses idempotency ('Not idempotent'), specific side effects ('creates a suite and execution records'), rate limits ('10 seconds between dispatches'), retry behavior ('concurrent calls auto-retry with exponential backoff'), and return value ('Returns the created suite object'). Exceptional behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense and well-structured: purpose → usage context → sibling alternative → parameters → side effects/idempotency → rate limits → return value. Slightly verbose but every sentence earns its place by conveying critical behavioral or usage information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Thorough coverage for a complex mutating tool. No output schema exists, but description explicitly states what returns ('created suite object'). Covers resource creation, platform state changes, timing constraints, and retry policies—sufficient for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage (baseline 3). Description adds semantic interpretation: maps additionalInstructions to 'free-text instructions' and additionalVariables to 'custom variables', 'starting URL', 'login credentials', and 'cookie preferences' (including specific enum-like values ACCEPT_ALL/DECLINE_ALL/IGNORE). This contextualizes how to populate the generic parameter structures despite schema being fully described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific action: 'Create a new analysis suite AND dispatch an AI crawling agent in one step.' Distinguishes from sibling wopee_create_blank_suite by contrasting auto-analysis vs manual population. Describes mechanism (real browser, navigation, discovery) precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use: 'Use this when you want to auto-analyze a web app.' Explicit alternative named: 'Use wopee_create_blank_suite instead if you want to manually populate the suite.' Clear guidance on choice between automation and manual workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Excellently discloses: safety profile ('Read-only'), external dependency ('uses WOPEE_PROJECT_UUID from environment'), return structure ('array of suite objects with UUIDs, names, types...'), empty state behavior ('Returns an empty array'), and failure condition ('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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences covering purpose, return values, usage guidelines, and operational constraints. No redundant words. Front-loaded with the core action ('List all analysis suites'), followed by return details, usage context, and finally technical constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and no annotations, description fully compensates by detailing the return object structure (UUIDs, names, types, statuses), enumerating specific enum values (ANALYSIS, AGENT, IDLE, IN_PROGRESS, FINISHED), and covering edge cases (empty array, missing env var). Complete for a zero-parameter discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters (baseline 4). Description adds essential context that the tool 'Takes no input; uses WOPEE_PROJECT_UUID from environment,' explaining the implicit configuration dependency not captured in the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb ('List') and resource ('analysis suites'). Explicitly distinguishes from sibling tools by stating it discovers suites needed for wopee_generate_artifact, wopee_fetch_artifact, wopee_update_artifact, and wopee_dispatch_agent, establishing its role as a prerequisite discovery tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('discover existing suites before calling other tools') and names four specific sibling tools that require the UUIDs returned by this tool. Also clarifies what it does NOT do ('does not create or modify anything'), distinguishing it from wopee_create_blank_suite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses 'Returns the artifact content as text', 'returns an empty result' for missing artifacts, and validation failure behavior ('omitting it returns an error'). Explicitly declares read-only nature compensating for missing safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences each earning their place: (1) Core operation, (2) Return format, (3) Usage context with siblings, (4) Safety declaration, (5) Parameter validation rules & edge cases. Front-loaded with purpose, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately covers return values ('text', 'empty result'), parameter interdependencies (type/identifier coupling), sibling workflows, and read-only safety. Sufficient for a 3-parameter fetch tool with conditional validation logic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions (baseline 3). Description adds value by clarifying runtime behavior: identifier causes an error if omitted for PLAYWRIGHT_CODE, and is explicitly 'ignored' for other types—nuances beyond the schema's static 'Required only when' declaration. Adds concrete example 'US004:TC006'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Retrieve' + resource 'test artifact' + scope 'from a suite'. Explicitly references siblings 'wopee_generate_artifact' and 'wopee_update_artifact', clearly positioning this as the read counterpart to those mutating operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use this to review what wopee_generate_artifact created, or to retrieve existing artifacts before editing with wopee_update_artifact.' Also explicitly states read-only safety with 'Does NOT modify any data'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It states the destructive nature ('destructive overwrite — full content is replaced, not patched'), idempotency guarantees, and specific failure modes (invalid UUID, missing artifact). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Six sentences, each earning its place: purpose, destructive nature, when-to-use, when-not-to-use/prerequisites, return behavior, idempotency. No redundancy despite covering complex behavioral and procedural requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation tool with no annotations and no output schema, the description is remarkably complete. It covers prerequisites, sibling tool relationships, success/failure return patterns, and destructive side-effects that would normally require annotation hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. The description adds workflow context that explains parameter relationships: suiteUuid comes from prior fetching, content requires full replacement (not diff), and maps artifact types (USER_STORIES, PLAYWRIGHT_CODE) to use cases ('fix incorrect user stories', 'edit generated Playwright code').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Replace' with resource 'test artifact' and scope 'in a suite'. It explicitly distinguishes from sibling wopee_generate_artifact by stating this is for existing artifacts only, not creating new ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('after reviewing artifacts with wopee_fetch_artifact'), when-not-to-use ('Do NOT use this to create new artifacts'), prerequisite ('artifact must already exist'), and names the correct alternative tool ('use wopee_generate_artifact instead').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
How to claim the server?
If you are the author of the server, you simply need to authenticate using GitHub.
However, if the MCP server belongs to an organization, you need to first add glama.json to the root of your repository.
{
"$schema": "https://glama.ai/mcp/schemas/server.json",
"maintainers": [
"your-github-username"
]
}Then, authenticate using GitHub.
Browse examples.
How to make a release?
A "release" on Glama is not the same as a GitHub release. To create a Glama release:
- Claim the server if you haven't already.
- Go to the Dockerfile admin page, configure the build spec, and click Deploy.
- Once the build test succeeds, click Make Release, enter a version, and publish.
This process allows Glama to run security checks on your server and enables users to deploy it.
How to add a LICENSE?
Please follow the instructions in the GitHub documentation.
Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear on the server after some time, you can manually trigger a new scan using the MCP server admin interface.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Latest Blog Posts
MCP directory API
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