Skip to main content
Glama

get_debug_evidence

Retrieve comprehensive failure evidence for a failing test: flake verdict, failure signatures, regression boundary, and downloadable artifacts like traces and screenshots in one call.

Instructions

Start every failing-test investigation here. One call returns the whole cheap tier of the evidence ladder: the computed flake verdict with its per-attempt failure signatures, the regression boundary (the last run this test passed and the first it failed), and download links for every stored artifact — trace, screenshots, and the expected/actual/diff images on a visual failure. Read all of it before forming a hypothesis. The verdict says whether the failure repeats, never why, so it rules fixes out rather than pointing at a cause; the boundary turns "why does this fail" into "what changed between these two runs", which is a far smaller question. Artifact links are minutes-scale: download what you need immediately, and call this again to mint fresh ones rather than treating an expired link as a missing artifact.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNoResponse shape. "md" is markdown, and markedly cheaper for the same content.
maxLengthNoCap the markdown length. Applies to format="md" only; anything cut is announced in the output. JSON is never truncated, because a cut payload would not parse and would read as a complete one.
projectIdYesProject ID (e.g. project_<id>)
testrun_idNoRun scope. Omit to use the most recently started run carrying this case.
testcase_idNoThe case's pw_test_id.
testcase_nameNoFull test title. Required for the regression boundary — prefer it when known.
suite_file_pathNoSpec file path — only needed when the title is shared across files.
include_instructionsNoDefault true. The procedure and the trace runbook are identical on every call and about half the response — set false on repeat calls once you have read them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.3

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses the verdict's limit ('never why'), reframes the regression boundary, and warns that artifact links are minutes-scale and must be re-minted rather than treated as missing artifacts. This is substantive behavioral disclosure.

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 dense but every sentence earns its place: when to use, what it returns, what the verdict cannot explain, what the boundary provides, and how to handle expiring artifact links. The action directive is front-loaded.

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 complex 8-parameter tool with no output schema and no annotations, the description covers the key operational facts: output contents, limitation of the verdict, artifact link expiry, and parameter guidance. An agent can invoke it correctly and interpret its results without additional lookups.

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%, so the baseline is 3, but the description adds real value: testcase_name is required for the regression boundary, include_instructions is identical and about half the response, md is markedly cheaper, and maxLength/truncation behavior is contextualized. This exceeds schema-only understanding.

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 opens with a specific directive — 'Start every failing-test investigation here' — and lists the concrete deliverables: computed flake verdict with per-attempt failure signatures, regression boundary, and artifact download links. This makes the tool's role distinct from generic detail/debug siblings.

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?

It explicitly tells the agent when to use the tool ('Start every failing-test investigation here') and to read all output before forming a hypothesis. It doesn't name sibling alternatives or state when not to use it, so it stops 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.