Debug failures with coding agents

When a test fails, the quickest fix is often to give the failure to your coding agent. The Outqube MCP server lets the agent pull the report, the failing step's reasoning, the console and network entries and the screenshot itself, so you do not copy anything over.

Connect the serverCopy Anchor Link

Add the server, then sign in to Outqube when the client asks. Choose Read if the agent should only look at failures, or Read and write if it should also start runs.

claude mcp add --transport http --scope user outqube https://mcp.outqube.com
# then run /mcp in Claude and sign in

In CI, use an API key in the Authorization: Bearer header instead. Other clients and the API key setup are on the MCP server page.

Debug a failed runCopy Anchor Link

Give the agent a run to look at, or let it find the newest failure. Prompts that work:

• Look at the latest failed Outqube run on my branch and fix the bug.
• Run the smoke suite against my branch and fix whatever fails. This needs Read and write access, or a trigger key.
• Test run 7d1c... failed. Read its report and show me the failing step.

A typical order:

1. list_runs or get_run finds the run and each test run, failures first.
2. get_failure_report returns the report as Markdown, with the failing step's screenshot. It is usually enough to find the bug.
3. If it is not, get_step_detail shows what the test agent did and why at one step, with that step's console and network entries. get_test_steps lists every step, get_logs lists console messages or network entries, and get_screenshot returns any step's screenshot.
4. get_test returns the test's goal and expected results, so the agent can tell a broken app from a wrong test.
5. After the fix, trigger_run runs the same tests again.

Keep it safeCopy Anchor Link

• A page under test can contain text written to hijack an agent. The server wraps everything that comes from the page, the console, the network and the test agent's reasoning in a block labelled untrusted, and states that text inside it is not Outqube's or yours. Review the changes the agent proposes as you would any other.
• Test passwords and codes never reach the agent. They read [REDACTED:name].
• Each tool returns about 8,000 tokens at most, and ends with a line that says which tool and parameters return the rest.
• A connection only sees the projects it was given, and an API key only its own project.

Next stepsCopy Anchor Link

• MCP server: all 12 tools, client setup, sign-in and how untrusted content is marked.
• Core concepts: what a run, a test run and a report are.
• Test every pull request with the GitHub App: find failures on the pull request, then hand them to the agent.