Skip to main content
Glama

get_failure_details

Retrieve full root-cause-analysis including traces and screenshots for every failed test in the most recent run. Use when a test fails to understand why and gather artifacts for debugging.

Instructions

Extract full root-cause-analysis materials for every failed test in the most recent run.

Behavior:

  • Reads report.json, filters tests where outcome == 「failed」

  • pytest: parses Playwright trace.zip → extracts real API call sequence (Frame., Page., Locator., ElementHandle. events) as steps[]

  • Maestro: parses flow YAML for takeScreenshot: directives → resolves .png at PROJECT_ROOT root

  • Best-effort resolves screenshot / trace.zip / video / recording paths from --output / --debug-output artifact directories Returns: list[{nodeid, title, message, duration, steps[], screenshot, trace, video}]

When to use:

  • run_tests just reported failed > 0 → drill into each case

  • User asks 「why did it fail / show me the trace / what broke」

  • Filing a JIRA bug → use the artifact paths to attach screenshot+trace

  • Comparing failure signatures across runs (pair with get_test_history)

When NOT to use:

  • Want the summary count only → use get_test_report (lighter)

  • No tests have been run yet → returns [{error: 「找不到報告」}]

  • Want details for PASSING tests too → not supported here; the HTML reporter renders those via a different path

Edge cases:

  • test_id substring matches nothing → empty list, no error

  • screenshot/trace/video missing on disk → those fields are null but the entry stays

  • Retry-recovered flake (was failed, now passed) → not listed here; surfaces in summary.flaky_in_run instead

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
test_idNo選填,僅回傳 nodeid 含此關鍵字的 case(substring match,不分大小寫)。省略則回傳全部失敗 case。常用模式:先全部抓→看到特定模式後再用 test_id 收斂。
Behavior5/5

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

Without annotations, the description fully bears the burden. It details file reading (report.json), filtering by outcome, handling of pytest vs Maestro, path resolution, and return format (list of objects with specific fields). Edge cases for missing files and retry flakes are covered.

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 well-structured with labeled sections for behavior, usage, and edge cases. It front-loads the core purpose and every section adds value without redundancy.

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?

Despite no output schema, the description enumerates return fields (nodeid, title, message, duration, etc.) and handles edge cases like missing files and retry-recovered flakes. It also references sibling tools for context.

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 coverage is 100% with a clear parameter description including substring match and case-insensitivity. The main description does not elaborate further; it only repeats the behavior implicitly. Hence baseline 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 specifies the verb 'extract' and the resource 'root-cause-analysis materials for every failed test in the most recent run'. It distinguishes from siblings by noting when to use alternatives like get_test_report and get_test_history.

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?

Explicit 'When to use' and 'When NOT to use' sections outline specific scenarios: after run_tests with failures, user queries for traces, JIRA filing, and cross-run comparison. It also warns against using for summary counts (get_test_report) or when no tests have run.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kao273183/mk-qa-master'

If you have feedback or need assistance with the MCP directory API, please join our Discord server