MCP Server By TestMu AI

- upload_app: Uploads an app to LambdaTest for mobile testing and displays upload status.
- generateHyperExecuteYAML: Generates a HyperExecute YAML configuration for running tests on LambdaTest's HyperExecute platform.

REQUIRED fields: project (language, framework) and testing (testDiscovery.command, testRunnerCommand)
All other fields are OPTIONAL.

Supports multiple languages and frameworks:
- JavaScript/TypeScript: Playwright, Cypress, WebDriverIO, Puppeteer, Taiko
- Python: Pytest, Behave, Robot Framework
- Java: TestNG, JUnit, Cucumber
- Ruby: RSpec, Capybara
- C#: NUnit, xUnit, MSTest
- Mobile (ONLY use appTesting for these): XCUI (iOS), Espresso (Android), Appium

Features:
- Smart framework defaults for common configurations
- Input validation with security checks
- Caching and artifact upload configuration
- Git integration via sourcePayload
- Mobile app testing support (via optional appTesting field)

NOTE: For web automation (Selenium, Playwright, Cypress, etc.), do NOT include appTesting field.
- answerHyperExecuteQuery: Answers questions about HyperExecute features, configuration, usage, troubleshooting, and best practices by searching through documentation.
- getHyperExecuteJobInfo: Fetches and displays information about a HyperExecute job including status, test results, and progress.
- getHyperExecuteJobSessions: Fetches and displays session information for a HyperExecute job.
- getAccessibilityReport: Fetches accessibility report for URLs
- analyzeAppViaTunnel: Analyzes a locally running app for accessibility via LambdaTest tunnel.
- buildLocalAppForAnalysis: Builds the application from codebase, serves it locally, and analyzes accessibility issues.
- getSmartUIResources: Gets resources for a SmartUI comparison
- summarizeSmartUIPixelDiff: Summarizes SmartUI pixel differences
- summarizeSmartUILayoutDiff: Summarizes SmartUI layout differences
- summarizeSmartUIDomDiff: Summarizes SmartUI DOM differences
- analyzeSmartUIHumanDiff: Analyzes SmartUI differences from a human perspective
- analyzeSmartUIRun: Analyzes a SmartUI test run
- getAutomationTestDetails: Fetches detailed information about an automation test by ID
- getAutomationTestCommandLogs: Fetches command logs for a specific automation test
- getAutomationTestNetworkLogs: Fetches network logs for a specific automation test
- getAutomationTestBrowserConsoleLogs: Fetches Browser Console logs for a specific automation test. Note: Not available for mobile app automation tests.
- getAutomationTestSeleniumLogs: Fetches Selenium logs (web), Appium logs (mobile/Appium), or instrumentation logs (mobile/XCUI/Espresso) for a specific automation test. Automatically detects XCUI and Espresso tests and fetches the correct log type.
- automationQuery: Unified tool for querying LambdaTest automation resources: builds, sessions, tests, and logs. Supports listing builds, getting build details, deleting/updating/stopping builds, listing sessions in a build, fetching test details, and retrieving test logs (command, network, console, selenium, instrumentation). Use logType "instrumentation" for XCUI and Espresso test logs.
- triggerSuiteRun: Triggers a phone call test run for a specific suite. This will initiate phone calls for all scenarios configured in the suite.
- getSuiteOverview: Gets comprehensive suite overview for a project including run counts, latest status, scores, schedule information, and active calls.
- getSupportedPlatforms: Retrieve all supported browser and OS combinations available on LambdaTest (3000+ options). Use this to discover valid values for os, browser, version when setting up test configurations.
- listTunnels: Retrieve all active LambdaTest tunnel connections for the account. Useful for checking which tunnels are running before starting a new one or debugging local testing connectivity.
- stopTunnel: Terminate a specific active tunnel connection by tunnel ID. Use this to clean up tunnels that are no longer needed.
- deleteSession: Permanently delete a specific automation test session from LambdaTest by session ID.
- updateSession: Update the name or pass/fail status of a test session. Use status_ind to mark tests as passed, failed, error, or skipped from your test framework.
- stopSession: Stop an active running test session on LambdaTest.
- getSessionScreenshots: Retrieve command-by-command screenshots captured during a test session. Returns screenshot URLs for each step.
- getSessionVideo: Retrieve the video recording URL for a completed test session.
- getSessionV2CommandLogs: Retrieve v2 command execution logs for a test session. Returns structured JSON with enhanced detail compared to v1 logs.
- getSessionV2SeleniumLogs: Retrieve v2 Selenium/WebDriver grid request and response logs for a test session.
- postSessionExceptions: Upload exception/error logs from the client machine for a test session. Use this to attach assertion failures or unexpected errors to a session.
- postSessionAssertions: Upload assertion results for a test session. Use this to attach test assertion outcomes to a session for reporting.
- postTestExceptions: Upload exception logs for a specific test (by test ID) rather than by session ID.
- getLiveSessionLogs: Stream live logs from an active test session in real time.
- getOrgConcurrency: Retrieve the current concurrency usage and limits for the organization on web automation (Selenium/Cypress).
- getScreenshotTestResult: Retrieve the results and screenshot URLs for a completed or in-progress screenshot test.
- stopScreenshotTest: Stop an active screenshot test before it completes.
- getAnalyticsData: Retrieve analytics and test metrics data for the organization including build counts, pass/fail rates, and usage statistics.
- getFlakyTests: Retrieve a list of flaky tests — tests that pass and fail intermittently — to help identify unstable test cases. (UNDOCUMENTED - may change without notice)
- getTestTrends: Retrieve test execution trends over time including pass rates, failure rates, and execution counts. (UNDOCUMENTED - may change without notice)
- getAnalyticsErrors: Retrieve aggregated error data and failure analysis across test sessions. (UNDOCUMENTED - may change without notice)
- getPerformanceTestResult: Retrieve the results of a completed performance test including Core Web Vitals, load times, and performance scores.
- uploadPrerunFile: Upload a prerun script or file to LambdaTest. Prerun files execute before the test starts on the remote machine.
- deletePrerunFile: Delete an uploaded prerun file by stored LambdaTest file path.
- uploadUserFile: Upload a user file to LambdaTest storage. User files can be referenced in test scripts during execution.
- deleteUserFile: Delete an uploaded user file by stored LambdaTest file path.
- listUploadedApps: Retrieve all apps uploaded to LambdaTest for mobile testing. Use type=android/ios for real devices, emulator/simulator for virtual devices.
- deleteUploadedApps: Delete one or more uploaded apps from LambdaTest by their app IDs.
- uploadAppVirtualDevice: Upload an app (APK for emulator, IPA for simulator) to LambdaTest for virtual device (emulator/simulator) testing.
- listDevicesForTesting: Retrieve all available real devices on LambdaTest for mobile app testing. Filter by region and OS.
- getMobileCapabilityGenerator: Retrieve capability generation data for mobile automation test configuration.
- listMobileBuilds: Retrieve all mobile automation builds from the LambdaTest mobile automation API.
- listMobileSessions: Retrieve all mobile automation sessions from the LambdaTest mobile automation API.
- getMobileConcurrency: Retrieve the current concurrency usage and limits for mobile automation (real device testing).
- checkAppProcessingStatus: Check whether an uploaded app has been processed and is ready for features like image injection, network logs, and screenshot unblock on real devices.
- checkAppProcessingStatusVirtualDevice: Check whether an uploaded app has been processed for feature support on virtual devices (emulator/simulator).
- tm_list_projects: List all Test Manager projects the authenticated user is allowed to see. Supports keyword search and pagination.
- tm_get_test_cases: Find test cases in a project by filters (folder, priority, automation status, type, tags) and/or search (matches test case ID like TC-123, or title; minimum 3 characters) — returns summaries. Filters combine (AND). Pass case_id instead to get one case's full detail (steps, BDD scenarios, field values).
- tm_list_folders: Get a folder tree. Test Manager keeps three folder types: Test Cases and Test Runs folders (per project — pass project_id) and Modules folders (organization-level, since modules are shared across projects — no project_id needed). Pick with the tree parameter (default: test-cases). New test-case/test-run folders can be created with tm_create_folder.
- tm_list_modules: List the organization's reusable step Modules (modules are org-level, shared across projects — the same list as the Modules page). Supports name search and pagination. Reference a module by id when creating or editing a test case to include its steps (the Module itself is never changed).
- tm_list_configurations: List saved run Configurations (reusable platform / browser / OS / device setups). To apply one to a run, pass the configuration's TOP-LEVEL id to tm_create_test_run or tm_update_test_run as configuration_id (NOT the nested environments[].environment_id). Pass run_type to see only the configurations usable for that run type (kaneai vs manual). Each test instance carries exactly one configuration. Configurations are created by humans in the Test Manager UI.
- tm_get_test_runs: Pass run_id to get one test run's detail plus its result summary (instance counts by status — passed / failed / skipped / not started / in progress — and pass rate). Otherwise pass project_id to list runs with optional filters. Every returned run carries run_type ("kaneai" or "manual") identifying KaneAI runs — the backend stores KaneAI runs with type "Manual" (result-entry mode), so use run_type, not type, to tell them apart.
- tm_get_milestone: Pass milestone_id to get one milestone's detail and live completion progress. Otherwise pass project_id to list the project's milestones.
- tm_get_coverage_summary: Test coverage for a project — overall and per folder — computed live from the project's test cases (matches the Test Cases screen). Also answers requirement / traceability coverage: pass jira_id (any Jira issue key, e.g. TE-123 — a requirement, user story, epic, ticket or bug) to get that item's test coverage (the test cases linked to it and how many are automated; zero linked cases = uncovered). For a set of requirements, call once per Jira key. A scope with no test cases returns all zeros.
- tm_create_project: Create a new Test Manager project. Project & Org Instructions (Memory Layer) stay managed in the UI. Deleting projects is not available through this connection.
- tm_update_project: Update a project's name, description or tags (fields are merged — only what you pass changes). Project & Org Instructions stay managed in the UI.
- tm_create_folder: Create a folder — in a project's Test Cases tree (default) or Test Runs tree (pass project_id), or in the organization-level Modules tree (no project_id needed; module folders are shared across projects). Optionally nest it under an existing parent folder to build folder trees. Deleting folders is not available through this connection.
- tm_update_folder: Rename a folder, change its description, or move it under a different parent folder. Works on all three folder types: per-project Test Cases (default) and Test Runs trees, and the organization-level Modules tree. Moves of test-cases/test-runs folders require project_id; module folders need none.
- tm_generate_test_cases: Generate structured test cases from a requirement or prompt using the Test Manager AI generator (applies the project's Memory Layer — Project & Org Instructions — automatically) and file them into the chosen folder. Requirement documents, specs, spreadsheets or screenshots can be attached via files to ground the generation. Volume = test_scenario_limit × per_scenario_test_cases_limit, capped at 50 per call. By default all generated cases are saved into the folder (one sub-folder per scenario); pass auto_save=false to review before saving. The call returns FAST with a request_id (and a browser progress URL) — generation takes ~30-90s in the background; call this tool again with just request_id to check progress, fetch results, or save. Note: consumes AI generation credits.
- tm_create_test_case: Create a single test case in a project folder, with optional steps and references to existing step Modules (module steps are included; the Module itself is unchanged). For creating many cases from a requirement, prefer tm_generate_test_cases.
- tm_update_test_case: Edit an existing test case (fields are merged — only what you pass changes). test_steps, when given, REPLACE the case's steps; module_ids append module reference steps. Deleting test cases is not available through this connection.
- tm_create_test_run: Create a test run from chosen test cases — manual (default) or KaneAI (run_type: "kaneai"). Each included test case becomes a TEST RUN INSTANCE — the executable copy of that test inside the run, which carries its own status, remarks and exactly one Configuration. The cases must match the run type: KaneAI runs only take KaneAI-authored cases with completed code generation; manual runs only take manual cases. Optionally attach existing milestones, file into a run folder, and apply a Configuration to all instances (KaneAI configurations must be compatible with each case's platform — web/mobile-app/mobile-browser and iOS/Android).
- tm_update_test_run: Update an open test run — overall status (Passed / Failed / Skipped / In Progress), title, objective, milestones, folder, add test cases (each added case becomes a new test run instance; cases must match the run's type — KaneAI or manual), apply a Configuration to the run's instances (configuration_id; on KaneAI runs it must be kane-supported and platform-compatible with the targeted cases), toggle sequential execution (KaneAI runs), or archive it. Only open (active) runs can be updated; a closed/archived run returns a clear message. Adding cases/milestones appends, never replaces.
- tm_record_test_results: Record execution results on a MANUAL run's TEST RUN INSTANCES (the per-run copies of each test case) — max 500 per request, all-or-nothing (larger requests are rejected with nothing recorded). Manual runs only: KaneAI run results are recorded by KaneAI executions, so manual entry on a KaneAI run is rejected. Target an instance by instance_id, or just pass test_case_id and the instance is resolved automatically. Valid statuses: Passed, Failed, Skipped, Not Started (terminal — run-level "In Progress" is set via tm_update_test_run). Re-recording a step status replaces its result: an omitted step remark is cleared; response echoes per-step outcomes. Optional remarks and assignee per result, and per-step results via steps[] (mark individual test steps / BDD scenario rows Passed/Failed/Skipped with remarks, like the UI's per-step Mark Status). Note: this sets INSTANCE statuses; the run's overall status is set separately via tm_update_test_run.
- tm_create_milestone: Create a milestone in a project (status: Open), optionally with description, start/end dates, tags, and existing runs attached.
- tm_update_milestone: Update a milestone — title, description, dates, tags — or change its status (e.g. mark it Completed). Deleting milestones is not available through this connection.
- tm_link_jira_issue: Link a test case, test run, or a run result (instance) to a Jira issue (requirement / user story / epic / bug) — linked test cases are what give the issue its test coverage and traceability. Linking a result also links its case and run. Requires the Jira integration to be set up for the organization — otherwise a clear "set up Jira first" message is returned.
- tm_link_ado_issue: Link a test case, test run, or a run result (instance) to an Azure DevOps work item (requirement / user story / bug) by its URL — linked test cases are what give the work item its test coverage and traceability. Requires the Azure DevOps integration to be set up for the organization — otherwise a clear "set up Azure DevOps first" message is returned.
- getAccessibilityScanReport: Retrieve the full accessibility scan report for a completed scan by scan ID.
- getAccessibilityScanIssues: Retrieve the list of accessibility issues found in a completed scan. Optionally filter by severity.
- uploadSmartUIScreenshots: Upload screenshots to LambdaTest SmartUI for visual regression comparison. Supports PNG, JPEG, and JPG formats. Use projectToken from your SmartUI project settings.
- listHyperExecuteJobs: Retrieve a list of HyperExecute jobs for the account with optional filtering by status.
- deleteHyperExecuteJob: Delete a HyperExecute job by job ID.
- getHyperExecuteJobArtifacts: Retrieve all artifacts or categorized errors for a HyperExecute job or task.
- downloadJobArtifact: Get an authenticated download URL (plus size/status metadata) for a specific HyperExecute job artifact. Requires artefactName (from getHyperExecuteJobArtifacts); optionally scope to a task with taskId. Returns a URL to fetch with your LambdaTest credentials rather than the raw file bytes.
- getJobArtifactDetail: Get details for a specific artifact within a HyperExecute job.
- getHyperExecuteStage: Retrieve the stages of a HyperExecute task (cache/prerun/scenario/etc.). Pass a stageId to return just that one stage. Stages are keyed by their parent task, so taskId is required.
- getHyperExecuteStageLogs: Retrieve logs for a HyperExecute stage. (UNDOCUMENTED - may change without notice)
- getHyperExecuteStageTasks: Retrieve tasks for a HyperExecute stage. (UNDOCUMENTED - may change without notice)
- getHyperExecuteTask: Retrieve details for a HyperExecute task by task ID. (UNDOCUMENTED - may change without notice)
- getHyperExecuteTaskLogs: Retrieve logs for a HyperExecute task. (UNDOCUMENTED - may change without notice)
- getHyperExecuteJobLiveStream: Stream live output from a running HyperExecute job. (UNDOCUMENTED - may change without notice)
- analyzeHyperExecuteJob: Perform a full analysis of a HyperExecute job: fetches job info, sessions, traverses all tasks → scenario stages → console logs, and returns a structured report with test results, per-scenario logs, and pass/fail statistics. Use this for questions like "which tests failed and why" or "show me the console logs for job X".