# Goose MCP: Debug From Recorded Bug Evidence

_2026-11-05 • 10 min read • By clip.qa team_

**Category:** Engineering

**Keywords:** Goose MCP; describe bugs to ai concisely; llm bug reporting; agentic qa

---

## Overview

Goose MCP can give an agent access to clip.qa reports, report details, screenshots, transcripts, and other captured evidence. clip.qa records screen bugs on iOS, Android, and Chrome, but its capture clients are still beta and require request access.

---

## Introduction

<p>Goose MCP can give an agent access to clip.qa reports, report details, screenshots, transcripts, and other captured evidence. clip.qa records screen bugs on iOS, Android, and Chrome, but its capture clients are still beta and require request access.</p>

## What evidence can Goose MCP access?

Analysis happens in clip.qa’s cloud and produces a draft report that a human reviews. It does not guarantee accurate diagnosis or an autonomous fix, and a local Goose session does not move that analysis onto your machine. Reports remain private until you explicitly share them.
Use this connection for evidence retrieval, not blind execution. A useful Goose workflow begins with a report identifier, confirms that the report belongs to the current task, and distinguishes observed behavior from an unconfirmed root-cause hypothesis.
The remote clip.qa MCP endpoint uses OAuth 2.1 with PKCE. Its remote tools include listReports, getDetails, getScreenshots, getVideoTranscript, getNetworkRequests, getConsoleLogs, getReportDiff, createComment, linkFix, and linkFixAttempt. Read-only retrieval should be configured before any operation that writes comments or links fixes.
Goose itself is an open source agent available as a desktop application, CLI, and API. It runs on your local machine, while selected models or providers may send information to remote services. It is now part of AAIF. Do not interpret local execution as an offline guarantee or as proof that clip.qa analysis is local.
For browser bugs, a browser extension can capture console and network data. For native mobile apps, that does not mean you can obtain phone console logs or network traffic through clip.qa. Mobile context also varies: iOS telemetry can be limited while the target app is in the foreground. A mobile report may therefore contain captured visuals and context without native traffic evidence.
This boundary matters when Goose sees a failure involving a background return. Suppose a user taps a notification, returns to the app, and finds that a draft message has disappeared. The recording can establish the visible sequence; it cannot by itself prove whether the app discarded state, restored stale state, or received a failed server response.
Before asking Goose to investigate, label those possibilities as hypotheses. The mobile bug reporting without SDK guide explains how capture works without installing an SDK into the tested app, while LLM-ready bug reports covers structuring evidence for analysis.

## How do I configure the clip.qa extension?

Add clip.qa as a custom remote Streamable HTTP extension in Goose. The documented configuration file is ~/.config/goose/config.yaml.
Start with this minimal configuration:
extensions:
  clipqa:
    name: clip.qa
    type: streamable_http
    uri: https://mcp.clip.qa/mcp
    enabled: true
    timeout: 300
Start with read-only tool approvals. Configure comment and fix-linking tools separately only when you understand their effects and the task requires them.
Goose documents custom remote Streamable HTTP extensions and OAuth discovery; clip.qa supports Dynamic Client Registration (DCR), so use its documented flow rather than inventing a client secret (Goose extensions guide; clip.qa MCP).
After saving the configuration, restart Goose or open a new session so extension discovery runs again. Confirm that the clip.qa tools appear, then request one known report. A known-good identifier gives you a controlled check: it verifies authentication, retrieval, and your ability to interpret the returned evidence without starting a broad debugging task.
Check Goose’s configured permission mode before investigative steps; approval behavior can vary by installation (Goose documentation).
The clip.qa MCP documentation describes the remote tool set and OAuth model. This is a documentation-based setup, not an end-to-end integration test. Your installed Goose version, OAuth flow, and local configuration may differ, so verify discovery rather than treating these steps as proof of connection.
Also review Goose’s model and provider configuration before sending report content. Local tooling does not make every inference local. Remove credentials, personal data, and unrelated production payloads before including any evidence in a prompt or repository task.

## How should I retrieve and review a report?

Retrieve one report at a time and establish an evidence ledger. Record the report ID, exact symptom, environment, reproduction steps, expected result, actual result, and attachment types.
A practical first request is:
Retrieve report REPORT_ID using the clip.qa MCP read tools. Return:
1. exact reproduction steps;
2. expected and observed behavior;
3. relevant screenshots and transcript excerpts;
4. available device, OS, browser, and app context;
5. absent evidence, especially mobile console or network data;
6. a root-cause hypothesis clearly labeled as unconfirmed.
Do not modify the report or propose that a fix succeeded.
This prompt keeps retrieval separate from diagnosis. It also follows the principle in how to describe a bug to AI: precise observations make it easier for an agent to test a hypothesis instead of merely repeating a summary.
For the hypothetical notification example, the evidence ledger might say:

Trigger: open app from notification after ten minutes in background.
Expected: draft message remains visible and editable.
Observed: draft screen is empty after return.
Available: screen recording, screenshots, narration, and limited iOS telemetry while another app is foregrounded.
Missing: native app console log, network request, server response, and state-snapshot evidence.

Do not ask Goose to “fix the missing draft” from those facts alone. First inspect repository code for state restoration, lifecycle handling, draft persistence, and notification routing. The report can prioritize code paths; it cannot replace a source-level investigation.
Use getReportDiff only when comparing two reports has a defined purpose. It can help reveal changed evidence, but a difference does not itself establish causality. Likewise, never infer mobile console or network content from a screenshot.

## How do I turn evidence into a debugging task?

Turn the reviewed report into a task with a bounded scope, explicit acceptance checks, and a requirement to preserve uncertainty until code inspection proves otherwise.

Write the observed outcome. State what the user sees, including the empty draft screen in the example, without embedding the unconfirmed cause.
List exact reproduction steps. Include the background interval, notification action, app version, and device context if known.
Define affected surfaces. Name likely code areas only as search targets, such as lifecycle restoration, notification routing, or draft storage.
Require a hypothesis check. Ask Goose to identify evidence for and against at least two possible causes before editing.
Set acceptance criteria. Verify that the message survives background return, remains editable, and is restored after a real lifecycle transition.
Protect the change. Add or update a focused regression test before generalizing the fix.
Record the outcome. Save a fix-attempt log with the commit or PR and status pending, succeeded, or failed.

Do not mark an attempt succeeded merely because Goose edited code or tests passed in the agent’s repository tooling. clip.qa does not run those tests. Success requires an original-environment retest that reproduces the original steps and confirms the expected outcome.
Keep the task concise. A good instruction might be:
Investigate the missing draft after returning from the background.
Observed evidence: the captured report shows an empty draft screen after notification return.
Treat discarded state, stale restoration, and a failed persistence request as hypotheses.
Trace the relevant lifecycle and draft-restoration paths, add a regression test matching the
reported transition, and run the repository's focused tests. Report changed files, test
results, remaining uncertainty, and a commit or PR. Do not mark the fix succeeded until the
original environment has been retested.
If Goose needs to write back to clip.qa, configure those write-capable tools separately from read access. createComment can record an observation; linkFix and linkFixAttempt can associate repository work with the report. The fix-attempt log still needs the actual commit or PR and one of the three documented outcomes.

## What should I check before trusting a fix?

Validate in layers. First confirm that the code change addresses an observed mechanism rather than only matching the report’s wording. Then run the focused test in the agent’s repository tooling, including a fixture that exercises the exact transition.
Next, reproduce in the original environment. For the mobile example, return from background through the same notification path, reopen the draft, edit it, and repeat the transition after saving. A desktop unit test is useful but not equivalent to mobile lifecycle behavior.
Compare evidence before and after the change. getReportDiff can help organize the comparison, but human review must confirm that the new capture reflects the same device, app build, and reproduction sequence.
Check failure cases too: stale drafts, interrupted writes, duplicate notifications, process termination, and partial restoration. The screen recording to bug report workflow can help produce comparable evidence after the retest.
Keep secrets out of prompts, source files, and reports. Use least-privilege read access first, scrub personal information, and avoid pasting authorization headers or tokens into agent context. Tool availability does not justify broad permissions.
If evidence is incomplete, say so. A report that proves “the draft screen is empty” is still valuable even when it does not prove why. Accurate uncertainty is more useful to a coding workflow than a polished but unsupported diagnosis.
Sign up free to capture evidence for a grounded debugging task.

## Sources


Goose documentation — Confirms Goose’s open source desktop, CLI, and API surfaces, local execution model, possible remote model providers, and AAIF project context. Checked 2026-11-05.
Goose extensions guide — Confirms MCP extensions, developer tools, custom remote Streamable HTTP configuration, YAML location and fields, and OAuth discovery behavior. Checked 2026-11-05.


## Key Takeaways

- Analysis happens in clip.qa’s cloud and produces a draft report that a human reviews.
- Add clip.qa as a custom remote Streamable HTTP extension in Goose.
- Retrieve one report at a time and establish an evidence ledger.
- Turn the reviewed report into a task with a bounded scope, explicit acceptance checks, and a requirement to preserve uncertainty until code inspection proves otherwise.

## Frequently Asked Questions

**Q: What is Goose MCP used for in a bug-report workflow?**

Goose MCP lets Goose retrieve and, when configured, update clip.qa bug reports through remote tools. The connection supplies captured evidence to an agent while preserving human review of clip.qa’s draft analysis.

**Q: Does clip.qa analyze bugs locally when used with Goose?**

No. clip.qa’s cloud analysis produces a draft report that a human reviews. Goose may run locally, but selected model or provider operations can still be remote, and a local Goose session does not make clip.qa analysis local.

**Q: Can clip.qa capture console logs from native mobile apps?**

No general native-app console or network capture should be assumed. A browser extension can capture browser console and network data, while mobile reports vary by platform and may have limited iOS telemetry while another app is foregrounded.

**Q: How should I begin with the Goose MCP configuration?**

Add the remote Streamable HTTP endpoint to ~/.config/goose/config.yaml , enable the extension, restart or open a new session, and retrieve one known report. Use a review or approval mode for consequential actions and avoid pre-registering an OAuth secret that the supported flow does not require.

**Q: Does a passing repository test prove a clip.qa fix succeeded?**

No. clip.qa does not run tests in the agent’s repository. A fix-attempt log stays pending until an original-environment retest confirms the outcome; repository test results and a commit or PR are still required evidence.

## Related Posts

- [Read more](/blog/how-to-describe-bug-to-ai)
- [Read more](/blog/llm-ready-bug-reports)
- [Read more](/blog/mobile-bug-reporting-without-sdk)
- [Read more](/blog/screen-recording-to-bug-report)