MCP tools: Stdio-only tools

Stdio-only tools

The stdio server (goodqa-mcp, apps/mcp/README.md) registers most remote-core tools under the same names plus these. Their parameters are in apps/mcp/src/server.ts.

Tool	Description
`cancel_fix_suggestion`	Cancel a Suggest Fix run you requested that is still queued or running. Use if a request was made in error or is no longer needed. 409 if the run has already finished.
`comment_issue`	Add a comment to an issue. Use to report investigation findings, link a fix commit, ask for clarification, or explain a status change. Reuse operationId (or just repeat the exact same call) after an uncertain response -- an identical retry replays instead of double-posting.
`get_fix_suggestion`	Get a Suggest Fix run's status and, once it has succeeded, its full proposal (hypotheses, affected areas, implementation steps, risks, tests, suggested field values, and citations into the project's indexed sources). Use after request_fix_suggestion to poll for completion, or to review a past proposal.
`get_mission`	Get a mission with its flows, steps, assignees, and current step results. Use before executing a mission to see which steps still need results, and to get the stepId values needed by upsert_step_result.
`get_project_context`	Get the AI context for a project: the accumulated understanding of what the app is, its surfaces, key flows, and risk areas (from interviews and repo scans). Read this BEFORE generating test plans, running missions, or writing issue reports so your output matches the team’s domain language.
`get_test_plan`	Get a test plan including its flows and steps (instructions + expected results). Use when executing or reviewing a plan — the steps tell you exactly what to do and what should happen.
`link_pull_request`	Link a pull request to a GoodQA issue, so the bug records the fix and picks up the customer's CI verdict and preview URL when they arrive. Use after opening a PR that fixes a bug. GoodQA does not need write access to the repository for this. Alternatively, put the issue URL or `goodqa#<number>` in the PR title, body or branch name and it is linked automatically.
`list_attachments`	List the evidence (screenshots, recordings, files) attached to an issue. Use to confirm an upload you made actually landed, or to review evidence someone else attached before triaging.
`list_comments`	List one comment page (default 100, maximum 200) in chronological order; order=desc selects the newest page. hasMore reports remaining pages in that direction; issue.commentCount is the issue total. Follow nextCursor or olderCursor/newerCursor to continue. Optional commentId resolves one canonical source pointer within the existing issue/archive/access rules. Use to read back a thread you just posted into with comment_issue, or to catch up on discussion before acting. For a single one-off issue you can also pass get_issue { include: "comments" } to fetch both in one call.
`list_missions`	List testing missions for a project (title, status, due date). Use to find active testing work — a mission bundles test flows for testers/agents to execute.
`list_notifications`	List the caller's notifications (mentions, assignments, status changes, thank-yous) across every org the key can see, newest first. Pass unread: true to see only what hasn't been marked read. Use to check for new activity without opening the web app.
`list_pull_requests`	The pull requests linked to an issue, each with the customer's CI verdict (pending/success/failure) and preview URL if their pipeline deploys one. Use to check whether a fix actually passed before closing the bug.
`list_test_plans`	List the test plans for a project (name, surface, status). Use to discover what structured testing exists before creating a mission or generating a new plan.
`refine_test_plan`	Ask GoodQA’s AI to revise an existing test plan per your instructions (add/remove/rewrite flows and steps). Use when a plan exists but is missing coverage or has outdated steps. Slow (LLM call).
`request_fix_suggestion`	Ask GoodQA to generate an AI fix proposal for an issue (Suggest Fix). Asynchronous: returns immediately with a queued/running run — poll get_fix_suggestion with the returned runId to see the result. Use when a bug needs triage help or a starting-point diagnosis. Requires Project Intelligence to be configured, enabled, and have indexed content for the project; 409 if not ready or a run is already in progress for this issue.
`upsert_step_result`	Record (or update) the result of executing one test step within a mission. Use as you work through a mission: after performing each step, report passed/failed/blocked/skipped with notes. When a step fails, also file a bug with create_issue.

Stdio-only tools

The stdio server (goodqa-mcp, apps/mcp/README.md) registers most remote-core tools under the same names plus these. Their parameters are in apps/mcp/src/server.ts.

Tool

Description

cancel_fix_suggestion

Cancel a Suggest Fix run you requested that is still queued or running. Use if a request was made in error or is no longer needed. 409 if the run has already finished.

comment_issue

Add a comment to an issue. Use to report investigation findings, link a fix commit, ask for clarification, or explain a status change. Reuse operationId (or just repeat the exact same call) after an uncertain response -- an identical retry replays instead of double-posting.

get_fix_suggestion

Get a Suggest Fix run's status and, once it has succeeded, its full proposal (hypotheses, affected areas, implementation steps, risks, tests, suggested field values, and citations into the project's indexed sources). Use after request_fix_suggestion to poll for completion, or to review a past proposal.

get_mission

Get a mission with its flows, steps, assignees, and current step results. Use before executing a mission to see which steps still need results, and to get the stepId values needed by upsert_step_result.

get_project_context

Get the AI context for a project: the accumulated understanding of what the app is, its surfaces, key flows, and risk areas (from interviews and repo scans). Read this BEFORE generating test plans, running missions, or writing issue reports so your output matches the team’s domain language.

get_test_plan

Get a test plan including its flows and steps (instructions + expected results). Use when executing or reviewing a plan — the steps tell you exactly what to do and what should happen.

link_pull_request

Link a pull request to a GoodQA issue, so the bug records the fix and picks up the customer's CI verdict and preview URL when they arrive. Use after opening a PR that fixes a bug. GoodQA does not need write access to the repository for this. Alternatively, put the issue URL or goodqa#<number> in the PR title, body or branch name and it is linked automatically.

list_attachments

List the evidence (screenshots, recordings, files) attached to an issue. Use to confirm an upload you made actually landed, or to review evidence someone else attached before triaging.

list_comments

List one comment page (default 100, maximum 200) in chronological order; order=desc selects the newest page. hasMore reports remaining pages in that direction; issue.commentCount is the issue total. Follow nextCursor or olderCursor/newerCursor to continue. Optional commentId resolves one canonical source pointer within the existing issue/archive/access rules. Use to read back a thread you just posted into with comment_issue, or to catch up on discussion before acting. For a single one-off issue you can also pass get_issue { include: "comments" } to fetch both in one call.

list_missions

List testing missions for a project (title, status, due date). Use to find active testing work — a mission bundles test flows for testers/agents to execute.

list_notifications

List the caller's notifications (mentions, assignments, status changes, thank-yous) across every org the key can see, newest first. Pass unread: true to see only what hasn't been marked read. Use to check for new activity without opening the web app.

list_pull_requests

The pull requests linked to an issue, each with the customer's CI verdict (pending/success/failure) and preview URL if their pipeline deploys one. Use to check whether a fix actually passed before closing the bug.

list_test_plans

List the test plans for a project (name, surface, status). Use to discover what structured testing exists before creating a mission or generating a new plan.

refine_test_plan

Ask GoodQA’s AI to revise an existing test plan per your instructions (add/remove/rewrite flows and steps). Use when a plan exists but is missing coverage or has outdated steps. Slow (LLM call).

request_fix_suggestion

Ask GoodQA to generate an AI fix proposal for an issue (Suggest Fix). Asynchronous: returns immediately with a queued/running run — poll get_fix_suggestion with the returned runId to see the result. Use when a bug needs triage help or a starting-point diagnosis. Requires Project Intelligence to be configured, enabled, and have indexed content for the project; 409 if not ready or a run is already in progress for this issue.

upsert_step_result

Record (or update) the result of executing one test step within a mission. Use as you work through a mission: after performing each step, report passed/failed/blocked/skipped with notes. When a step fails, also file a bug with create_issue.

MCP tools: Stdio-only tools

All tool groups

Stdio-only tools

The stdio server (goodqa-mcp, apps/mcp/README.md) registers most remote-core tools under the same names plus these. Their parameters are in apps/mcp/src/server.ts.

Tool	Description
`cancel_fix_suggestion`	Cancel a Suggest Fix run you requested that is still queued or running. Use if a request was made in error or is no longer needed. 409 if the run has already finished.
`comment_issue`	Add a comment to an issue. Use to report investigation findings, link a fix commit, ask for clarification, or explain a status change. Reuse operationId (or just repeat the exact same call) after an uncertain response -- an identical retry replays instead of double-posting.
`get_fix_suggestion`	Get a Suggest Fix run's status and, once it has succeeded, its full proposal (hypotheses, affected areas, implementation steps, risks, tests, suggested field values, and citations into the project's indexed sources). Use after request_fix_suggestion to poll for completion, or to review a past proposal.
`get_mission`	Get a mission with its flows, steps, assignees, and current step results. Use before executing a mission to see which steps still need results, and to get the stepId values needed by upsert_step_result.
`get_project_context`	Get the AI context for a project: the accumulated understanding of what the app is, its surfaces, key flows, and risk areas (from interviews and repo scans). Read this BEFORE generating test plans, running missions, or writing issue reports so your output matches the team’s domain language.
`get_test_plan`	Get a test plan including its flows and steps (instructions + expected results). Use when executing or reviewing a plan — the steps tell you exactly what to do and what should happen.
`link_pull_request`	Link a pull request to a GoodQA issue, so the bug records the fix and picks up the customer's CI verdict and preview URL when they arrive. Use after opening a PR that fixes a bug. GoodQA does not need write access to the repository for this. Alternatively, put the issue URL or `goodqa#<number>` in the PR title, body or branch name and it is linked automatically.
`list_attachments`	List the evidence (screenshots, recordings, files) attached to an issue. Use to confirm an upload you made actually landed, or to review evidence someone else attached before triaging.
`list_comments`	List one comment page (default 100, maximum 200) in chronological order; order=desc selects the newest page. hasMore reports remaining pages in that direction; issue.commentCount is the issue total. Follow nextCursor or olderCursor/newerCursor to continue. Optional commentId resolves one canonical source pointer within the existing issue/archive/access rules. Use to read back a thread you just posted into with comment_issue, or to catch up on discussion before acting. For a single one-off issue you can also pass get_issue { include: "comments" } to fetch both in one call.
`list_missions`	List testing missions for a project (title, status, due date). Use to find active testing work — a mission bundles test flows for testers/agents to execute.
`list_notifications`	List the caller's notifications (mentions, assignments, status changes, thank-yous) across every org the key can see, newest first. Pass unread: true to see only what hasn't been marked read. Use to check for new activity without opening the web app.
`list_pull_requests`	The pull requests linked to an issue, each with the customer's CI verdict (pending/success/failure) and preview URL if their pipeline deploys one. Use to check whether a fix actually passed before closing the bug.
`list_test_plans`	List the test plans for a project (name, surface, status). Use to discover what structured testing exists before creating a mission or generating a new plan.
`refine_test_plan`	Ask GoodQA’s AI to revise an existing test plan per your instructions (add/remove/rewrite flows and steps). Use when a plan exists but is missing coverage or has outdated steps. Slow (LLM call).
`request_fix_suggestion`	Ask GoodQA to generate an AI fix proposal for an issue (Suggest Fix). Asynchronous: returns immediately with a queued/running run — poll get_fix_suggestion with the returned runId to see the result. Use when a bug needs triage help or a starting-point diagnosis. Requires Project Intelligence to be configured, enabled, and have indexed content for the project; 409 if not ready or a run is already in progress for this issue.
`upsert_step_result`	Record (or update) the result of executing one test step within a mission. Use as you work through a mission: after performing each step, report passed/failed/blocked/skipped with notes. When a step fails, also file a bug with create_issue.