Skip to main content
Glama
Wopee-io

wopee-mcp

Official
by Wopee-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create GitHub issue

wopee_create_github_issue

Create GitHub issues to report bugs found during testing or track test failures. For failed tests, include run evidence by providing the executed test case UUID.

Instructions

Create a new GitHub issue in the project's connected repository. Use this to report bugs found during testing, track test failures, or create action items from chat discussions. For a failed test, pass its executedTestCaseUuid so the issue carries the run's evidence (failing step, expected vs actual, screenshot, report link). The issue is created by the Wopee.io GitHub App and names the requester in its body. Requires a GitHub repository linked to the project and WOPEE_PROJECT_UUID to be set.

Input Schema

NameRequiredDescriptionDefault
bodyNoThe body/description of the GitHub issue (supports Markdown). Kept verbatim, above anything Wopee.io adds from the test run.
titleYesThe title of the GitHub issue
labelsNoOptional labels to apply to the issue (e.g., ['bug', 'testing'])
executedTestCaseUuidNoUUID of the executed test case the issue is about (the executedTestCaseUuid shown by wopee_fetch_recent_executions and wopee_dispatch_agent, or uuid in wopee_fetch_executed_test_cases). When set, Wopee.io adds the failing step, expected vs actual, the failing step's screenshot and a link to the run in Commander, so the body only needs your own analysis.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.31.0
    • changedInput schema / properties / body / description
      Previous value: -"The body/description of the GitHub issue (supports Markdown)"New value: +"The body/description of the GitHub issue (supports Markdown). Kept verbatim, above anything Wopee.io adds from the test run."
    • addedInput schema / properties / executedTestCaseUuid
      Added value: +{
+  "description": "UUID of the executed test case the issue is about (the executedTestCaseUuid shown by wopee_fetch_recent_executions and wopee_dispatch_agent, or uuid in wopee_fetch_executed_test_cases). When set, Wopee.io adds the failing step, expected vs actual, the failing step's screenshot and a link to the run in Commander, so the body only needs your own analysis.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "title",
-  "body"
-]New value: +[
+  "title"
+]
  2. Addedv1.26.1

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full load, and it does disclose meaningful behavior: the issue is created by the Wopee.io GitHub App, the requester is named in the body, and run evidence is auto-appended when executedTestCaseUuid is set. It also states prerequisites (linked repo, WOPEE_PROJECT_UUID), though it omits error/failure behavior.

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 purpose, then usage, then the key parameter behavior, then prerequisites. Each sentence adds a distinct piece of information with no filler.

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 mutation tool with no annotations and no output schema, it covers prerequisites, side effects, and the special evidence-attachment behavior adequately. It leaves return/failure behavior unexplained, which is a minor gap.

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 the baseline is 3. The description restates that executedTestCaseUuid triggers evidence attachment and that the body is kept verbatim, but these are already documented in the schema, so it adds little beyond the structured fields.

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+resource ('Create a new GitHub issue') scoped to 'the project's connected repository.' No sibling tool overlaps with issue creation, so the agent can distinguish it immediately.

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?

Gives three concrete use cases (report bugs, track test failures, create action items from chat) and a conditional rule for when to pass executedTestCaseUuid. It doesn't name an alternative tool or an explicit when-not, but the trigger conditions are clear.

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