MCP for QA Workflows

An AI assistant on its own can only read and write text. To be useful in testing it needs to reach things: a browser, the test results, the bug tracker, logs, an API. Before MCP, every assistant had its own way of plugging in tools, so each integration had to be built again for each product.

The Model Context Protocol (MCP) is an open protocol, introduced by Anthropic in November 2024, that standardises how AI applications connect to tools and data. A capability is packaged once as an MCP server, and any MCP-compatible client can use it.

The architecture

┌──────────────── Host application ────────────────┐
│  (an AI chat app, IDE assistant or agent)         │
│                                                   │
│   MCP client ──────┐   MCP client ──────┐         │
└────────────────────┼────────────────────┼─────────┘
                     │                    │
              MCP server            MCP server
            (browser via         (test results,
             Playwright)          bug tracker...)

• Host: the application the user interacts with, which contains the model integration.
• Client: a connector inside the host that maintains a connection to one server.
• Server: a program that exposes capabilities over the protocol.

Messages use JSON-RPC 2.0. Servers can expose three main kinds of capability:

• Tools: functions the model can call, such as “navigate to a URL” or “fetch failed tests for run 123”. Each tool has a name, a description and a JSON Schema for its inputs.
• Resources: data the application can read into context, such as a file, a test report or a database record, identified by URIs.
• Prompts: reusable prompt templates the server offers, such as “write a bug report from this failure”.

Transports

MCP defines two standard transports:

• stdio: the client starts the server as a local child process and talks to it over standard input and output. Typical for local tools such as a browser on your machine.
• Streamable HTTP: the server runs as an independent process, local or remote, and clients connect over HTTP. Used for shared or hosted servers. (It replaced an earlier HTTP-with-Server-Sent-Events transport.)

What a tool call looks like

You rarely write these messages by hand, but seeing one demystifies the protocol. The client discovers tools with tools/list, and the model’s choice becomes a tools/call request:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "browser_navigate",
    "arguments": { "url": "http://localhost:3000/login" }
  }
}

The server performs the action and returns a result containing content, typically text, that goes back into the model’s context as its observation.

Playwright MCP

Playwright MCP (the @playwright/mcp package from Microsoft) is an MCP server that gives an AI client a real browser driven by Playwright. Its tools cover navigation, clicking, typing, selecting options, taking snapshots, handling tabs and dialogs and more, with names such as browser_navigate, browser_click and browser_snapshot. The exact tool list changes between versions, so check the project’s README.

Accessibility snapshots instead of screenshots

By default, Playwright MCP describes the page to the model using a structured accessibility snapshot: the roles, accessible names and states of elements, with references the model uses to target them. It does not rely on screenshots and a vision model by default. That has practical advantages:

• Snapshots are text, so they are cheaper and faster for the model to process than images.
• Actions target elements deterministically by reference instead of guessing pixel coordinates.
• The representation mirrors how role-based locators work, so what the model sees translates well into getByRole locators in a generated test.

A side effect testers will appreciate: if elements lack accessible names or roles, the model struggles too. Poor accessibility shows up quickly.

Configuring it

Many MCP clients use a JSON configuration with an mcpServers object. A common shape for Playwright MCP is:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

This tells the client to start the server over stdio using npx. Where this file lives depends on the client: desktop chat apps, IDEs and command-line agents each have their own settings location, and some use a different top-level key (VS Code’s mcp.json, for example, uses servers). Some clients also provide a command to add servers instead of editing JSON. Follow your client’s MCP documentation.

The server supports command-line options for things like running headless, choosing the browser and enabling extra capabilities such as screenshot-based interaction; see npx @playwright/mcp@latest --help for the options in your version. For repeatable team setups, consider pinning a specific version rather than @latest.

QA workflows where MCP helps

Exploratory assistance

Ask the assistant to walk a flow in a local or staging build and report anything unexpected: validation messages, console errors, broken links, missing labels. You stay in charge of what is a bug.

From exploration to a real test

A productive pattern:

1. Ask the assistant to perform a flow through Playwright MCP (“log in as the test user, add a product, apply the coupon SAVE10, go to checkout”).
2. Ask it to write a Playwright test reproducing that flow using role-based locators and web-first assertions, following your project’s conventions.
3. Review, run and break the test to prove it can fail, then commit it.

The MCP session is disposable; the reviewed test is what lasts.

Reproducing bug reports

Give the assistant a bug report and ask it to reproduce the issue, record the exact steps and capture console and network errors. If it cannot reproduce, that is useful information too, as long as you verify it.

Connecting test data and systems

Beyond the browser, MCP servers exist or can be built for issue trackers, repositories, databases and observability tools. A QA-focused setup might let an assistant read the latest test run’s failures (resource), look up related issues (tool) and draft a bug report from a template (prompt). Only connect systems your organisation has approved.

Testing your own MCP servers

If your team builds an MCP server, test it like any API. The MCP Inspector (npx @modelcontextprotocol/inspector) is a developer tool for connecting to a server, listing its capabilities and calling tools interactively. Add automated tests for each tool’s input validation, error handling and permissions.

Security

Specific risks and mitigations:

• Prompt injection through content: a web page, issue description or log line can contain text written to manipulate the model (“ignore your instructions and…”). Anything a tool returns is untrusted input. Keep humans approving sensitive actions.
• Over-broad tools: a server that can run arbitrary shell commands or SQL gives the model that power. Prefer narrow, purpose-built tools with read-only access where possible.
• Credentials: pass secrets through environment variables or the client’s secret handling, scoped to test accounts; never put production credentials in an MCP config file that might be shared or committed.
• Untrusted servers: a malicious server can describe its tools misleadingly or return manipulative content. Review third-party servers before use, and pin versions.
• Tool-call approval: many clients ask before running a tool. Leave confirmation on for anything that writes, deletes or sends.

Practice exercise

Your team wants a setup where an assistant can (a) drive a browser against the staging site and (b) read the latest CI test results. Describe the MCP servers you would configure, the configuration for the browser part, and five safety rules for the setup.

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

Key takeaways

• MCP is an open protocol (introduced by Anthropic in November 2024) standardising how AI applications connect to tools and data.
• Hosts contain clients; each client connects to a server exposing tools, resources and prompts over JSON-RPC.
• Standard transports are stdio (local processes) and Streamable HTTP (independent or remote servers).
• Playwright MCP gives assistants a browser and uses accessibility snapshots rather than screenshots by default.
• Config shapes and file locations vary by client; mcpServers with command and args is a common pattern.
• Treat tool output as untrusted, use narrow and read-only tools, test accounts and human approval for risky actions.