# How to Use MCP for Test Automation: Practical Workflows Written by Dominik Szahidewicz Reviewed by Mariusz Wójcik Published: 2026-09-06 Updated: 2026-09-06 \[TABLE\_OF\_CONTENTS\] AI coding agents can write test code. MCP lets them go a step further: work with your actual testing system. With an MCP server connected, you can ask an agent to plan test coverage, create tests, run regression checks, investigate failures, inspect screenshots, repair selectors, and review test quality without manually moving between your editor and testing tool. This guide shows how to use MCP for web testing with BugBug, from setup to practical workflows you can use in Codex, Claude Code, Cursor, VS Code, Windsurf, and GitHub Copilot CLI. ## What does MCP add to web testing? Without access to your testing environment, an AI agent mostly works with what it can see in the codebase. It can suggest test cases or generate automation code, but it does not automatically know: * which regression tests already exist * how those tests are structured * which tests recently failed * what happened during a specific test run * what screenshots or DOM snapshots were captured * which reusable components already exist * whether a visual difference is expected * how your existing tests should be updated MCP gives the agent a structured way to access that information and take permitted actions. With BugBug MCP connected, the same AI agent you use for development can work with your BugBug tests, runs, artifacts, and documentation. The important difference is that you are not asking the agent to create a separate testing workflow. It works with the regression assets your team already uses. ## Connect your AI agent to BugBug MCP The easiest setup is the BugBug Plugin, which installs BugBug MCP together with Agent Skills. For example, for Codex: ```css npx @bugbug-io/cli plugin --agent=codex ``` BugBug Plugin supports: * Codex * Claude Code * Cursor * VS Code * GitHub Copilot CLI If you only want the MCP connection, you can connect directly to BugBug's hosted MCP endpoint: ```css https://mcp.bugbug.io/mcp ``` For example, with Claude Code: ```css claude mcp add --transport http bugbug https://mcp.bugbug.io/mcp ``` If your MCP client supports OAuth, authorize through BugBug during the connection flow. For CI or clients that cannot complete OAuth, you can authenticate with a project API token. Once connected, your agent can discover the BugBug capabilities available to it. ## Plan web test coverage before creating tests One of the simplest MCP workflows does not change anything. Ask the agent to inspect your existing BugBug project and help identify missing regression coverage. For example: > Review our existing tests and propose regression coverage for the new checkout flow. Reuse existing tests and components where possible. Don't create or modify anything yet. BugBug MCP includes the `plan-tests` workflow prompt specifically for this type of task. The agent can use product context together with existing BugBug assets to produce a test plan without immediately creating another set of duplicate tests. This is particularly useful before automating a new feature. Instead of starting from a blank prompt, the agent can account for the coverage that already exists. ### Good tasks for this workflow * Plan regression coverage for a new feature * Identify obvious gaps in an existing test suite * Check whether a new user flow overlaps with existing tests * Find reusable components before creating tests * Turn a feature description into a proposed set of E2E scenarios ![Zrzut ekranu 2026-08-27 o 15.45.06.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/Zrzut_ekranu_2026_08_27_o_15_45_06_600e491253.png) ## Create a web test from a product flow Once you know what should be covered, the agent can help turn a product flow into an actual BugBug test. For example: > Create a regression test for checkout. A logged-in user should add a product to the cart, open checkout, enter valid customer details, complete the purchase, and see the order confirmation. BugBug MCP provides the `create-test` workflow for creating tests from product or flow descriptions. You can give the agent additional constraints: > Check whether we already have a login component and reuse it instead of creating the login steps again. Or: > Create the test, but ask me before making changes to existing components. The agent can work with structured BugBug test assets rather than generating a disconnected test script that your team then has to maintain separately. ## Run existing regression tests from your AI agent MCP also makes existing tests accessible from the same interface where development work happens. You can ask: > Find our checkout regression test and run it. Or: > Run the signup tests and tell me whether anything fails. Or: > Run the relevant regression tests for the account settings flow. The agent can find the appropriate BugBug assets, start the run, inspect its status, and continue investigating if something fails. This is useful during development when you want a targeted regression check without leaving the current task to find and start the test manually. The regression test itself remains a normal BugBug test. MCP is simply another controlled way to interact with it. ## Debug a failed web test Failure analysis is where an agent with access to test evidence becomes much more useful. Instead of copying an error into your AI assistant, you can ask it to inspect the actual failed run: > Debug the latest failed checkout test and explain the most likely cause. BugBug MCP includes a predefined `debug-test-run` workflow for this. The agent can work with run information and debugging artifacts available through BugBug MCP, including: * screenshots * console logs * network logs * DOM snapshots * JUnit reports * test definitions * BugBug error-code documentation A useful debugging request can be as simple as: > Find the first failed step, inspect the available screenshot and run artifacts, and tell me whether this looks like an application bug or a broken test. You can then decide what should happen next. ![Zrzut ekranu 2026-08-27 o 15.34.43.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/Zrzut_ekranu_2026_08_27_o_15_34_43_250e62e25b.png) ## Repair a broken selector UI changes frequently break selectors without changing the actual business flow. BugBug MCP includes a `heal-step-selector` workflow designed to help investigate and repair this type of failure. For example: > Inspect the failed selector in this run. If the page changed but the intended element is still clear, propose a better selector. Show me the change before applying it. The agent can use run evidence together with BugBug's selector rules to determine what likely changed. This is an important distinction from simply telling an agent: > Make the test pass. Your instruction should preserve the intent of the test. A selector can be repaired because a button moved or its HTML changed. An assertion should not be weakened simply because the application no longer behaves as expected. For test maintenance, tell the agent explicitly what it is allowed to change. For example: > Repair selectors if necessary, but don't change assertions or expected values. That gives the agent a much narrower and safer task. ![Zrzut ekranu 2026-08-27 o 15.35.10.png](https://bugbug-homepage.s3.eu-central-1.amazonaws.com/Zrzut_ekranu_2026_08_27_o_15_35_10_9f55a6d02c.png) ## Review visual regression failures MCP can also help with visual regression analysis. The `review-visual-regression` workflow helps the agent inspect visual regression evidence and determine whether a detected difference appears expected. For example: > Review the visual regression failure from the latest dashboard test. Explain what changed and whether it looks related to the new navigation redesign. The goal is not to automatically approve visual changes. The agent first gathers and interprets the evidence, then recommends the next step — accept the change, or adjust the threshold or maximum tolerance. ## Review existing web tests Agents can be useful even when nothing is currently failing. Ask: > Review our checkout tests for maintainability and reliability. Don't change anything yet. BugBug MCP provides the `review-test` workflow for this purpose. You can use it to look for areas such as: * redundant test steps * opportunities to reuse existing components * flaky selectors * unnecessarily complicated flows * tests that are difficult to understand or maintain If you want the agent to make changes after the review, BugBug also provides a `refactor-test` workflow with explicit safety gates before mutations. A practical sequence is: > Review this test first. Give me the proposed changes. Then: > Apply recommendations 1 and 3. Leave everything else unchanged. This separates analysis from modification and keeps the scope of the agent's work explicit. ## Check the health of your regression project MCP can also be used at the project level rather than for one test at a time. BugBug provides the `report-project-status` workflow for creating a project health report from test inventory and run data. For example: > Review the current BugBug project and summarize the tests that need attention. Or: > Give me a regression health report before today's release. Highlight failing or unstable tests that should be investigated. This can make MCP useful to QA leads and product teams, not only developers working on an individual feature. ## A complete MCP web testing workflow Consider a developer finishing a new checkout change. Without MCP, the workflow might involve: 1. Finish the implementation. 2. Open the test automation platform. 3. Search for checkout tests. 4. Run the relevant suite. 5. Wait for the result. 6. Open the failed run. 7. Inspect screenshots and logs. 8. Determine whether the application or test broke. 9. Return to the code. 10. Update or rerun the test. With BugBug MCP connected to the coding agent, the developer can instead start with: > Run the relevant checkout regression tests and investigate any failures caused by my change. If something fails, the agent will perform the issue discovery with potential fixes, so the same conversation can continue: > Apply suggested fix, but don't change the assertion. Finally: > Run the test again. ## Useful prompts for MCP web test automation Here are several starting prompts you can adapt. **Plan coverage** > Review our existing tests and plan regression coverage for \[feature\]. Don't create anything yet. **Create a test** > Create an E2E test for \[flow\]. Reuse existing components where possible. **Run regression** > Find the tests related to \[feature\] and run the relevant regression coverage. **Investigate a failure** > Debug the latest failed run for \[test\]. Inspect the available evidence and explain the likely root cause. **Repair a selector** > Investigate the failed selector. Propose a more reliable selector, but don't modify assertions or expected values. **Review a test** > Review \[test\] for maintainability and reliability. Recommend changes before modifying anything. **Check project health** > Review the current regression project and tell me which tests need attention first. The more precisely you define what the agent may inspect and modify, the more useful these workflows become. ## MCP for browser control vs MCP for regression testing There are two related ways MCP appears in web testing. One is giving an AI agent direct browser-control capabilities so it can navigate pages, click elements, fill forms, and inspect a live application. The other is giving the agent access to a managed regression testing system. With BugBug MCP, the agent can work with existing test assets, recorded runs, screenshots, debugging artifacts, components, visual regression references, and test history. This matters when the goal is not simply: > Can the agent interact with this website? but: > Can the agent work with the regression coverage our team already relies on? For repeatable web testing, durable test assets become more important than a single successful browser session. > **Important note:** For the best results, use both MCPs together — browser-control MCP for exploring and interacting with the live application, and BugBug MCP for working with the durable regression assets, evidence, and history your team already relies on. ## Keep humans in control of test intent Granting an agent access to your regression system also means defining what it is allowed to change. A useful rule is to distinguish between: **Inspection** Reading tests, runs, screenshots, artifacts, documentation, and project status. **Execution** Running an existing test or suite. **Modification** Creating, editing, refactoring, importing, or deleting test assets. The consequences are different. Start with narrowly scoped instructions, review modifications, and be particularly careful when an agent proposes changes that affect assertions or expected outcomes. The purpose of test maintenance is to preserve reliable regression coverage — not merely turn failed tests green. Happy (automated) testing!