Connect a tool with MCP
MCP lets Claude use tools that belong to another program — a browser, a database, an API. One server, added twice: once for yourself, once for the whole project, committed and pinned.
01The goal
Connect an MCP server for yourself at local scope, then share it with the project as a committed .mcp.json — pinned to one version, with its outbound data flows turned off.
02The idea
MCP — the Model Context Protocol — lets Claude Code use tools that another program provides. The program is an MCP server; it runs on your machine (or remotely), and its tools appear in Claude’s hands like built-ins. This lesson’s server is Chrome DevTools MCP: it drives a Chrome browser, so Claude can open a page, read its console, take a screenshot — the difference between "Claude says the button should work" and "Claude watched the button not work".
| Scope | Who gets it | Stored in |
|---|---|---|
| Local — the default | You, in this project | ~/.claude.json |
| Project | Everyone who works in the project | .mcp.json at the project root, committed |
| User | You, in every project | ~/.claude.json |
In an interactive session, Claude Code asks you to approve a project’s servers before it uses them — a prompt worth reading, because a server is code that runs on your machine and hands Claude new tools. A claude -p run cannot show that prompt and loads project servers without asking, which is the second reason .mcp.json is a reviewed, committed file rather than a convenience.
One warning before the commands, and it is the lesson’s: by default this particular server sends usage statistics to Google, may send trace URLs to Google’s CrUX API, and checks npm for updates. Everything the pages Claude opens still load from the web, and the server shows Claude everything in that browser. So this lesson pins the version and turns all three flows off — and that is the default stance for any third-party server: read what it sends, then decide.
03The walkthrough
- 01Save a page to look at — any small HTML file with a console.warn in it will do; park it somewhere scratch.
- 02Add the server at local scope, configured before it ever runs: claude mcp add --env CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS=1 --transport stdio chrome-devtools -- npx -y chrome-devtools-mcp@1.10.1 --isolated --no-usage-statistics --no-performance-crux. Read it right to left: the name, then — after the double dash — the server’s own command. The version is pinned, --isolated gives the browser a throwaway profile, and the flags and the variable turn the three data flows off.
- 03claude mcp get chrome-devtools shows which scope holds it — local here — and the server’s status.
- 04Start claude and run /mcp: the server is listed with its tools. Then ask: "Use the chrome-devtools tools to open the scratch page as a file: URL, and tell me its title and console messages." A Chrome window opens; Claude reports the title and the warning. In manual mode, the first use of each tool asks permission — approve the reads.
If you ever need the approval prompt back — you declined a server and want to reconsider — claude mcp reset-project-choices clears the project’s saved choices and the prompt returns on the next session.
04Your turn
Move the server from yours to everyone’s. Remove the local copy, which would otherwise shadow the project entry: claude mcp remove chrome-devtools --scope local. Then write .mcp.json at the repository root, translating the command you ran — type stdio, command npx, and the args array carrying the pinned version and the flags, with the env object holding the update-check variable. Commit it. Start a session; when it asks about the new MCP server found in this project, read the prompt and approve it, then confirm with /mcp that it connects. Ask Claude to open the scratch page and save a screenshot of it. Delete the local scratch page afterwards; the committed .mcp.json is the deliverable.
Hold the review habit. A third-party server can run code on your machine and give Claude new tools; read what it is and what it sends before it joins the project, and treat a .mcp.json change in a pull request with the seriousness of a dependency bump — it is one.
Where does a project-scope MCP server live?
- A~/.claude.json
- BManaged settings
- C.mcp.json at the project root, committed
→Check your answer
Project scope is the shareable one: the file is committed, reviewed like code, and every collaborator gets asked to approve it.
What does a claude -p run do with a project’s servers?
- ASkips them all
- BAsks once, then never again
- CLoads them without asking
→Check your answer
Headless runs cannot show the approval prompt, so project servers load silently — the reason the committed file must be reviewed before it merges.
Why does the lesson pin the server to an exact version?
- AReproducibility — a commit that changes behaviour silently is unreviewable
- Bnpx refuses @latest
- CPinned servers skip the approval prompt
→Check your answer
A floating version means yesterday’s reviewed config and today’s running code can differ. Pinning makes the commit the truth — and the flags stay off whatever ships.