AI Engineering

Overview

This chapter covers:

• The three questions that decide whether a task needs a server at all
• The native Chrome integration — what it does that an API connector cannot
• Plan mode’s read/write split for browser tools, and the flags that turn a read into a write
• Prompt shapes taken from the documented recipes, and what makes each one work
• The one Chrome capability worth a second thought before you use it

Before you reach for a server

Chapter 14 was the mechanism. The practical question is narrower: does this task need a server? Three checks, in order:

1. Can Bash already do it? gh, psql, aws, kubectl are all installed and Claude can run them. A server earns its place when you want typed tools rather than a command whose output has to be parsed — or when there is no CLI at all.
2. Is the problem context, not capability? “Explore how auth works” does not need a server. It needs a subagent, so the file reads land somewhere other than your window.
3. Are you already signed in to it in a browser? Then Chrome is often the shorter path than an API integration, because it inherits the session you already have.

That third one is what the rest of this chapter is mostly about.

The native Chrome integration

claude --chrome, with the Claude in Chrome extension installed, gives Claude your actual browser. Not a headless one — a visible window, running in real time, sharing your login state.

That last property is the whole point. It is why Google Docs, Gmail, Notion and your internal admin panel all work without an API connector, an OAuth app, or a token:

Draft a project update based on the recent commits and add it to my
Google Doc at docs.google.com/document/d/abc123

Claude opens the document, clicks into the editor, and types. Chrome, Edge and other Chromium browsers all work; WSL does not.

Two prerequisites catch people. You need a direct Anthropic plan — Pro, Max, Team or Enterprise — and you must be signed in with /login. Authenticate with an API key or a claude setup-token token and Chrome integration stays off even if you pass --chrome, because the extension cannot authenticate with those credentials.

What it is good at

The pattern that makes it more than automation is chaining browser work to code work in one turn:

• Live debugging — read console errors and DOM state, then fix the code that produced them.
• Design verification — build the UI, open it, check it against the mock.
• Data extraction — read a page, write a CSV locally.
• Uploads — attach a local file to a form field.

When Claude hits a login page or a CAPTCHA it stops and asks you to handle it, which is the right behaviour and worth knowing before you leave it unattended.

Plan mode splits reads from writes

Chapter 3 said plan mode blocks edits but runs classifier-approved commands. Browser tools get a cleaner version of that rule: read-only calls run without a prompt, state-changing calls ask.

The subtlety is that a flag can turn a read into a write: createIfEmpty on the tabs tool, clear on the console and network readers, save_to_disk on a screenshot. And a browser_batch runs unprompted only if every action inside it is read-only.

Uploads, and their three limits

Claude can attach local files to a page (v2.1.211+), and the restrictions are all sensible once stated:

• A Read deny rule blocks the upload. Chapter 4’s rules cover this path too — Claude can only upload a file the session may read.
• 10 MB total per upload.
• Files with multiple hard links are refused — common inside node_modules and pnpm stores. Copy it and upload the copy.

The one to think about

A recorded GIF captures everything visible in the browser, including account details on pages you are logged into. Claude Code says so explicitly, and it is worth repeating: review a recording before it leaves your team.

Two smaller notes. Enabling Chrome by default loads browser tools every session, which costs context — Chapter 8’s argument, so prefer --chrome when you need it. And the extension’s service worker goes idle in long sessions; /chrome → Reconnect extension is the fix when browser tools stop responding.

Three servers worth knowing

Beyond the built-in Chrome integration, three third-party servers come up constantly because each fixes a distinct blind spot. They are not Anthropic’s, so treat the capability lists as what the projects claim and the add commands as the interface:

Chrome DevTools — the browser as an instrument rather than a driver.

claude mcp add chrome-devtools --scope project -- npx chrome-devtools-mcp@latest

--scope project writes it to .mcp.json for the team; npx means nothing to install. Where the native integration is about doing things in a browser you are signed into, this is about reading one — console, network, DOM. The difference it makes is on a prompt like “the login form at localhost:5173 always fails, find out why and fix it”: with it, Claude opens the page, submits the form, reads the console error and the network response, then traces it back to source. Without it, Claude reads the source and guesses.

Playwright — the same browser access, aimed at tests.

claude mcp add playwright --scope project npx @playwright/mcp@latest

Cross-browser rather than Chrome-only, headless or headed, and the useful trick is that it can generate a Playwright test file from actions it just performed — walk a checkout flow once, get a spec file with the assertions and waits already in place.

Context7 — documentation newer than the model.

claude mcp add --transport http context7 --scope project https://mcp.context7.com/mcp

Note what is missing: no npx, no local process. This is a remote HTTP server, which is the shape Chapter 14 called the recommended one. It indexes current library documentation and serves the relevant section, which fixes a specific failure mode — a model confidently offering an API that moved. React Router 7’s lazy-loading API differs from v6; asking Claude to “use context7 to look up the React Router v7 docs, then refactor” gets the current pattern rather than a remembered one.

Four shapes that show up repeatedly

Once more than one server is connected, the value is in the chain rather than any single tool:

The pattern in all four: the work was never hard, it was scattered. That is the case for MCP that a single server does not make.

Prompts that work

The recipes below are the documented ones. What they have in common is worth naming before you read them: they specify the target and the symptom, and leave the procedure alone — Chapter 1’s advice, applied.

Choosing the mechanism

Four ways to get information into a session, and they are not interchangeable:

The failure mode this avoids is reaching for a server when the answer is a subagent, which is common because “connect a tool” feels like the more powerful move. It is usually the more expensive one.

Summary

• Ask whether Bash already does it before adding a server. A server earns its place through typed tools, not access.
• Three that repay setup: Chrome DevTools (read the browser), Playwright (test it, and generate the spec), Context7 (documentation newer than the model).
• The real return comes from chaining servers — the work was never hard, it was scattered.
• If the problem is context rather than capability, the answer is a subagent.
• Chrome shares your login state, which is why it reaches authenticated apps with no connector or token. It needs a direct Anthropic plan and /login — an API key or setup token disables it.
• In plan mode, browser reads run and writes prompt — but save_to_disk, clear and createIfEmpty turn a read into a write.
• Uploads respect Read deny rules, cap at 10 MB, and refuse hard-linked files.
• A recorded GIF captures logged-in page content. Review before sharing.
• Enabling Chrome by default loads browser tools into every session; prefer --chrome.
• Full reference: Chrome, common workflows, best practices.

Chapter 16 takes this off your machine: GitHub and GitLab integration, and Claude Code as a step in CI.