MCP and Agent Skills for testing workflows

9 min read · Reviewed May 2026 · mcp

Playwright MCP gives a coding agent browser automation. But a test is not just a browser interaction — it starts with a ticket, draws on an existing test plan, and ends with a results record somewhere. MCP servers and Agent Skills bridge the coding agent across those tool boundaries. Agent Skills, published as an open standard for cross-platform portability in December 2025 (not just an Anthropic product feature), make this composability real rather than theoretical. As of May 2026, a single agent invocation can read a Jira ticket, inspect merged code on GitHub, scaffold tests against your repo conventions, validate them against a live browser session, and open a draft PR — without the engineer switching between four tools.

READ TIME9 min
DIFFICULTYintermediate
REVIEWEDMay 2026
YOU'LL LEARNHow MCP and Agent Skills compose into a working test pipeline that crosses tool boundaries — Jira ticket to merged PR.

The MCP + Skills architecture for testing

One coding agent, multiple MCP servers, one set of Agent Skills — the composition pattern that spans tool boundaries.

The standard architecture places the coding agent at the top of a stack of MCP servers. Each server exposes a different tool surface: Jira for issue context, GitHub for repository and PR operations, TestRail for test plan reading and result writing, Playwright for browser automation. The agent picks the appropriate server per turn — reading from Jira, writing to GitHub, and driving Playwright in the same session — without the developer managing context-switching between tools.

Agent Skills sit alongside this stack: they are folders of instructions and scripts the agent loads on demand, encoding team-specific knowledge such as "how to author a Playwright test in this repository" or "how to package test evidence for a PR". The combination of MCP servers (tool access) and Agent Skills (encoded knowledge) is what makes the pipeline cross tool boundaries rather than stopping at browser automation.

Architecture diagramSystem architecture showing components and their connectionsCoding agentJira MCPGitHub MCPTestRail MCPPlaywright MCPJira APIGitHub APITestRail APIBrowser
Coding agent composed with MCP servers for full-workflow testing

MCP — what shipped

A multi-vendor protocol with real adoption — Claude Code, Cursor, and VS Code all support MCP clients as of May 2026.

Model Context Protocol (MCP), published at modelcontextprotocol.io, is the communication standard that allows a coding agent to call external tools through a structured interface. It is not proprietary to any one vendor: Claude Code, Cursor, VS Code with the Copilot extension, and several other coding agents all support MCP as a client. The server side is equally open — any team can publish an MCP server for their internal tools using the public specification.

Playwright MCP (github.com/microsoft/playwright-mcp) has 32.7k stars as of May 2026, making it the de-facto browser-automation MCP server. Microsoft publishes and maintains it, and it exposes the full Playwright API surface through the MCP protocol. For automation teams, it is the natural starting point for any agent-driven browser workflow.

The composition pattern is what makes MCP useful at the workflow level rather than just the individual-tool level. One agent, multiple MCP servers, the right server called per turn. This is different from scripting API calls in sequence — the agent decides which server to call based on what it needs next, not from a predetermined script. A Jira ticket that references an existing test plan triggers a TestRail read; a TestRail plan that references browser flows triggers a Playwright session. The agent routes between servers without explicit orchestration code.

Agent Skills — what changed

From Anthropic product feature to open standard — the December 2025 update made Agent Skills portable across platforms.

Agent Skills were initially a capability within Claude Code specifically. In December 2025, Anthropic published Agent Skills as an open standard — the headline change being cross-platform portability. A skill authored for Claude Code can, under the standard, run in any agent platform that implements the specification. See claude.com/blog/skills for the original announcement and the December 2025 open-standard update.

For testing workflows, Agent Skills serve as packaged team knowledge: a "playwright-test-author" skill that carries the team's selector conventions, wait patterns, and file-naming rules; a "test-plan-from-ticket" skill that reads a Jira ticket and produces a structured test plan matching your team's format; an "evidence-package" skill that bundles screenshots and trace files into a PR description template.

The practical benefit is that skills encode the context that would otherwise need to be re-stated in every prompt. Instead of beginning every agent session with three paragraphs of project context, the skill carries that context and activates on demand. This is the complement to the prompt patterns described in the authoring guide: prompt patterns are human-authored and iteratively refined; Agent Skills are the package that delivers them reliably and consistently across the team.

A practical pipeline

One agent invocation, four MCP servers, one skill — from Jira ticket to draft PR without switching tools.

The following pipeline is achievable today with Claude Code, the publicly available MCP servers for Jira, GitHub, and Playwright, and a custom Agent Skill encoding your team's test-authoring conventions. It is not a hypothetical architecture — teams have described assembling exactly this stack in engineering blogs published in Q1 2026.

The developer assigns a Jira ticket to the coding agent. The agent uses the Jira MCP server to read the ticket's acceptance criteria and linked specifications. It uses the GitHub MCP server to inspect code merged in the relevant feature area over the last two weeks, establishing what changed. It loads the "playwright-test-author" Agent Skill, which supplies the team's selector hierarchy, assertion patterns, and file-naming conventions. It scaffolds one or more test files, then uses Playwright MCP to run them against a live browser instance and confirm they pass. The agent uses the GitHub MCP server to open a draft PR with the Jira ticket number in the description.

The entire loop is one agent invocation. The developer's contribution is reviewing the PR and validating that the assertions check the right things — the part that requires domain knowledge and cannot be delegated.

Security and permissions

MCP server credentials are agent credentials — scope them like CI runner secrets.

MCP servers inherit the credentials of the agent session that calls them. A GitHub MCP server configured with a personal access token that has repository write access can merge pull requests on your behalf. A Jira MCP server with project-admin permissions can close tickets, delete sprints, or modify issue types. This is expected protocol behaviour, not an edge case.

The appropriate model is the same as for CI runner secrets: each MCP server should be configured with the minimum credentials required for the intended tasks. A test-authoring pipeline needs GitHub read (for repository context) and GitHub write (for draft PRs). It does not need merge permissions, branch-protection overrides, or organisation-level access. Least privilege is the default, not an optional hardening step to add after the first incident.

// NOTE

MCP servers run with the agent's credentials. A Jira MCP server with write permissions can close tickets on your behalf. A GitHub MCP server with merge permissions can merge PRs. Audit MCP server permissions like you audit CI runner secrets — least-privilege is the default, not optional hardening.

Related glossary terms