What Is the Model Context Protocol (MCP)

The Model Context Protocol (MCP) is an open standard introduced by Anthropic in late 2024 that lets AI assistants connect to external tools and data sources in a uniform way. Think of it as USB-C for AI — one standardised socket so any tool can plug into any AI host without bespoke glue code. This lesson explains the protocol, the three roles in its architecture, what an MCP server actually exposes, and why it matters specifically for QA. Everything in the rest of this course sits on top of this foundation, so it pays to be precise about it.

This is a fast-moving space. The protocol shipped publicly only at the end of 2024, the official servers are still adding capabilities, and best practices for QA workflows are being figured out in the open right now. Treat this lesson as the lay of the land in early 2026 — the shape will hold, the details will keep evolving.

The problem MCP solves

Before MCP, every AI integration was a custom build. Want Claude to read your Postgres? Custom adapter. Want it to drive a browser? Different custom adapter. Want both? Two integrations, two maintenance burdens, no portability. Every time a new AI host shipped (a new IDE plugin, a new desktop app), every tool vendor had to rebuild. Every time a new tool shipped, every host had to rebuild.

MCP collapses that grid. Build a server once, and any MCP-compatible host — Claude Desktop, Claude Code, IDE plugins, custom agents — can use it. Ship a new host, and the entire library of existing servers works on day one. The portability story is the headline feature, not the wire format.

Three roles, one protocol

[ AI Host ] ── contains ──> [ MCP Client ] ── speaks MCP ──> [ MCP Server ]
                                                                    │
                                                                    └─> external system
                                                                        (browser, DB, GitHub…)

Host — the application running the AI. Claude Desktop, Claude Code, an IDE with an MCP-aware plugin. The host owns the chat surface and the model.
Client — a thin adapter inside the host. It connects to one or more MCP servers, lists their capabilities, and forwards tool calls from the model.
Server — the thing that actually does the work. Playwright MCP is a server. So is GitHub MCP, Postgres MCP, Slack MCP. Servers run as separate processes (locally over stdio, or remotely over HTTP/SSE).

The model never talks to the server directly. It calls a tool by name; the client routes the call; the server executes it; the result flows back. That indirection is what makes the protocol model-agnostic.

What a server exposes

Every MCP server can publish three kinds of capabilities:

Tools — functions the AI can call. For Playwright MCP these include browser_navigate, browser_click, browser_type, browser_snapshot. Tools are invoked with structured JSON arguments and return structured results.
Resources — read-only data the AI can fetch. Examples: a file's contents, a database row, the current page snapshot. The model decides when to read; the host can also surface resources directly to the user.
Prompts — pre-built prompt templates the host can offer to users (think slash commands). Less common day-to-day, but useful for canned workflows.

Communication is JSON-RPC: requests, responses, and notifications over either standard input/output (for local servers, the typical case) or HTTP with Server-Sent Events (for remote servers).

Why MCP matters for QA

QA work is fundamentally tool-shaped — drive a browser, query a database, read CI logs, file a bug, check Slack. MCP is the substrate that lets a single AI assistant chain those tools into one workflow. A tester can describe a flow in plain English and the assistant can navigate, query, capture, and report — across what used to be five disconnected systems.

Some testing-related servers already in the wild:

Playwright MCP (Microsoft) — browser automation, the focus of this course.
GitHub MCP — issues, PRs, branches, CI runs.
Filesystem MCP — read and write project files.
Postgres / SQLite MCPs — query test databases directly.
Slack, Linear, Notion MCPs — bug filing, ticket lookup, doc retrieval.

The combinations are the point. Reproduce this bug in Playwright, query Postgres for the affected user's row, and file a Linear ticket with the steps is one prompt away when those servers are all installed.

The MCP architecture at a glance

MCP Architecture

– Owns the chat surface and the model
– Loads MCP client(s) at startup

– Discovers tools, resources, prompts
– Routes tool calls over JSON-RPC

– Playwright MCP — browser automation
– GitHub MCP — issues, PRs, runs
– Database MCPs — Postgres, SQLite
– Slack / Linear / Notion MCPs

Browsers, DBs, APIs, files –
Reached only through the server –

⚠️ Common mistakes

Treating MCP as a Claude-only or proprietary thing. The protocol is open and model-agnostic. Servers you write or install today will work with future MCP-aware clients from any vendor — that portability is the whole point. Don't reach for a single-vendor SDK when an MCP server already exists.
Confusing tools with prompts or resources. Tools do things (call APIs, mutate state). Resources return data (files, snapshots). Prompts are templates. Mixing them up shows up as servers that should expose data as a resource but bury it inside a tool, making it harder for clients to surface naturally.
Assuming MCP replaces existing test code. MCP is a transport for AI-driven workflows. Your Playwright suite, your Jest tests, your CI pipeline — those are still the regression backbone. MCP adds an interactive, conversational layer on top; it doesn't subtract anything underneath.

🎯 Practice task

Map your current QA stack onto MCP roles. 15 minutes, no installs required.

List every external system your team touches in a typical week — browsers, GitHub, Jira/Linear, Postgres, Datadog, Slack, anything.
For each one, write down whether an MCP server already exists (search the public registry — most of the obvious ones do) or would need to be written.
Pick the two systems where AI-driven access would save the most time. For each, sketch in one sentence what a useful natural-language prompt would look like (e.g., "find the last five flaky CI runs and group them by error message").
Note which of those two prompts could be answered by a single server and which would need two or more chained together — that is the workflow MCP unlocks.

You don't need to install anything yet. The next lesson explains why Playwright MCP specifically is worth installing first, and what QA scenarios it changes the shape of.