🔗 MCP (Model Context Protocol)

MCP (Model Context Protocol): MCP is like a hospital's standardized equipment port — the mechanism is exact: before a standard port existed, every device (an infusion pump, a mon

MCP is like a hospital's standardized equipment port — the mechanism is exact: before a standard port existed, every device (an infusion pump, a monitor) needed its own custom connector built for each specific hospital bed; MCP defines one standard interface that any tool (a browser driver, a database reader, a ticketing system) can plug into, and any AI agent that speaks the protocol can use it without a custom integration per tool. Here is the question worth sitting with: if Claude could already "browse the web" by generating Selenium code for you to run, why do we need a SEPARATE protocol for it to control a browser directly? Because generating code you run yourself and an agent directly driving a live browser through a standardized tool interface are different capability classes — the first still requires you to execute and report results back manually; MCP lets the agent see the actual DOM or query result and decide its next action in the same loop, without you being the messenger. Java comparison: this is the same leap as JDBC standardizing "any Java program can talk to any database" instead of writing a custom driver per vendor — MCP standardizes "any AI agent can talk to any external tool," and a browser or database becomes just another JDBC-shaped connector. The QA stake: an MCP-connected agent that can query your test database directly is powerful for verifying seeded data, but the same connection is a real credential with real write access if misconfigured — the permission boundary matters exactly as much as it did for Claude Code CLI in the previous tab, just extended to external systems instead of your local filesystem.

Real Browser Control vs. Generated Code

Without MCP, asking Claude for browser automation gets you Selenium/Playwright CODE that YOU must run and report results from. With a Playwright-MCP-style connection, Claude can drive an actual browser session directly — navigate, click, read the resulting DOM — and decide its next step in the same conversation, closing the loop that previously required you as a manual relay.

Reasoning: why would a QA engineer want an agent to control a REAL browser instead of just generating a script? Because some tasks are exploratory, not scripted — "log in and tell me what breaks" has no pre-written test to run; a live-browser-connected agent can improvise the way a manual tester does, while a generated script can only execute exactly what was written in advance.

Database MCP for Test Data Verification

A database-connected MCP server lets Claude query a test database directly to verify seeded data or confirm a bug's actual state, instead of you copy-pasting query results back and forth. The same read-only-first discipline as Claude Code applies: a read-only DB connection is safe by construction, while a write-capable one needs the same review discipline as a write-capable CLI permission mode.

Step by Step: The MCP Request Flow

A task is requested in the conversation: "check if the login bug is actually fixed".

The agent decides a tool call is needed

It decides an MCP tool call is needed (e.g. browser navigation).

The MCP server executes the real action

The server opens the real page and returns the result.

The agent reads the real result

It reads the real DOM or query result and reasons about the next step.