TestMu AI MCP. Audit cross-browser builds & debug sessions from chat.

Listen up. TestMu AI MCP Server lets your agent audit cross-browser test builds and dig into failure context right from your IDE. It's built to handle all that messy, complex debugging work so you don't have to manually jump between ten tabs.

When you need to know what happened with a build, you can list all completed or running test automation builds using list_builds. This function retrieves grouped telemetry data for multiple major browser testing frameworks—whether it’s Selenium, Playwright, or Cypress—all tied back to your primary CI/CD build IDs. If you're checking specific details on one run, you can fetch precise telemetry data for a single LambdaTest build run using get_build.

To narrow down the scope, your agent can extract a complete list of individual test sessions associated with a parent Build ID via get_build_sessions. For basic status checks on recent runs, you'll get fundamental details like OS, browser, and duration for automated test sessions by calling list_sessions. If you want to audit your local setup before running tests, the server lists all active secure Tunnels connected for development purposes with list_tunnels, and it can also return a list of every combination of macOS, Windows, iOS, and Android versions available in the testing grid using list_platforms.

When you pinpoint the exact failing test run, you'll gather deep debugging information for that specific automated test session by invoking get_session. This function doesn't just give you a status code; it provides crucial data like console errors and network traffic logs. You can also pull raw command-level execution logs—those precise, time-stamped Selenium or Appium commands—by calling get_session_logs for the defined session.

To figure out what caused the failure, you'll retrieve visual bug screenshots captured during the test session using get_screenshots. Furthermore, if you need to see exactly how something broke, the server retrieves the full video recording URL of an entire failed execution via get_video. To isolate problems in a large deployment, you can fetch telemetry for child sessions under specific parent CI/CD builds, letting you pinpoint exact regression spots.

This whole setup means that instead of just seeing 'Failed,' your agent gives you the full picture: it shows you why it failed. You use these tools to check build status (list_builds), narrow down the session list (get_build_sessions), grab the raw context and errors (get_session and get_session_logs), get proof of the failure (screenshots via get_screenshots, videos via get_video), or just verify if your target platform even exists (list_platforms).

It’s everything you need to debug, nothing you don't.