Model Context Protocol (MCP) gives an AI client a standard way to discover approved data and tools. For QA, this can connect an agent to browsers, APIs, repositories, databases, files and test systems without building a separate integration for every model.
On this practical guide
MCP in simple terms
| Part | Responsibility | QA example |
|---|---|---|
| Host | The AI application that manages the user experience and permissions. | An IDE, coding agent or desktop AI application. |
| Client | The connection inside the host that communicates with one MCP server. | A Playwright MCP connection configured in the IDE. |
| Server | Exposes defined capabilities to the client. | A server for browser actions, GitHub, a database or test management. |
| Tools | Actions the model may request. | Navigate, click, query, create an issue or read a file. |
| Resources | Context that can be read. | Requirements, schemas, logs or project documentation. |
| Prompts | Reusable interaction templates supplied by a server. | A standard defect triage or API analysis workflow. |
MCP is a connection standard, not the intelligence: the model decides what to request, while the server defines what data and actions are available.
Useful QA agent patterns
Browser agent
Explore a flow, collect page state, reproduce a defect or draft a test.
API agent
Read a contract, send controlled requests and compare responses with expectations.
Database agent
Run approved read-only queries to verify state after an operation.
Repository agent
Inspect changes, locate related tests and prepare a reviewed pull request.
Evidence agent
Collect logs, traces, screenshots and CI results into a concise report.
Test management agent
Read requirements, draft cases or update approved execution records.
Choose the right level of autonomy
| Level | Agent behaviour | Suitable examples |
|---|---|---|
| Read-only | Retrieves and summarises information. | Inspect CI failures, requirements or database state. |
| Suggest | Prepares a plan, query, test or patch for approval. | Draft test cases, SQL or a locator fix. |
| Act with approval | Requests confirmation before a consequential tool call. | Create a Jira defect or push a branch. |
| Bounded autonomous | Performs a narrow workflow within explicit limits. | Run a tagged test suite and attach evidence. |
Start with read-only or suggestion mode. Increase autonomy only after the workflow is predictable, auditable and covered by recovery controls.
A reliable agent workflow
- Define the outcome. State what “done” means and what evidence is required.
- Select trusted context. Provide the current requirement, contract and project rules.
- Allow minimum tools. Expose only the servers and operations needed.
- Plan before acting. Ask the agent to identify steps, assumptions and high-impact actions.
- Execute in small stages. Inspect outputs between data access, action and reporting.
- Validate independently. Run tests, query final state and compare with the source of truth.
- Record evidence. Keep tool results, diffs and approvals linked to the work item.
Example: browser exploration with Playwright MCP
Playwright MCP lets compatible clients interact with a browser using structured page information. A typical local configuration resembles this:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["@playwright/mcp@latest"]
}
}
}
The exact configuration location depends on the client. Review the package and pin an approved version for shared or controlled environments.
Explore the checkout flow in the approved test environment.
Boundaries:
- Do not place a real order
- Do not leave the application domain
- Use only the supplied test account
- Do not change persistent customer data
Tasks:
1. Map the main states and validation rules
2. Record accessibility-based element descriptions
3. Propose positive, negative and boundary scenarios
4. Return evidence and open questions
Stop before any destructive or billable action.
Example: controlled data verification
Goal: Verify order ORD-123 after cancellation.
Allowed tools:
- API: GET requests only
- Database: approved read-only queries
- Files: write the final Markdown report only
Expected checks:
- API status is "cancelled"
- cancelled_at is populated
- payment refund reference exists
- audit event contains the acting user
Do not update data. If sources disagree, stop and report the
conflicting values with timestamps.
Security and governance checklist
- Use servers from trusted publishers and verify the package or endpoint.
- Allowlist approved servers and tools at organisation level where possible.
- Use least-privilege accounts, scopes and database roles.
- Separate development, test and production credentials.
- Keep secrets in an approved secret store, never in prompts or committed files.
- Restrict browser domains, file paths, commands and network destinations.
- Require approval for writes, deletions, payments, deployments and external messages.
- Treat content returned by tools as untrusted input that may contain prompt injection.
- Log tool requests, outputs, approvals and final state without exposing sensitive data.
- Define time, request and cost limits to stop runaway loops.
What to test in an MCP agent
| Area | Checks |
|---|---|
| Tool selection | Chooses the correct tool and avoids unrelated capabilities. |
| Arguments | Uses valid, complete and safe parameters. |
| Permissions | Cannot access forbidden data, paths, projects or operations. |
| Approvals | Stops at the correct point and clearly describes the intended action. |
| Failure handling | Handles timeouts, partial results, unavailable servers and invalid responses. |
| Prompt injection | Does not follow hostile instructions found in pages, issues or files. |
| Idempotency | Retries do not create duplicate defects, records or messages. |
| Auditability | Produces enough evidence to reconstruct important decisions and actions. |
Troubleshooting MCP connections
- Confirm the client supports the server's transport and configuration format.
- Run the server manually and inspect its startup error.
- Check the executable, package version, arguments and working directory.
- Confirm required environment variables exist without printing their values.
- Check authentication scopes and organisation policies.
- List available servers and confirm the expected tools are discovered.
- Try one harmless read-only tool call with minimal arguments.
- Inspect client and server logs for protocol, timeout or schema errors.
- Restart the client after changing configuration.
Useful links
- Model Context Protocol introduction ↗ — official concepts and architecture.
- MCP tools ↗ — discovery and tool execution concepts.
- Playwright MCP ↗ — browser-agent setup and examples.
- GitHub MCP Server ↗ — current GitHub setup guidance.
- MCP security best practices ↗ — threats and safeguards.