Skip to main content
Glama
testdino-hq

TestDino MCP

by testdino-hq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get AI Insights

get_ai_insights
Read-only

Fetch AI failure insights and fixes for a project, a single test run, or one test case to triage what to fix first and poll pending AI analysis.

Instructions

TestDino's AI Insights, at three levels. With testrun_id + testcase_id: that test case's AI fixes — recommendations (investigation/remediation steps + reasoning) and quick fixes (concrete fixes, often with code snippets). With testrun_id only: that run's AI analysis — AI failure categorization (flaky/bug/ui_change), failure clusters, new-failures cards, the error-analysis table, and the LLM-written run summary. With neither: the project-level overview — per-category failure counts over the date range with the top offending test cases in each category. AI payloads are generated lazily: sections may report status "not_generated", "queued", "processing", or "failed" before "completed" — poll this tool every few seconds while "processing". A "disabled" status is terminal (AI features are off for the project, Settings → AI) — do not poll it. Case mode (testrun_id + testcase_id) reports "in_progress" while ai_fixes generate; the run-level sections use "processing". An "unavailable" section carries the upstream statusCode: a 5xx or timeout is transient (retry once), a 4xx (bad ids) is terminal. Use the project overview to answer "what should we fix first?"; the run mode to triage one run; the case mode to get fixes for one failing test — each also serves as the poll target after get_run_details(include_ai_insights=true) / debug_testcase(include_ai_insights=true) reported a pending status. Requires AI features to be enabled in the project settings (Settings → AI).

Input Schema

NameRequiredDescriptionDefault
toDateNoProject overview only: custom range end (YYYY-MM-DD)
fromDateNoProject overview only: custom range start (YYYY-MM-DD)
dateRangeNoProject overview only: e.g. "7d", "30d", or "custom" (with fromDate/toDate)
projectIdYesProject ID (e.g. project_<id>)
testrun_idNoRun mode: AI insights for this single test run. Also required for case mode (with testcase_id).
environmentNoProject overview only: filter by environment name
testcase_idNoCase mode: with testrun_id, return AI fixes (recommendations + quick fixes) for this test case (its pw_test_id) in that run.

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 / dateRange / description
      Previous value: -"Project overview only: e.g. \"7d\", \"30d\", or \"custom\" (with fromDate/toDate)."New value: +"Project overview only: e.g. \"7d\", \"30d\", or \"custom\" (with fromDate/toDate)"
    • changedInput schema / properties / environment / description
      Previous value: -"Project overview only: filter by environment name."New value: +"Project overview only: filter by environment name"
    • changedInput schema / properties / fromDate / description
      Previous value: -"Project overview only: custom range start (YYYY-MM-DD)."New value: +"Project overview only: custom range start (YYYY-MM-DD)"
    • changedInput schema / properties / projectId / description
      Previous value: -"Project ID (Required). The TestDino project identifier."New value: +"Project ID (e.g. project_<id>)"
    • changedInput schema / properties / toDate / description
      Previous value: -"Project overview only: custom range end (YYYY-MM-DD)."New value: +"Project overview only: custom range end (YYYY-MM-DD)"
  2. Addedv2.0.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, so the description carries the behavioral burden and does so thoroughly: lazy generation, the full status vocabulary ('not_generated'/'queued'/'processing'/'failed'/'completed'/'disabled'/'in_progress'/'unavailable'), which statuses are terminal, polling cadence, and transient-vs-terminal error interpretation via upstream statusCode.

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 the three-mode frame and dense with actionable detail, with no filler sentences. It is long, and the polling advice ('poll this tool every few seconds') is restated later as 'each also serves as the poll target', a minor redundancy that keeps it out of the top band.

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 must describe returns — and it does, enumerating recommendations/quick fixes, failure categorization, clusters, new-failure cards, the error-analysis table, and the LLM run summary per mode. Nothing needed to call it correctly, or to interpret its gaps, 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% and each parameter already names its mode, so the baseline is 3. The description adds composite meaning the per-parameter schema cannot express: which parameter combinations yield which payload, and that testrun_id is shared between run mode and case mode.

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 states a specific verb and resource ('TestDino's AI Insights') and immediately decomposes it into three unambiguous modes keyed on parameter combination. An agent can distinguish case mode, run mode, and project-overview mode without opening the schema, and the mention of get_run_details/debug_testcase positions it against siblings.

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?

Explicitly routes each mode to a task: 'Use the project overview to answer "what should we fix first?"; the run mode to triage one run; the case mode to get fixes for one failing test.' It also states the prerequisite (AI features enabled in Settings → AI) and that this tool is the poll target after the other tools report a pending status.

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