Testdino MCP

TestDino MCP

A Model Context Protocol (MCP) server that connects TestDino to AI agents. This server enables you to interact with your TestDino test data directly through natural language commands.

Quick Start

Add this to your MCP client config (~/.cursor/mcp.json for Cursor), then restart the client:

{

"mcpServers": { "TestDino": { "command": "npx", "args": ["-y", "@testdino/mcp"], "env": { "TESTDINO_PAT": "your-pat-here" } } } }

Get your PAT from TestDino → User Settings → Personal Access Tokens, then ask your assistant: _"Check TestDino health."_ You should see your account, organizations, and projects. Full setup for Cursor and Claude Desktop is in Integration.

What is This?

This MCP server bridges the gap between your TestDino test management platform and AI agents. Instead of manually navigating the TestDino dashboard, you can ask your AI assistant to:

• Check test run results
• Analyze test failures
• Get detailed test case information
• Manage manual test cases and suites
• Plan releases, spin up manual test runs, and assign testers
• Run exploratory testing sessions
• Record per-case verdicts (passed / failed / blocked / etc.) from chat

All through simple conversational commands.

Features

• 🔍 Health Check: Verify your connection and validate your TestDino PAT. Get account information and list all available organizations and projects.
• 📊 Test Run Management: List and retrieve detailed information about your test runs with filtering options (branch, time, author, commit, environment).
• 🧪 Test Case Analysis: Get comprehensive details about individual test cases, including errors, logs, execution steps, and artifacts (screenshots, videos, traces).
• 🐛 AI-Assisted Debugging: Debug test case failures with historical data aggregation, failure pattern analysis, and AI-friendly debugging prompts. Analyze patterns across multiple executions to identify root causes.
• 🧭 Test Quality Audit: Fetch a server-curated audit prompt plus branch signals, analyze your local test code, and store the completed report back in TestDino without uploading raw source files.
• 📝 Test Case Management: Create, update, list, and retrieve manual test cases with comprehensive filtering and organization (status, priority, severity, type, layer, behavior, tags).
• 📁 Test Suite Organization: Create and manage test suite hierarchies to organize your manual test cases.
• 🚀 Release Planning: Create, browse, and update releases (a.k.a. milestones), nest them up to 3 levels deep, and track rolled-up progress stats across all runs in a release.
• ▶️ Manual Test Runs: Spin up runs scoped to specific suites or the whole project, attach them to a release, and update workflow state without leaving chat.
• ✅ Per-case Assignment & Verdicts: Inside a run, assign each test case to a tester (by User \_id or email) and set the result — passed, failed, blocked, skipped, retest — exactly as the UI does.
• 🔭 Exploratory Sessions: Create exploratory testing sessions with mission/charter, assign a tester, link to a release, and track state.
• 🧩 Failure Triage at Scale: Group a run's failing tests by their underlying error signature to see which reds are one root cause versus many, so you fix the real problem first.
• 🔗 Issue Tracker Integrations: Connect Jira, Linear, Asana, or monday.com and file a tracked issue straight from a failing test or run, then check its status later without leaving chat.
• 🔌 MCP Compatible: Built on the Model Context Protocol standard. You can configure TestDino MCP with any MCP-compatible IDEs or AI agents (Cursor, Claude Desktop, etc.).
• ⚡ Easy Setup: Install and configure in minutes with npx. No installation required!
• 🔐 Secure: PAT stored securely in your local configuration. One PAT provides access to all organizations and projects you have permissions for.

Available Tools

The server provides 58 tools across twelve domains, the same tools, prompts and skills guide as the hosted TestDino MCP:

Test Execution & Results:

1. `health` - Verify your connection and validate your PAT. Shows account information, available organizations, and projects with access permissions.
2. `list_testruns` - Browse test runs with filters (branch, time interval, author, commit, environment). Supports pagination and batch operations.
3. `get_run_details` - Get comprehensive details about a specific test run including statistics, test suites, test cases, and metadata. Supports batch operations (comma-separated IDs, max 20).
4. `list_testcase` - List test cases with comprehensive filtering (by test run, status, browser, error category, branch, environment, commit, author, spec file, tags, runtime, artifacts, and more). Can filter by test run criteria or directly by test case properties.
5. `get_testcase_details` - Get detailed information about a specific test case including error messages, stack traces, test steps, console logs, and artifacts. Can identify by testcase_id alone or by testcase_name with testrun_id/counter.
6. `debug_testcase` - Debug a test case by aggregating historical failure data across multiple executions. Returns failure patterns, error categories, common error messages, error locations, browser-specific issues, and a pre-formatted debugging prompt for AI analysis. Perfect for root-cause analysis and identifying flaky test behavior.
7. `get_debug_evidence` - Start every failing-test investigation here: one call returns the flake verdict with per-attempt signatures, the regression boundary (last pass → first fail), and short-lived download links for every stored artifact (trace, screenshots, visual diff images). JSON or markdown.
8. `get_flake_verdict` - Compare a test's retry attempts within one run and say whether the failure repeats: deterministic, flaky, or inconclusive.
9. `verify_fix` - After a new run lands, check whether a fix held against the run you saw the failure in: fixed, not_fixed, changed_failure, still_failing, unstable, no_runs_since_baseline, or baseline_not_found.
10. `get_audit_report` - Fetch the audit context (server-curated prompt + top failing / flaky / slow tests for the branch) to start a new audit, browse historical reports, or retrieve one by reportId.
11. `submit_audit_report` - Submit a completed audit report (score, findings, recommendations, markdown) to TestDino.
12. `show_audit_report` - Show a saved audit as a scorecard: score and band, where the points were lost, the top issues, and a link to the report. AI tools that render MCP Apps show it as a card; others get a one-paragraph summary.

Test Case Management:

1. `list_manual_test_cases` - Search and list manual test cases with comprehensive filtering (project, suite, status, priority, severity, type, layer, behavior, automation status, tags, flaky status).
2. `get_manual_test_case` - Get detailed information about a specific manual test case including steps, custom fields, preconditions, postconditions, and all metadata.
3. `create_manual_test_case` - Create new manual test cases with steps, preconditions, postconditions, and metadata (priority, severity, type, layer, behavior).
4. `update_manual_test_case` - Update existing manual test cases (title, description, steps, status, priority, severity, type, layer, behavior, preconditions, postconditions).
5. `list_manual_test_suites` - List test suite hierarchy to find suite IDs for organization. Supports filtering by parent suite.
6. `create_manual_test_suite` - Create new test suite folders to organize test cases. Supports nested suites by providing parentSuiteId.

Automation Linking:

1. `list_automated_tests` - List the Playwright tests TestDino has seen for a project, the source of pwTestId + fullTitle for linking. Filter by spec file, suite, or free-text title.
2. `get_test_case_links` - Show which automated tests are linked to a manual test case, with their latest automation result.
3. `link_automated_test` - Link one Playwright test to a manual test case so its automation result shows on the case.
4. `unlink_automated_test` - Remove a link between a manual test case and a Playwright test.
5. `bulk_link_automated_tests` - Link up to 500 case/test pairs in one call, with per-item results so a partial failure is visible.

Releases (a.k.a. Milestones):

1. `list_releases` - Browse releases for a project with filters (search, type, completion status, parent release). Releases group runs + sessions and can nest up to 3 levels deep.
2. `get_release` - Get full details for one release including dates, status, parent/root hierarchy, and rolled-up progress stats across all runs in this release and its descendants. Accepts internal _id or counter-style ID like MS-12.
3. `create_release` - Create a new release with name, type, dates, and optional parent for nesting.
4. `update_release` - Modify an existing release — name, dates, completion flags, type, linked issues. Closed releases are still editable.

Manual Test Runs:

1. `list_manual_runs` - Browse manual runs in a project. Filter by status, state, environment, release, tags, or free-text name search.
2. `get_manual_run` - Get full details for one run — test stats (total/passed/failed/blocked/untested), contributors, attachments, linked release. Accepts internal _id or counter-style ID like RUN-12.
3. `create_manual_run` - Create a new manual run. Choose selectionMode='all' for every case in the project, or 'selected' with suite/case IDs to scope it. Attach to a release with releaseId.
4. `update_manual_run` - Modify run metadata — name, environment, state, release attachment, tags. Closed runs are read-only except for releaseId.
5. `list_run_test_cases` - Get the per-case execution rows inside a run — exactly what the UI shows in the run's test-case table. Each row includes the current assignee and current result. Filter by assignee (email or \_id) or result.
6. `update_run_test_case` - Set the assignee and/or result for one test case inside a run — same as clicking "Assign to" + the result pill in the UI. Works even on untested cases (auto-creates the per-case row on first edit). Accepts caseKey (TC-156), test case _id, or the internal tcm_rtc_… ID.

Exploratory Sessions:

1. `list_sessions` - Browse exploratory sessions in a project. Filter by status, state, sessionType, assignee (email or \_id), release, tags.
2. `get_session` - Get full details for one session — name, mission, status, assignee, linked release, findings. Accepts internal _id or counter-style ID like SES-12.
3. `create_session` - Create a new exploratory session with mission/charter, sessionType, assignee, estimate, and optional release attachment.
4. `update_session` - Modify session metadata — name, mission, assignee, state, estimate, linked issues.

**Error Analysis