Recipe 014

Stop Describing Websites to Your Agent — Give It a Browser

We used to paste HTML into chat and explain where the login button was, like giving directions to a blindfolded driver. Playwright MCP ends that: your agent gets its own browser — it sees pages, clicks, types, and logs in. Here's the setup, the real workflow from office automation, and the safety rules.

Here's a scene from our early office-automation days. The task: pull numbers from a partner's website every week. The agent could write the scraping code — but it couldn't see the site. So we did what everyone does: opened DevTools, copied chunks of HTML into the chat, and typed paragraphs like "there's a login form, the ID field is called user_email, then a dashboard with a table, third column is the one we want…"

Giving directions to a blindfolded driver. Every website, every time. And the moment the site changed its layout, the whole script — and the whole explanation — was garbage.

Then we gave the agent its own browser, and that entire genre of suffering ended.

The tool: Playwright MCP

Playwright MCP is Microsoft's official MCP server that hands your agent a real browser. Once connected, your agent can:

  • navigate to any URL and see the page — not as a screenshot it has to squint at, but as a structured snapshot of every button, field, link, and table on the page,
  • click, type, select, scroll — operate the page like a person,
  • fill and submit forms — including login forms,
  • take screenshots when you (or it) need visual confirmation,
  • watch network requests — often revealing a clean JSON endpoint hiding behind the messy HTML.

The magic is the snapshot. When the agent "looks" at a page, it receives the accessibility tree — the same structured view a screen reader gets. Buttons are labeled, fields have names, tables have rows. You never explain a page's structure again, because the agent reads it directly. Site changed its layout? The agent looks again and adapts — no brittle selectors to maintain, no HTML to re-paste.

Setup: one command

In a terminal (with Claude Code installed):

claude mcp add playwright npx @playwright/mcp@latest

That's it. Restart Claude Code, and your agent has browser tools. First run downloads a browser; after that it's instant.

The real workflow, from our office days

The weekly-numbers chore, rebuilt with an agent that can see:

Step 1 — Just describe the goal, not the site.

"Log into partner-portal.example.com, go to the monthly report page, and pull this month's table into a CSV."

Step 2 — The agent navigates and looks. It opens the page, takes a snapshot, and finds the login form itself. No HTML pasting. No field names from you.

Step 3 — The login, done safely. This part matters: never put passwords in the prompt. Two clean patterns:

  • Let the agent open the login page, then you type the password in the browser window and tell it to continue — the human does the secret part, the agent does the boring part.
  • Or store credentials in a local .env file the agent reads at runtime — they stay on your machine and out of the chat history (and out of any commits).

Step 4 — Extraction. The agent reads the table from the snapshot, writes the CSV, and — because it's an agent — can also diff it against last week's file and summarize what changed. The chore didn't just get automated; it got upgraded.

We're not speaking hypothetically, by the way: this very blog is operated with Playwright MCP. Every layout fix is verified by the agent opening the live site and measuring pixels; the design audit's before/after screenshots, the physics-test verdicts — all of it was the agent driving its own browser.

The honest rules

  1. Credentials stay out of prompts. See step 3. Chat history is forever; passwords in it are leaked passwords.
  2. CAPTCHAs and 2FA are human jobs. That's by design — sites use them precisely to require a person. The pattern that works: agent pauses, you solve, agent continues. Don't ask an agent to defeat them.
  3. Respect the site. Log in only where you have an account and permission, keep request volume human-ish, and check the terms of service before automating anything commercial. A good test: would the site owner mind if they watched you do this? Automate your own chores, not someone else's content.
  4. Watch the first runs. An agent with a browser is an agent with hands. Keep approval mode on until you trust the routine — the same permission dial logic as always.

Order up

Pick the web chore you're most tired of — a dashboard you check every morning, a table you copy weekly — and paste this:

I want to automate a web chore. Here's the goal: [e.g. "log into <site>, open
the monthly report, extract the main table to report.csv, and tell me what
changed vs last time"].

Rules:
1. Use your browser tools. Navigate and read the page structure yourself —
   I won't be describing the site.
2. When you hit a login or CAPTCHA, pause and let me handle it in the browser,
   then continue.
3. Never ask me to put credentials in the chat.
4. When it works end to end, save the routine as a reusable script or skill,
   and tell me exactly how to run it next time.

The first run is a conversation. Every run after that is one sentence. That's the difference between explaining a website and handing over the keys — er, the browser.

Hungry for more?

New recipes land in your inbox as they leave the kitchen. No spam, unsubscribe anytime.