Skip to content
Scalekit Docs
Talk to an Engineer Dashboard

Connect AI agents to the Testdino MCP server

Vendor MCP
Open markdown

The Testdino MCP connector routes your AI agent's tool calls to Testdino's own MCP server through Scalekit. Each user signs in to Testdino once, and Scalekit stores and refreshes their tokens, so your agent never handles credentials. It comes with 57 tools.

Tools
57
What they doRead · write · destructive
34 · 23 · 034 read23 write0 destructive
Users sign in with
OAuth app
Scalekit's or your own

Setup

  1. Install the SDK

    Terminal window
    npm install @scalekit-sdk/node dotenv

  2. Set your credentials

    Add your Scalekit credentials to your .env file. Find values in app.scalekit.com > Developers > API Credentials.

    .env
    SCALEKIT_ENVIRONMENT_URL=<your-environment-url>
    SCALEKIT_CLIENT_ID=<your-client-id>
    SCALEKIT_CLIENT_SECRET=<your-client-secret>

  3. Create the Testdino MCP connection

    In AgentKit > Connections, create a Testdino MCP connection. The name you give it is the connection_name your code passes. See Configure connections.

    Scalekit credentials are available for Testdino MCP server, so you don't need to register an OAuth app.

  4. Authorize a user and make your first call

    quickstart.mts
    import { ScalekitClient } from '@scalekit-sdk/node'
    import 'dotenv/config'
    import { createInterface } from 'node:readline/promises'
    

    const scalekit = new ScalekitClient(
      process.env.SCALEKIT_ENVIRONMENT_URL,
      process.env.SCALEKIT_CLIENT_ID,
      process.env.SCALEKIT_CLIENT_SECRET,
    )
    const actions = scalekit.actions
    

    const connector = 'testidinomcp'
    const identifier = 'user_123'
    

    // Generate an authorization link for the user
    const { link } = await actions.getAuthorizationLink({ connectionName: connector, identifier })
    console.log('Authorize Testdino MCP:', link)
    const rl = createInterface({ input: process.stdin, output: process.stdout })
    await rl.question('Press Enter after authorizing...')
    rl.close()
    

    // Make your first call
    const result = await actions.executeTool({
      connector,
      identifier,
      toolName: 'testidinomcp_get_trace_analysis',
      toolInput: {},
    })
    console.log(result)
    Terminal window
    npx tsx quickstart.mts

    Each user signs in once. See Authorize a user for the full flow and statuses.

Tools

Pass the exact name to execute_tool
Try in PlaygroundRequest a tool
  • testidinomcp_debug_testcaseAI-assisted root cause analysis for a failing or flaky test.Read-only

    Debug Test Case

    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?". If the title is shared across multiple files, pair with suite_file_path to disambiguate (else data-handler returns 409 AMBIGUOUS_IDENTITY with candidates). 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.

    Inputs

    projectIdstringrequired
    Project ID
    testcase_namestringrequired
    Test case name / title to debug. Required unless testcase_id is given.
    include_ai_insightsboolean
    Attach AI recommendations + quick fixes for this test under `ai_fixes` (targets the most recent failing execution unless testrun_id is set).
    suite_file_pathstring
    Optional spec file path — disambiguates when several tests share the same title. Example: "tests/checkout.spec.ts".
    testcase_idstring
    The test's pw_test_id — exact, never ambiguous. Wins over testcase_name and suite_file_path.
    testrun_idstring
    Only with include_ai_insights: fetch the AI analysis for this specific run instead of the most recent failure.
  • testidinomcp_get_ai_insightsTestDino's AI Insights, at three levels.Read-only

    Get AI Insights

    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).

    Inputs

    projectIdstringrequired
    Project ID (e.g. project_<id>).
    dateRangestring
    Project overview only: e.g. "7d", "30d", or "custom" (with fromDate/toDate).
    environmentstring
    Project overview only: filter by environment name.
    fromDatestring
    Project overview only: custom range start (YYYY-MM-DD).
    testcase_idstring
    Case mode: with testrun_id, return AI fixes (recommendations + quick fixes) for this test case (its pw_test_id) in that run.
    testrun_idstring
    Run mode: AI insights for this single test run. Also required for case mode (with testcase_id).
    toDatestring
    Project overview only: custom range end (YYYY-MM-DD).
  • testidinomcp_get_audit_reportRead-only TestDino Playwright audit reads.Read-only

    Get Audit Report

    Read-only TestDino Playwright audit reads. Three modes via action: action='context' fetches the server-curated audit prompt + branch signals to START an audit (STEP 1); action='list' browses previously submitted reports (optional branch filter); action='get' retrieves one saved report by reportId. Only use this when the user EXPLICITLY names TestDino (e.g. "TestDino audit"). For a generic audit without TestDino named, do NOT call this tool.

    Inputs

    actionstringrequired
    Read mode: 'context' (fetch audit prompt + branch signals to start), 'list' (browse past reports), 'get' (one report by reportId).one of contextlistget
    projectIdstringrequired
    Project ID (required).
    branchstring
    Git branch. For action='context', the branch to audit. For action='list', an optional filter.
    limitinteger
    Page size for action='list'.
    pageinteger
    Page number for action='list'.
    reportIdstring
    Report ID. Required for action='get'.
  • testidinomcp_get_debug_evidenceStart every failing-test investigation here.Read-only

    Get Debug Evidence

    Start every failing-test investigation here. One call returns the whole cheap tier of the evidence ladder: the computed flake verdict with its per-attempt failure signatures, the regression boundary (the last run this test passed and the first it failed), and download links for every stored artifact — trace, screenshots, and the expected/actual/diff images on a visual failure. Read all of it before forming a hypothesis. The verdict says whether the failure repeats, never why, so it rules fixes out rather than pointing at a cause; the boundary turns "why does this fail" into "what changed between these two runs", which is a far smaller question. Artifact links are minutes-scale: download what you need immediately, and call this again to mint fresh ones rather than treating an expired link as a missing artifact.

    Inputs

    projectIdstringrequired
    Project ID (e.g. project_<id>).
    formatstring
    Response shape. "md" is markdown, and markedly cheaper for the same content.one of jsonmd
    include_instructionsboolean
    Default true. The procedure and the trace runbook are identical on every call and about half the response — set false on repeat calls once you have read them.
    maxLengthinteger
    Cap the markdown length. Applies to format="md" only; anything cut is announced in the output. JSON is never truncated, because a cut payload would not parse and would read as a complete one.
    suite_file_pathstring
    Spec file path — only needed when the title is shared across files.
    testcase_idstring
    The case's pw_test_id.
    testcase_namestring
    Full test title. Required for the regression boundary — prefer it when known.
    testrun_idstring
    Run scope. Omit to use the most recently started run carrying this case.
  • testidinomcp_get_external_issueFetch external issue/task details by provider IDs or keys previously linked to TestDino, such as Jira keys TD-17 or Linear issue identifiers.Read-only

    Get External Issue

    Fetch external issue/task details by provider IDs or keys previously linked to TestDino, such as Jira keys TD-17 or Linear issue identifiers.

    Inputs

    issueIdsarrayrequired
    External issue IDs or keys (at most 20).
    projectIdstringrequired
    TestDino project ID
    providerstringrequired
    Provider to read issues from. monday.com and GitHub have no issue read route.one of jiralinearasana
    targetobject
    Provider-specific target/context values. For Jira, pass { defaultApp } to read from a specific Atlassian site/resource.
  • testidinomcp_get_flake_verdictSay whether a failing test behaves the same way every time, by comparing its retry attempts within one run.Read-only

    Get Flake Verdict

    Say whether a failing test behaves the same way every time, by comparing its retry attempts within one run. If you are debugging a failing test, call get_debug_evidence first — it returns this plus the regression boundary and every artifact link in one call, so calling this separately afterwards repeats work already done. Returns a computed verdict — "deterministic" (every attempt failed with the same signature, so the failure repeats), "flaky" (an attempt passed on retry, so the outcome is not consistent), or "inconclusive" (too few attempts, or the attempts failed differently) — plus the per-attempt signatures behind it. The verdict describes the behaviour, not the cause. It tells you which fixes the evidence cannot support; it does not tell you where the fix goes. Decide that after reading the artifacts, the trace and the code. Needs a test that ran with retries enabled; a single attempt is always inconclusive.

    Inputs

    projectIdstringrequired
    Project ID (e.g. project_<id>).
    testcase_idstringrequired
    Playwright pw_test_id of the failing case.
    testrun_idstring
    Run scope. Omit to use the most recently started run carrying this case.
  • testidinomcp_get_integration_statusCheck whether Jira, Linear, Asana, monday.com, or GitHub is connected for a TestDino project.Read-only

    Get Integration Status

    Check whether Jira, Linear, Asana, monday.com, or GitHub is connected for a TestDino project. Call this before connect_integration or create_external_issue.

    Inputs

    projectIdstringrequired
    TestDino project ID.
    providerstringrequired
    Integration provider connected to this TestDino project.one of jiralinearasanamondaygithub
    includeCreateOptionsboolean
    When true, include provider create metadata (createOptions: projects, issue types, required/optional fields). Resolved against the provider default target when no target is supplied.
    targetobject
    Provider-specific target/field values. Jira accepts human-readable aliases such as { jiraProjectKey: "TRX", issueType: "Bug" } or { jiraProjectName, issueTypeName }; raw { jiraProjectId, issueTypeId } also works. Linear { teamId }, Asana { workspaceId, projectId }, monday.com { boardId }.
  • testidinomcp_get_manual_runGet the full details of one manual test run: name, status, environment, linked release, test stats (total/passed/failed/blocked/untested), contributors, attachments, linked issues.Read-only

    Get Manual Run

    Get the full details of one manual test run: name, status, environment, linked release, test stats (total/passed/failed/blocked/untested), contributors, attachments, linked issues. runId accepts either the internal _id or a counter-style ID like "RUN-12".

    Inputs

    projectIdstringrequired
    Project ID (e.g. project_<id>). Obtain from the health tool.
    runIdstringrequired
    Internal _id or counter-style ID (e.g. "RUN-12").
All 123 in Developer Tools