Skip to main content
Glama
testdino-hq

TestDino MCP

by testdino-hq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Test Run Details

get_run_details
Read-only

Retrieve the complete breakdown of one or more test runs — statistics, error categories, suites, and all test cases — by run ID or counter, with optional AI insights.

Instructions

Get the full breakdown of one or more test runs — test statistics, error category breakdown, suite list, and all test cases in the run. Use testrun_id for ID-based lookup or counter for the human-readable run number (e.g. counter="47"). Batch up to 20 runs by comma-separating: testrun_id="id1,id2,id3". Typical workflow: list_testruns() → pick IDs → get_run_details() for the specific run. When is_swarm is true the run was distributed across multiple CI machines and the response also carries machines[] (per-machine counts plus spec_files, duration_ms and idle_tail_ms), machine_summary (machine_count, slowest, fastest, imbalance_ratio) and could_not_execute_specs — specs no machine could run, which means the run is not a clean pass whatever the counts say. Use the optimize_swarm prompt to turn those into a verdict; a file never splits across machines, so a slowest machine running one spec file is a hard floor that more machines cannot beat. Set include_ai_insights=true (single testrun_id only) to also get the run's AI Insights under ai_insights: AI failure categorization (flaky/bug/ui_change), failure clusters, new-failures cards, the error-analysis table, and the LLM-written run summary. AI payloads are generated lazily — if ai_insights sections report status "processing"/"not_generated", poll get_ai_insights(testrun_id=...) until "completed" instead of re-calling this tool. 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.

Input Schema

NameRequiredDescriptionDefault
counterNoRun counter. Number for a single run (e.g. 47), or comma-separated string ("47,48,49", max 20) for batch lookup.
projectIdYesProject ID
testrun_idNoSingle test run ID, or comma-separated IDs (max 20)
include_ai_insightsNoAttach the run's AI Insights (categorization, clusters, error-analysis table, written summary) under `ai_insights`. Requires a single testrun_id (not counter, not a batch).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 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 / counter / description
      Previous value: -"Run counter. A number for a single run (e.g. 47), or a comma-separated string ('47,48,49', max 20) for a batch."New value: +"Run counter. Number for a single run (e.g. 47), or comma-separated string (\"47,48,49\", max 20) for batch lookup."
    • changedInput schema / properties / counter / type
      Previous value: -[
-  "number",
-  "string"
-]New value: +[
+  "string",
+  "number"
+]
    • changedInput schema / properties / include_ai_insights / description
      Previous value: -"Attach the run's AI Insights (failure categorization, clusters, error-analysis table, LLM summary) under `ai_insights`. Requires a single testrun_id (not counter, not a batch). If a section reports `processing`, poll get_ai_insights(testrun_id=...) instead of re-calling this tool."New value: +"Attach the run's AI Insights (categorization, clusters, error-analysis table, written summary) under `ai_insights`. Requires a single testrun_id (not counter, not a batch)."
    • changedInput schema / properties / projectId / description
      Previous value: -"Project ID (Required). The TestDino project identifier."New value: +"Project ID"
    • changedInput schema / properties / testrun_id / description
      Previous value: -"Test run ID(s). Single ID or comma-separated for batch (max 20). Example: 'test_run_123' or 'run1,run2,run3'."New value: +"Single test run ID, or comma-separated IDs (max 20)"
  2. Changed3 schema fields changedv2.0.2
    • changedInput schema / properties / counter / description
      Previous value: -"Filter by test run counter (sequential number)."New value: +"Run counter. A number for a single run (e.g. 47), or a comma-separated string ('47,48,49', max 20) for a batch."
    • changedInput schema / properties / counter / type
      Previous value: -"number"New value: +[
+  "number",
+  "string"
+]
    • addedInput schema / properties / include_ai_insights
      Added value: +{
+  "description": "Attach the run's AI Insights (failure categorization, clusters, error-analysis table, LLM summary) under `ai_insights`. Requires a single testrun_id (not counter, not a batch). If a section reports `processing`, poll get_ai_insights(testrun_id=...) instead of re-calling this tool.",
+  "type": "boolean"
+}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Read-only annotation is consistent, and the description adds substantial behavioral context annotations cannot carry: is_swarm semantics (distributed CI, machines[], imbalance_ratio, could_not_execute_specs meaning the run is not a clean pass), lazy AI payload generation with status values ('processing'/'not_generated'/'unavailable'), and the 5xx/4xx transient-vs-terminal retry rule.

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?

Long but front-loaded: the core purpose and lookup modes come first, then swarm specifics, then AI-insight polling. Each block carries non-redundant information, though density is high and a few clauses (e.g. the hard-floor aside about spec files) could be trimmed without loss.

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 full burden of describing returns and does so thoroughly for every mode: standard run contents, swarm-specific fields, and the ai_insights payload structure. An agent has everything needed to call it correctly and interpret the response.

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; the description goes beyond it by illustrating syntax (counter="47", testrun_id="id1,id2,id3") and restating the batching cap of 20. It also clarifies that include_ai_insights is single-ID only, but most of this is already present in the schema descriptions.

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?

Opens with a specific verb+resource ('Get the full breakdown of one or more test runs') and enumerates exactly what comes back: test statistics, error category breakdown, suite list, and all test cases. This clearly separates it from list_testruns (which lists) and get_ai_insights (which drills into AI payloads).

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?

Provides an explicit workflow ('list_testruns() → pick IDs → get_run_details()'), tells the agent which parameter to use for ID vs human-readable lookup, and routes to alternatives when appropriate ('poll get_ai_insights(...) until completed instead of re-calling this tool'). When-to-use and when-not-to-use are both covered.

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