Skip to main content
Glama
testdino-hq

TestDino MCP

by testdino-hq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Debug Test Case

debug_testcase
Read-only

Investigate why a test fails or is flaky to identify root cause using historical execution data, failure patterns, error messages, and AI fix suggestions.

Instructions

AI-assisted root cause analysis for a failing or flaky test. Returns historical execution data, aggregated failure patterns (error types, frequency, browsers affected), common error messages, and a debugging_prompt field. If you are debugging a failing test, call get_debug_evidence first: it already carries the debugging_prompt, the verdict and the artifact links. Come here afterwards only for the stored AI suggestions or the full execution history. IMPORTANT: always read the debugging_prompt field in the response — it contains pre-formatted analysis instructions curated for this specific test. Treat it as your analysis context before drawing conclusions. Any fixes you produce from this analysis are recommendations only — validate them against the live code before applying. Use this when the user asks "why is test X failing?", "debug test X", or "is test X flaky?". Identify the test by testcase_id (its pw_test_id, exact) or testcase_name (its title). A title can match several tests (the same test under several Playwright projects, or the same title in several files): pair it with suite_file_path, and if the response is 409 AMBIGUOUS_IDENTITY, its candidates name the Playwright project of each — call again with testcase_id set to the pw_test_id of the one you mean. Set include_ai_insights=true to also get TestDino's stored AI analysis for this test under ai_fixes: recommendations (investigation/remediation steps + reasoning + historical insight) and quick fixes (concrete fixes, often with code snippets, plus long-term stabilization steps). By default they target the most recent failing execution; pass testrun_id to target a specific run. AI payloads are generated lazily — if ai_fixes sections report status "in_progress", poll get_ai_insights(testrun_id=..., testcase_id=...) until they report "completed". An "unavailable" section carries the upstream statusCode: a 5xx or timeout is transient (retry once via get_ai_insights); a 4xx (bad ids) is terminal. Workflow: this returns the long history across runs. If you are diagnosing a failure rather than surveying a pattern, get_debug_evidence is the first call — it returns this history alongside the verdict, the regression boundary and every artifact link, so starting here costs extra round trips for the same evidence.

Input Schema

NameRequiredDescriptionDefault
projectIdYesProject ID
testrun_idNoOnly with include_ai_insights: fetch the AI analysis for this specific run instead of the most recent failure.
testcase_idNoThe test's pw_test_id — exact, never ambiguous. Wins over testcase_name and suite_file_path.
testcase_nameNoTest case name / title to debug. Required unless testcase_id is given.
suite_file_pathNoOptional spec file path — disambiguates when several tests share the same title. Example: "tests/checkout.spec.ts".
include_ai_insightsNoAttach AI recommendations + quick fixes for this test under `ai_fixes` (targets the most recent failing execution unless testrun_id is set).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv2.2.0
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / include_ai_insights / description
      Previous value: -"Attach AI recommendations + quick fixes for this test under `ai_fixes` (targets the most recent failing execution unless testrun_id is set). If a section reports `in_progress`, poll get_ai_insights(testrun_id=..., testcase_id=...) instead of re-calling this tool."New value: +"Attach AI recommendations + quick fixes for this test under `ai_fixes` (targets the most recent failing execution unless testrun_id is set)."
    • changedInput schema / properties / projectId / description
      Previous value: -"Project ID (Required). The TestDino project identifier."New value: +"Project ID"
    • changedInput schema / properties / suite_file_path / description
      Previous value: -"Optional spec file path to disambiguate when several tests share the same title. Example: 'tests/checkout.spec.ts'."New value: +"Optional spec file path — disambiguates when several tests share the same title. Example: \"tests/checkout.spec.ts\"."
    • addedInput schema / properties / testcase_id
      Added value: +{
+  "description": "The test's pw_test_id — exact, never ambiguous. Wins over testcase_name and suite_file_path.",
+  "type": "string"
+}
    • changedInput schema / properties / testcase_name / description
      Previous value: -"Test case name/title to debug (Required). Example: 'Verify user can logout and login'."New value: +"Test case name / title to debug. Required unless testcase_id is given."
    • changedInput schema / properties / testrun_id / description
      Previous value: -"Only with include_ai_insights: target the AI fixes at this specific run instead of the most recent failure."New value: +"Only with include_ai_insights: fetch the AI analysis for this specific run instead of the most recent failure."
    • changedInput schema / required
      Previous value: -[
-  "projectId",
-  "testcase_name"
-]New value: +[
+  "projectId"
+]
  2. Changed3 schema fields changedv2.0.2
    • addedInput schema / properties / include_ai_insights
      Added value: +{
+  "description": "Attach AI recommendations + quick fixes for this test under `ai_fixes` (targets the most recent failing execution unless testrun_id is set). If a section reports `in_progress`, poll get_ai_insights(testrun_id=..., testcase_id=...) instead of re-calling this tool.",
+  "type": "boolean"
+}
    • addedInput schema / properties / suite_file_path
      Added value: +{
+  "description": "Optional spec file path to disambiguate when several tests share the same title. Example: 'tests/checkout.spec.ts'.",
+  "type": "string"
+}
    • addedInput schema / properties / testrun_id
      Added value: +{
+  "description": "Only with include_ai_insights: target the AI fixes at this specific run instead of the most recent failure.",
+  "type": "string"
+}
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes far beyond the lone readOnlyHint annotation: discloses the 409 AMBIGUOUS_IDENTITY ambiguity protocol, lazy AI generation with 'in_progress' polling via get_ai_insights, transient-5xx vs terminal-4xx handling, that fixes are recommendations to validate against live code, and that the debugging_prompt must be read first. Rich operational context the annotations do not carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose and the key alternative, but at roughly 350 words it sprawls and repeats itself — the guidance that get_debug_evidence 'is the first call' appears both mid-description and again in the trailing Workflow paragraph. The IMPORTANT block and disambiguation protocol also overlap the schema.

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 6-parameter tool with no output schema, the description compensates fully: it enumerates the returned evidence (execution history, failure patterns, error messages, debugging_prompt, ai_fixes) and the error/status paths. Nothing an agent needs to invoke it correctly is missing.

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 meaning: testcase_id is the pw_test_id and wins over name/path, a title can match several tests across projects/files, testrun_id only applies with include_ai_insights, and how to resolve ambiguity via the returned candidates.

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?

States a specific verb+resource with scope: 'AI-assisted root cause analysis for a failing or flaky test', and enumerates what it returns. It explicitly distinguishes itself from get_debug_evidence and get_ai_insights, so an agent can route among siblings without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use triggers ('why is test X failing?', 'debug test X', 'is test X flaky?'), names the alternative to call first (get_debug_evidence), and states the narrow condition for using this tool instead ('only for the stored AI suggestions or the full execution history').

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