Skip to main content
Glama

Get Trace Analysis

get_trace_analysis
Read-only

Debug a failing Playwright test from its trace.zip: get a runbook for the Playwright CLI protocol, classify the failure, and propose a fix. Add projectId and testcase_id for a hosted trace URL.

Instructions

Debug a failing Playwright test from its trace.zip using the Playwright agent CLI (npx playwright trace …, Playwright 1.59+). Returns a runbook that teaches the exact CLI protocol (open → actions → action → snapshot → close) plus how to classify the failure and propose a fix. Pass projectId + testcase_id (the Playwright pw_test_id) to also get a short-lived download URL for that case's hosted trace; optionally scope with testrun_id. Omit the ids to just get the runbook for a trace.zip you already have locally. The analysis runs on your machine — download the trace, run the CLI commands yourself, then report the root cause and fix.

Input Schema

NameRequiredDescriptionDefault
projectIdNoProject ID — required to resolve the hosted trace download URL
testrun_idNoOptional run scope for testcase_id (single run)
testcase_idNoPlaywright pw_test_id of the failing case whose hosted trace to resolve

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 / projectId / description
      Previous value: -"Project ID (Required). The TestDino project identifier."New value: +"Project ID — required to resolve the hosted trace download URL"
    • changedInput schema / properties / projectId / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
    • changedInput schema / properties / testcase_id / description
      Previous value: -"Playwright pw_test_id of the failing case whose hosted trace to resolve."New value: +"Playwright pw_test_id of the failing case whose hosted trace to resolve"
    • changedInput schema / properties / testcase_id / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
    • changedInput schema / properties / testrun_id / description
      Previous value: -"Optional run scope for testcase_id (single run)."New value: +"Optional run scope for testcase_id (single run)"
    • changedInput schema / properties / testrun_id / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
    • removedInput schema / required
      Removed value: -[
      -  "projectId"
      -]
  2. Addedv2.0.2

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint annotation: it discloses what is returned (a runbook teaching the open→actions→action→snapshot→close protocol), that the URL is short-lived, and crucially that analysis runs on the caller's machine and the agent must download and run the CLI itself before reporting a fix. This is exactly the kind of non-obvious behavioral context annotations cannot carry.

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

Conciseness4/5

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

Front-loaded with purpose, then modes, then the operational caveat. Two clauses are slightly redundant ('runs on your machine' and 'download the trace, run the CLI commands yourself'), but the density is justified for a multi-mode, multi-step tool.

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?

There is no output schema, so the description carries the return-value burden and does so — it describes the runbook content and the download URL. Combined with the workflow warning that the analysis happens locally, an agent has everything needed to call and act on this tool.

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 already 100%, so baseline is 3, but the description adds real meaning: projectId+testcase_id together unlock the download URL, testrun_id scopes to a single run, and omitting all ids switches to runbook-only mode. That dependency relationship is not captured by the per-field schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Debug a failing Playwright test from its trace.zip using the Playwright agent CLI' — and names the mechanism (trace CLI, 1.59+), which sets it apart from generic debug siblings. It never names debug_testcase or get_debug_evidence, so an agent must infer the boundary rather than being told it.

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?

Explicitly spells out the two invocation modes: pass projectId + testcase_id (optionally testrun_id) to get a hosted-trace download URL, or omit the ids to just get the runbook for a local trace.zip. Clear conditional usage, but no exclusions or comparison against the other debug-oriented siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.