Skip to main content
Glama
Sign In
TestDino MCP

TestDino MCP

by testdino-hq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Debug Evidence

get_debug_evidence
Read-only

Start failing-test investigations by returning the flake verdict, per-attempt failure signatures, regression boundary, and artifact links for traces, screenshots, and visual diffs 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

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 — exact, so prefer it when known.
testcase_nameNoFull test title. Give this or testcase_id.
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. Changed5 schema fields changedv2.2.0
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / maxLength / exclusiveMinimum
      Added value: +0
    • changedInput schema / properties / testcase_id / description
      Previous value: -"The case's pw_test_id."New value: +"The case's pw_test_id — exact, so prefer it when known."
    • changedInput schema / properties / testcase_name / description
      Previous value: -"Full test title. Required for the regression boundary — prefer it when known."New value: +"Full test title. Give this or testcase_id."
  2. Addedv2.0.3

TDQS

A4.5/5.0
Behavior5/5

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

The readOnlyHint annotation only tells the agent the tool is safe to call. The description adds substantial behavioral context beyond that: the verdict says whether a failure repeats but never why, so it rules out fixes rather than pointing at a cause; the boundary reframes the question as 'what changed between these two runs'; artifact links expire on a minutes scale, so agents should download immediately and call again for fresh links rather than treating expiry as missing artifacts.

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 front-loaded with the most important guidance ('Start every failing-test investigation here'), followed by a tight enumeration of returns and behavioral caveats. Every sentence earns its place: none repeat the schema or annotations, and each adds actionable context for an agent.

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?

With no output schema, the description carries the burden of explaining what the tool returns, and it does so completely: verdict, failure signatures, regression boundary, and artifact links. It also discloses key constraints (verdict limits, boundary utility, link expiry) that an agent needs to use the tool correctly, making it sufficient for this complex, eight-parameter tool.

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 schema itself fully documents all eight parameters, including enums and format trade-offs. The description does not add per-parameter meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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 uses a specific verb-plus-resource framing ('One call returns the whole cheap tier of the evidence ladder') and enumerates exactly what the tool returns: flake verdict, per-attempt signatures, regression boundary, and artifact links. It also positions itself as the entry point for failing-test investigations, which clearly distinguishes it from siblings like get_flake_verdict or get_trace_analysis that return narrower slices.

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?

Strong guidance is given: 'Start every failing-test investigation here' and 'Read all of it before forming a hypothesis.' It also explains when to call again ('call this again to mint fresh ones'), which is a useful workflow cue. However, it does not explicitly name alternatives or when-not-to-use this tool, so a 4 rather than 5.

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