wopee-mcp

Official

by Wopee-io

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.30.0
Disambiguation4/5
Most 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.6/5 across 15 of 15 tools scored. Lowest: 4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on August 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

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.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
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 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.
Conciseness5/5
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.
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 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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

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:

[![wopee-mcp MCP server](https://glama.ai/mcp/servers/Wopee-io/wopee-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Wopee-io/wopee-mcp)

Score Badge

Copy to your README.md:

[![wopee-mcp MCP server](https://glama.ai/mcp/servers/Wopee-io/wopee-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Wopee-io/wopee-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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