5 MCP Servers to Add to Claude Code

Use MCP servers to investigate a broken page and file a developer-ready issue.

Introduction

30 Second Summary

A broken image can look obvious on screen while leaving almost nothing useful in a copied text summary. Without the failed requests behind it, a developer still has to repeat the investigation from scratch.

In this project, you will use Claude Code and five MCP servers to investigate the public Broken Images page. The finished workflow turns research and browser evidence into a private GitHub issue another developer can act on.

What You'll Build

You will watch the page fail in a real browser before opening a private GitHub issue with enough evidence for another developer to reproduce the defect.

By the end of this project, you'll have:

  • A text-only investigation brief that uses Context7 and Firecrawl to separate known facts from the browser evidence still missing.
  • A browser-backed diagnosis built from Playwright visual evidence, DOM findings, and failed-request details from Chrome DevTools.
  • A developer-ready investigation issue with reproduction steps, screenshots, request evidence, a diagnosis, and measurable acceptance criteria.
  • Secret Mission: Connect Notion MCP and publish the GitHub investigation as a structured page for technical and non-technical readers.

Are there any prerequisites?

You need a Mac running macOS 13 or later, internet access, an eligible Claude Code account, and accounts for Context7 and GitHub. The guide walks you through installing Node.js 24.21.0 LTS and Google Chrome. A Notion account is only needed for the optional Secret Mission.

Before We Start

Set Up Claude Code and Browser Tools

A browser-backed investigation depends on a reliable local foundation. A missing runtime or unsupported browser can make an MCP connection fail before the target page opens.

You will prepare macOS for browser automation with Google Chrome.

You will install Node.js plus Claude Code. You will then connect Playwright MCP plus Chrome DevTools MCP.

In this step, get ready to:
  • Confirm your Mac supports the browser tools.
  • Install Node.js v24.21.0 LTS plus Claude Code.
  • Connect the Playwright MCP server plus the Chrome DevTools MCP server.
Prepare macOS, Chrome, and Node.js

Chrome provides the rendered page that the browser servers inspect. Node.js provides the runtime used to start both local server packages.

  • Click the Apple menu in the upper-left corner of your screen.
  • Choose About This Mac.
  • Confirm the window shows macOS 13 or later.

✔️ I see macOS 13 or later

Your Mac supports Claude Code plus the browser prerequisites used in this project.

ⓧ I see macOS 12 or earlier

Your Mac needs a supported macOS release before the browser tools can run reliably.

  • Select System Settings from the Apple menu.
  • Click General in the sidebar.
  • Click Software Update.
  • Install macOS 13 or later if your Mac offers a compatible upgrade.
  • Return to About This Mac after the upgrade finishes.
  • Confirm the window now shows macOS 13 or later.

No Compatible Upgrade Available?

Your Mac model may not support macOS 13 or later. Help me check whether my Mac supports macOS 13 or later.

  • Press Cmd+Space to open Spotlight.
  • Type Google Chrome into Spotlight.
  • Press Enter to launch Google Chrome.

✔️ Google Chrome opens

Google Chrome is ready to provide a supported browser for both MCP servers.

ⓧ Google Chrome is missing

  • Visit the official Google Chrome download page.
  • Download Google Chrome for macOS.
  • Open the downloaded installer.
  • Complete the installation prompts.
  • Press Cmd+Space to open Spotlight.
  • Type Google Chrome into Spotlight.
  • Press Enter to confirm Google Chrome now opens.

Chrome Still Missing?

Confirm the installer finished before searching again. Help me install Google Chrome on macOS.

The two browser MCP packages require Node.js. This project uses the current LTS release shown on the official Node.js download page.

  • Press Cmd+Space to open Spotlight.
  • Type Terminal into Spotlight.
  • Press Enter to open Terminal.
  • Check the installed Node.js plus npm versions by running:
node -v
npm -v

What Do These Checks Prove?

  • The first command confirms that Terminal can find the Node.js runtime.
  • The second command confirms that npm is available for running the browser server packages.

✔️ I see v24.21.0 and an npm version

Node.js plus npm are ready for the browser MCP packages.

ⓧ I see a different Node.js version

  • Visit the official Node.js download page.
  • Download the macOS installer for Node.js v24.21.0 LTS.
  • Open the downloaded installer.
  • Complete the installation prompts.
  • Return to Terminal from earlier.
  • Check the installed versions again by running:
node -v
npm -v

What Should I See?

The first line should report v24.21.0. The next line should report an npm version.

ⓧ Command not found

  • Visit the official Node.js download page.
  • Download the macOS installer for Node.js v24.21.0 LTS.
  • Open the downloaded installer.
  • Complete the installation prompts.
  • Return to Terminal from earlier.
  • Check the new installation by running:
node -v
npm -v

What Should I See?

Terminal should now print v24.21.0 plus an npm version. Those outputs confirm that both commands are available.

Still Seeing the Previous Node.js Version?

Close Terminal after the installer finishes. Open a fresh Terminal window so the shell can detect the new installation.

If the previous version remains, help me diagnose which Node.js installation Terminal is using.

Install and authenticate Claude Code

Claude Code is the workspace that coordinates every MCP server in the investigation. Checking for an existing installation avoids replacing a working copy.

  • Return to Terminal from earlier.
  • Check whether Claude Code is installed by running:
claude --version

What Does This Check Prove?

A printed version confirms that the Claude Code command is available in your shell. You can move directly to authentication when the check succeeds.

✔️ I see a Claude Code version

Claude Code is installed. The next action authenticates it with your eligible account.

ⓧ Claude Code is unavailable

  • Install Claude Code with the recommended macOS installer by running:
curl -fsSL https://claude.ai/install.sh | bash

What Does This Command Do?

The command downloads the official Claude Code installation script over HTTPS. The script installs the native command-line application for your Mac.

  • Close Terminal after the installation finishes.
  • Open a fresh Terminal window through Spotlight.
  • Verify the installation by running:
claude --version

What Should I See?

Terminal should print a Claude Code version. That output confirms the new command is available.

🙋‍♀️ Claude Command Still Unavailable?

A fresh Terminal window usually picks up the installed command. Help me make the Claude Code command available in Terminal.

The first launch starts a browser login for an eligible account. The browser flow is the only place your account credentials belong.

  • Launch Claude Code by running:
claude

What Happens on First Launch?

Claude Code starts an interactive terminal session. It opens a browser login when authentication is required.

Claude Code requires an eligible paid or Console account. The free Claude.ai plan does not include Claude Code access.

  • Complete the sign-in flow in the browser window.
  • Return to Terminal after the browser confirms authentication.
  • Confirm the interactive Claude Code prompt is ready for input.

Authentication is complete when Claude Code accepts input in the terminal session. Your workspace can now coordinate MCP tools.

  • Press Cmd+Space to open Spotlight.
  • Type Terminal into Spotlight.
  • Press Enter to open a separate Terminal window for the server commands.
Connect the browser MCP servers

Each browser server has a distinct role in the investigation. Playwright handles repeatable navigation plus rendered-page evidence.

Chrome DevTools handles request-level plus console diagnosis. Keeping these roles separate makes the final evidence easier to trace.

  • Add the local Playwright MCP server by running:
claude mcp add playwright npx @playwright/mcp@latest

What Does This Command Configure?

  • The server name is playwright.
  • The npx command starts the local package when Claude Code needs it.
  • The current verified @playwright/mcp release is 0.0.80.

🙋‍♀️ Playwright Server Not Added?

Confirm the command uses the server name playwright plus the package name @playwright/mcp@latest.

If the command still fails, help me connect Playwright MCP to Claude Code.

  • Add the user-scoped Chrome DevTools MCP server by running:
claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest

What Does This Command Configure?

  • The server name is chrome-devtools.
  • The user scope makes this connection available across your Claude Code workspaces.
  • The current verified chrome-devtools-mcp release is 1.9.0.

🙋‍♀️ Chrome DevTools Server Not Added?

Confirm Google Chrome opens normally. Confirm the command includes the --scope user flag.

If the command still fails, help me connect Chrome DevTools MCP to Claude Code.

Before you run the final check, which two server names do you expect Claude Code to report?

  • Display the configured MCP servers by running:
claude mcp list

What Should I See?

The list should include playwright plus chrome-devtools. Their presence confirms that Claude Code has both browser server configurations.

🙋‍♀️ Missing a Browser Server?

Rerun the add command for the missing server. Keep each server name plus package name exactly as shown above.

If the server remains absent, help me diagnose my Claude Code MCP list.

That is the local foundation locked in. Claude Code can now reach both browser tools for the investigation.

Next, you will connect the research sources plus GitHub destination that turn browser findings into a complete investigation workflow.

Connect Research and GitHub Servers

Your browser foundation is ready. Playwright can reproduce visible behavior.

Chrome DevTools can expose the requests behind that behavior. Research evidence still becomes disposable when it has no destination.

Context7 and Firecrawl supply the sources for your brief. GitHub gives the final investigation a durable destination through MCP.

In this step, get ready to:
  • Connect the remote Context7 server with an API key.
  • Connect the keyless Firecrawl server.
  • Connect GitHub MCP Server with repository access.
Connect Context7

A remote MCP connection lets Claude Code use a server over the internet. Context7 uses an API key to authorize that connection.

Keep the Key Private

This key authorizes requests from your account. Keep it out of prompts and screenshots.

  • Switch back to Google Chrome from earlier.
  • Sign in to your Context7 account.
  • Create an API key from the API key area in your account.
  • Save the API key in a secure password manager.
  • Return to the Terminal app from earlier.
  • Press Cmd+T to create a separate terminal tab for the setup commands.

The next command contains your key after you replace the placeholder. Keep this terminal tab out of screenshots.

  • Connect Context7 by replacing YOUR_API_KEY in this command before you run it:
claude mcp add --scope user --header "Authorization: Bearer YOUR_API_KEY" --transport http context7 https://mcp.context7.com/mcp

What Does This Command Do?

  • The --scope user option makes Context7 available across your Claude Code workspaces.
  • The --header option sends your API key as an authorization header.
  • The --transport http option connects Claude Code to the hosted server.
  • The https://mcp.context7.com/mcp value identifies the remote endpoint.
  • Confirm that Context7 appears in Claude Code by running:
claude mcp list

What Does This Check Do?

This command reads your configured MCP servers. It also checks their connection state.

That is your first remote evidence source connected. You should see context7 listed as connected.

Context7 Not Connecting?

  • Confirm that you replaced the placeholder with the complete API key.
  • Create a new key if the saved key has been revoked.
  • Run the add command again after checking your internet connection.

Still stuck? Help me troubleshoot my remote Context7 MCP connection without asking me to share my API key.

Connect Firecrawl

Firecrawl provides the live page content for your preliminary brief. Its keyless endpoint gives this project a remote scraping connection without another credential.

  • Connect the keyless Firecrawl endpoint by running:
claude mcp add --transport http firecrawl https://mcp.firecrawl.dev/v2/mcp

What Does This Command Do?

  • The firecrawl value becomes the server name inside Claude Code.
  • The https://mcp.firecrawl.dev/v2/mcp value points to the keyless hosted endpoint.
  • The remote server supplies its tools without creating another local process.
  • Confirm that Firecrawl appears in Claude Code by running:
claude mcp list

What Does This Check Do?

The list now includes the newly configured Firecrawl connection. This gives you a visible checkpoint before you add GitHub.

You should see firecrawl listed as connected. The live-content side of your research workflow is now ready.

Firecrawl Not Connecting?

  • Check that the endpoint in the command matches the hosted keyless endpoint exactly.
  • Retry the command after confirming that your Mac has internet access.
  • Remove any API key text that you added to the keyless command.

Need another pair of eyes? Help me diagnose my keyless Firecrawl MCP connection in Claude Code.

Connect GitHub and verify all five servers

A GitHub personal access token lets the remote server act within the permissions you grant. This project needs repository access so the server can create the private investigation repository and its issue.

Protect Repository Access

This token can act on your repositories. Store it securely without copying it into Claude prompts.

  • Switch back to Google Chrome.
  • Create a GitHub account if you do not have one.
  • Sign in to GitHub.
  • Open the personal access token area from your GitHub account settings.
  • Start a new personal access token.
  • Grant the token the repo permission.
  • Create the personal access token.
  • Save the token in a secure password manager.

The next command contains your token after replacement. Never include this terminal tab in a screenshot.

  • Connect GitHub MCP Server by replacing YOUR_GITHUB_PAT in this command before you run it:
claude mcp add-json github '{"type":"http","url":"https://api.githubcopilot.com/mcp","headers":{"Authorization":"Bearer YOUR_GITHUB_PAT"}}'

How Does the GitHub Configuration Work?

  • The github value becomes the MCP server name.
  • The type field configures a remote HTTP connection.
  • The url field points to the official GitHub MCP Server endpoint.
  • The Authorization header sends the personal access token with each request.
  • Switch back to the Claude Code terminal tab from earlier.
  • Exit the current Claude Code session.
  • Restart Claude Code by running:
claude

Why Restart Claude Code?

The fresh session loads the complete MCP configuration. GitHub becomes available alongside the four servers you already connected.

Before you check, how many connected investigation servers do you expect to see?

  • Switch to the setup terminal tab.
  • Check every MCP connection by running:
claude mcp list

What Does the Final List Prove?

The command tests the configured connections from outside the interactive session. This separates server connectivity from any later prompt behavior.

You should see five connected investigation servers: playwright, chrome-devtools, context7, firecrawl, and github.

  • Inspect the saved GitHub MCP configuration by running:
claude mcp get github

What Does This Check Confirm?

This command retrieves the configuration for the server named github. It confirms that Claude Code recognizes the official remote connection.

You should see the GitHub server configuration. Keep any credential value out of screenshots.

  • Switch to the restarted Claude Code session.
  • Check Firecrawl's available tools by entering this prompt:
List the tools available from the firecrawl MCP server without calling them.

What Does This Prompt Check?

The prompt asks Claude to inspect the server tool surface without scraping a page. This confirms that the connection exposes more than a server name.

Claude should list firecrawl_search, firecrawl_scrape, and firecrawl_parse.

  • Verify the GitHub identity by entering this prompt:
Use the github MCP server to show my authenticated GitHub profile.

What Does This Prompt Prove?

A returned profile proves that the server can authenticate a real GitHub request. The result validates the token without exposing it.

You should see your authenticated GitHub identity. That completes the five-server investigation workspace.

GitHub Profile Not Returning?

  • Confirm that the personal access token still exists in your GitHub account.
  • Confirm that the token has the repo permission.
  • Restart Claude Code again after correcting the GitHub configuration.

Keep the token private while you troubleshoot. Help me diagnose GitHub MCP authentication without asking me to reveal my token.

Your five MCP servers now have distinct jobs across research, reproduction, diagnosis, and reporting. Next, you will use the research servers to build a text-only investigation brief.

Build a Text-Only Investigation Brief

Five connected MCP servers now give Claude Code several ways to investigate the target page. Your first goal is to establish what research alone can tell you.

Firecrawl can recover live page content without rendering the page. Context7 can ground the next stage in current Playwright MCP guidance.

The key question is whether a text-only result can identify which images fail after rendering. This step tests that boundary before any browser server enters the investigation.

In this step, get ready to:
  • Collect a text-only page record with Firecrawl.
  • Retrieve current Playwright MCP guidance with Context7.
  • Synthesize the findings into a four-section preliminary brief.
Collect the page text with Firecrawl

Text extraction reads content returned from the page without checking how Google Chrome renders its image elements. This gives you a clean test of what the source can establish by itself.

Why isolate Firecrawl?

Using one evidence source makes its limits visible. You can judge the extracted content before browser observations influence your conclusion.

Before you send the request, do you think the extracted text will reveal which rendered images failed?

  • Switch back to Claude Code from earlier.
  • Send a text-only scrape request by pasting this prompt:
Use Firecrawl only to scrape https://the-internet.herokuapp.com/broken_images without launching a browser.

Return:
- The page title.
- The visible text.
- Any asset references available to text extraction.

Do not use Playwright or Chrome DevTools.

What does this prompt do?

  • Firecrawl retrieves the public page content without creating a browser session.
  • The requested fields preserve the page facts that may support the investigation.
  • The final restriction keeps visual evidence outside this test.
  • Confirm the result includes a page title.
  • Confirm the result includes visible text.
  • Locate the asset references that Firecrawl returned.

You should see the title The Internet plus visible text containing Broken Images. You should also see the asset references available to text extraction.

The result cannot establish which images failed after browser rendering. That shortfall is the intended finding from this first test.

Missing part of the scrape?

  • Ask Claude to retry the scrape with Firecrawl only.
  • Keep the request limited to the public target URL.

Still stuck? Help me troubleshoot a Firecrawl scrape that omitted the page title, visible text, or asset references.

Retrieve current browser-tool guidance

Documentation gives your next investigation stage a reliable method. You need guidance for navigation, screenshots, DOM evaluation, and request inspection.

  • Ask Context7 for current Playwright MCP guidance by pasting this prompt:
Use Context7 to retrieve current Playwright MCP guidance for page navigation, full-page screenshots, DOM evaluation, and request inspection.

Include the exact current tool names relevant to each investigation task.

Do not open the target page or use a browser yet.

What does this prompt do?

  • Context7 retrieves documentation for the browser tasks required in the next investigation stage.
  • The request asks for exact tool names so each later action maps to documented functionality.
  • The final restriction preserves the text-only boundary of this step.
  • Confirm the navigation guidance names browser_navigate.
  • Confirm the screenshot guidance names browser_take_screenshot.
  • Confirm the DOM guidance names browser_evaluate.
  • Confirm the request guidance names browser_network_requests.

You should see those four tool names in the result. The guidance now gives your browser investigation a documented path.

Missing one of the tool names?

  • Ask Context7 to focus its search on current Playwright MCP documentation.
  • Request guidance for the missing investigation task again.

Need help? Help me refine a Context7 request for current Playwright MCP navigation, screenshot, DOM evaluation, and request-inspection guidance.

Build the four-section brief

An investigation brief should separate observed facts from an unconfirmed hypothesis. It should also state which evidence remains missing.

Before you ask Claude to build the brief, do you expect the available text evidence to settle the rendering failure?

  • Create the preliminary brief by pasting this prompt:
Using only the Firecrawl result and the Context7 result already in this conversation, create and display a preliminary investigation brief for https://the-internet.herokuapp.com/broken_images.

Use these exact sections:
1. Known from text
2. Relevant tooling
3. Working hypothesis
4. Missing browser evidence

Include the extracted title, visible text, and available asset references under Known from text. Summarize the Playwright MCP guidance under Relevant tooling. Label every inference in Working hypothesis as unconfirmed. State explicitly that text-only extraction cannot prove which rendered images failed under Missing browser evidence.

Do not use Playwright, Chrome DevTools, or GitHub.

What does this prompt do?

  • The first section preserves facts returned by Firecrawl.
  • The second section records the documented browser tools for later use.
  • The third section keeps interpretation separate from observed evidence.
  • The final section names the exact proof that the investigation still needs.
  • Confirm the brief contains all four requested headings.
  • Compare Known from text with the Firecrawl result.
  • Compare Relevant tooling with the Context7 result.
  • Check that Working hypothesis labels its inferences as unconfirmed.
  • Check that Missing browser evidence states the limitation of text-only extraction.

You should see a preliminary brief containing the target page, extracted content, current browser-tool guidance, an unconfirmed hypothesis, and a clearly labeled evidence gap.

That is a strong first result: your brief now separates what text extraction reveals from what a rendered browser must prove.

Brief missing a required section?

  • Ask Claude to revise the existing brief without collecting new evidence.
  • Check that each required heading appears exactly once.
  • Remove any claims that browser evidence has already confirmed.

Need another pair of eyes? Help me check whether my preliminary investigation brief separates extracted facts, tooling guidance, hypotheses, and missing browser evidence.

Your text-only brief now defines both the evidence you have and the evidence you still need. Next, you will use Playwright MCP to render the page and test the brief against visible browser behavior.

Reproduce the Broken Images in Playwright

Your preliminary brief captures the page's text. The missing proof lives in a rendered browser.

In this step, Playwright MCP will reproduce the page as a visitor sees it. You will pair a full-page screenshot with DOM load states for every image.

In this step, get ready to:
  • Capture a full-page screenshot after the target page settles.
  • Inspect every rendered image through the DOM.
  • Package the browser evidence into concise reproduction notes.
Capture the rendered page

Text extraction gave you content without a rendered surface. A full-page screenshot captures the visual symptom exactly as the browser presents it.

Before you send the prompt, do you expect the rendered page to reveal evidence that the text-only brief could not show?

  • Switch back to the Claude Code session from earlier.
  • Paste this prompt into Claude Code:
Use Playwright MCP only for this task.

Use browser_navigate to open https://the-internet.herokuapp.com/broken_images. Wait for the page to settle. Use browser_take_screenshot with fullPage enabled. Return the screenshot in this conversation.

What does this prompt do?

  • The browser_navigate tool loads the target URL inside Playwright's browser.
  • The browser_take_screenshot tool preserves the whole page when fullPage is enabled.
  • Waiting for the page to settle gives the browser time to finish attempting each image load.
  • Send the prompt.
  • Review the returned screenshot in Claude Code.

You should see the Broken Images heading. You should also see visible broken-image placeholders on the rendered page.

That closes the text-only gap: your investigation now has visual proof of the defect.

Missing the full-page screenshot?

  • Confirm that Claude used the configured playwright server for the task.
  • Ask Claude to retry after the page has settled if the capture is incomplete.

Still stuck? Help me troubleshoot the missing Playwright screenshot

Inspect every image load state

A screenshot proves what a person can see. The DOM adds machine-checkable state for each rendered image.

Before you inspect the elements, do you expect every image on the page to report the same load state?

  • Paste this follow-up prompt into the same Claude Code session:
Continue with Playwright MCP only.

Use browser_evaluate to inspect every rendered image element on the current page. Return a Markdown table with one row per image. Include the fully resolved source. Include a browser-reported load state of successfully loaded or failed.

Do not use Chrome DevTools.

How does the table strengthen the evidence?

  • The browser_evaluate tool reads the live state of the rendered page.
  • Resolved sources identify the resource represented by each row.
  • Separate load labels make successful images distinguishable from failed images.
  • Send the prompt.
  • Review every row in the returned image-state table.

You should see one row for every rendered image. Each row should include a resolved source plus a successful or failed load state.

The table turns the visible symptom into DOM evidence. Another developer can now compare the browser's result image by image.

Missing images from the table?

  • Ask Claude to repeat the evaluation against every rendered image element if the row count looks incomplete.
  • Ask for fully resolved browser values if the source column contains relative references.

Need a hand? Help me verify the Playwright image-state table

Package the reproduction evidence

A useful reproduction preserves facts that another developer can repeat. It also separates observed behavior from an unverified diagnosis.

Before you package the evidence, do you think the screenshot plus DOM table can identify the exact request-level cause on their own?

  • Paste this final prompt into the same Claude Code session:
Using only the Playwright evidence in this conversation, display the full-page screenshot. Display the image-state table. Then create concise reproduction notes for the final issue.

Include these sections:
1. Target URL
2. Reproduction steps
3. Visual evidence
4. DOM evidence
5. Evidence boundary

Reference the screenshot under Visual evidence. Reference the image-state table under DOM evidence. State whether these artifacts reveal the exact request-level cause under Evidence boundary.

Keep observed facts separate from hypotheses. Do not use Chrome DevTools. Do not invent a status code or asset path.

Why include an evidence boundary?

  • Displaying both artifacts creates a final proof checkpoint.
  • The evidence boundary tests what the screenshot plus DOM findings can support.
  • The final instruction prevents unsupported request details from entering the issue.
  • Send the prompt.

You should see the full-page screenshot above the image-state table. The table should separate successfully loaded images from failed images.

The notes should contain concise reproduction steps that reference both artifacts. The evidence boundary should leave the exact request-level cause unresolved.

You have closed the browser-evidence gap. Your reproduction package now contains visual proof plus DOM proof.

Missing part of the evidence bundle?

  • Ask Claude to display the existing screenshot plus table from the current conversation.
  • Ask Claude to remove every unsupported claim if the notes infer request details.

Need help refining the result? Help me complete the Playwright evidence bundle

Your Playwright evidence proves the visible failure without guessing at the cause. Next, Chrome DevTools will inspect the requests behind it.

Diagnose Requests and File the Issue

The Playwright MCP evidence from the last step proves that the page contains failed images. The investigation still needs the browser's request-level explanation.

Chrome DevTools MCP reveals what happened at the request layer. You will classify the failure only from evidence the browser reports.

GitHub MCP Server turns the completed diagnosis into an issue another developer can reproduce.

In this step, get ready to:
  • Capture a Chrome DevTools debugging bundle.
  • Classify the image failure from browser-reported evidence.
  • Publish the investigation as a private GitHub issue.
Capture request-level evidence

A rendered placeholder proves the visible symptom. Network requests expose the browser's asset-loading results. Console messages can add related runtime context.

Before you send this prompt, do you expect every rendered image to have a successful request?

  • Collect the request-level evidence by sending this prompt to Claude Code:
Use Chrome DevTools MCP only for this diagnostic pass.

Open https://the-internet.herokuapp.com/broken_images and wait for the page to settle.

Use list_network_requests to identify the failed requests reported by the browser.

Inspect the browser-reported details for each relevant failed request.

Use list_console_messages to collect relevant console messages from this page load.

Use take_screenshot to capture the page during this debugging session.

Return a compact evidence report containing the failed requests, their reported details, the relevant console messages, and confirmation of the debugging screenshot.

Do not guess any status code or asset path that the browser did not report.

How This Diagnostic Pass Works

  • The list_network_requests tool exposes the requests observed during the selected page load.
  • The request details connect each failed load to evidence reported by the browser.
  • The list_console_messages tool adds relevant messages from the same debugging session.
  • The take_screenshot tool preserves the visible state that accompanied those requests.
  • Review Claude's failed-request list.
  • Review the recorded details for each relevant request.
  • Review the relevant console messages.
  • Confirm the debugging screenshot shows https://the-internet.herokuapp.com/broken_images.

You now have a debugging-session screenshot plus browser-reported failed-request details. The relevant console messages complete the diagnostic evidence.

No Failed Requests in the Report?

  • Ask Chrome DevTools MCP to navigate to the target URL again.
  • Reload the page through Chrome DevTools MCP.
  • Request the network list from the latest page load.

Still missing the evidence? Help me capture failed image requests with Chrome DevTools MCP

Classify the failure from both evidence sets

The Playwright findings describe which images failed in the rendered page. The Chrome DevTools findings describe the requests behind that result.

  • Compare both evidence sets by sending this prompt to Claude Code:
Compare the existing Playwright screenshot and image-state table with the Chrome DevTools failed-request details and console messages.

Classify the image failure using only browser-reported evidence.

Organize the result under these headings:

Confirmed evidence
Classification
Suspected cause

Keep any uncertain cause clearly labeled as suspected.

Do not invent a status code or asset path that does not appear in the collected evidence.

Why Compare Both Evidence Sets?

Playwright confirms the visible symptom through the screenshot plus DOM state. Chrome DevTools supplies the request-level evidence needed to explain that symptom.

Keeping confirmed facts separate from the suspected cause makes the final issue useful without overstating the diagnosis.

  • Review the confirmed evidence in Claude's comparison.
  • Check that the classification cites the browser findings.
  • Check that any unproven cause remains labeled as suspected.

The result should separate observed facts from interpretation. No status code or asset path should appear unless the browser reported it.

Does the Classification Include Assumptions?

  • Compare every claimed failure with the Playwright image-state table.
  • Remove any status code that does not appear in the Chrome DevTools evidence.
  • Move any plausible explanation without direct proof into the suspected cause.

Need a second pair of eyes? Help me separate confirmed browser evidence from my suspected cause

Create the repository and file the issue

A private repository gives the investigation a durable home. Its issue becomes the handoff another developer can reproduce.

  • Create the private repository by sending this prompt to Claude Code:
Use GitHub MCP Server's create_repository tool to create this repository:

Name: mcp-web-investigation
Visibility: private
Initialize with a README: yes

After creation, confirm the repository name, private visibility, and README initialization.

Why Create the Repository First?

The create_repository tool creates the private destination for the investigation. Initializing a README ensures the repository has a visible starting artifact.

  • Confirm Claude reports the repository name as mcp-web-investigation.
  • Confirm Claude reports the repository as private.
  • Confirm Claude reports the README as initialized.

Solid progress. Your private repository now gives the investigation a persistent home.

Repository Creation Failed?

  • Confirm GitHub MCP Server still returns your authenticated identity.
  • Check that your connected token has repository access.
  • Keep the token out of prompts while you troubleshoot.

Need help with the connection? Help me troubleshoot GitHub MCP repository creation

The issue body brings every layer of the investigation together. It should let another developer reproduce the symptom before reading the diagnosis.

  • Create the investigation issue by sending this prompt to Claude Code:
Use GitHub MCP Server's issue_write tool with method create in the private mcp-web-investigation repository.

Set the issue title to:
Investigation: broken image requests

Build the issue body from the evidence already collected. Include these sections:

Target source URL
Reproduction steps
Playwright visual evidence
Playwright DOM evidence
Chrome DevTools failed-request details
Diagnosis or suspected cause
Measurable acceptance criteria

Use https://the-internet.herokuapp.com/broken_images as the target source URL.

Preserve the exact browser-reported details. Do not invent a status code or asset path.

Return the created GitHub issue URL.

What Makes This Issue Actionable?

The issue_write tool publishes the investigation where a developer can act on it. The reproduction steps make the symptom repeatable.

The visual evidence proves the user-facing defect. The request details support the diagnosis.

Measurable acceptance criteria define what must change before the issue can be considered resolved.

  • Copy the returned issue URL into your GitHub issue URL.
  • Confirm Claude reports the issue title as Investigation: broken image requests.

Before you open the issue, do you expect another developer to reproduce the defect from the issue alone?

  • Switch back to Google Chrome.
  • Paste your GitHub issue URL into the address bar.
  • Press Enter.

You'll see Investigation: broken image requests inside the private mcp-web-investigation repository.

The body shows the target URL plus the reproduction steps. It also shows the Playwright visual evidence plus DOM evidence.

The final sections show the Chrome DevTools failed-request details. The diagnosis stays tied to browser evidence.

The acceptance criteria describe measurable success.

Issue Missing Evidence?

  • Ask Claude to read the existing evidence before retrying issue_write.
  • Confirm the repository name matches mcp-web-investigation exactly.
  • Confirm the issue body preserves the browser-reported request details.

Need help completing the handoff? Help me create a complete GitHub investigation issue from my browser evidence

Investigation complete. The visible defect now has a browser-backed diagnosis inside a developer-ready issue.

Secret mission

Publish the Investigation to Notion

Publish your completed browser investigation as a structured Notion page for a mixed technical and non-technical audience. Preserve the evidence from GitHub while turning it into a report that project stakeholders can scan and act on.

Clean Up Your Resources

Clean Up Your Resources

No paid cloud infrastructure was created, so these project artifacts add no ongoing infrastructure charges. Your existing Claude Code plan or API usage remains separate.

Resources you used:

  • MCP connections: playwright, chrome-devtools, context7, firecrawl, github, and notion.
  • GitHub repository: the private mcp-web-investigation repository containing its README and Investigation: broken image requests issue.
  • GitHub credential: the personal access token used by the github connection.
  • Notion report: the Broken Images MCP Investigation page in your authorized workspace.

Protect Your GitHub Token

  • Keep your GitHub personal access token out of Claude prompts.
  • Keep your GitHub personal access token out of version control.
  • Revoke the token when you no longer need the github connection.

Keep everything running

No action needed. Choose this if you want to reuse the investigation workflow for another web defect.

  • Keep all six MCP connections available in Claude Code.
  • Retain the private mcp-web-investigation repository as your developer-facing investigation record.
  • Retain the Broken Images MCP Investigation page as your mixed-audience report.
  • Keep the GitHub personal access token in its secure storage location.

Pause - I'll come back to this later

Disconnect the project integrations while keeping the GitHub and Notion artifacts ready for your return.

  • Return to the /mcp management interface from earlier.
  • Disconnect playwright.
  • Disconnect chrome-devtools.
  • Disconnect context7.
  • Disconnect firecrawl.
  • Disconnect github.
  • Disconnect notion.
  • Confirm that all six project connections show as disconnected.

Your private repository and Notion report remain available when you return.

Delete - I don't want to use this again

Remove all project resources and start fresh. This clears the investigation workspace without changing the public target page.

  • Return to the /mcp management interface from earlier.
  • Remove the playwright entry.
  • Remove the chrome-devtools entry.
  • Remove the context7 entry.
  • Remove the firecrawl entry.
  • Remove the github entry.
  • Remove the notion entry.
  • Confirm that none of the six project entries remain in the MCP management list.

Claude Code no longer has the investigation servers configured.

  • Return to the private mcp-web-investigation repository on GitHub.
  • Open the repository settings area.
  • Locate the repository deletion controls.
  • Delete the mcp-web-investigation repository.
  • Complete GitHub's confirmation prompt.
  • Return to your GitHub repository list.
  • Confirm that mcp-web-investigation is no longer listed.

Deleting the repository also removes its README and investigation issue.

  • Return to the GitHub account settings area where you created the project token.
  • Locate the personal access token used by the github connection.
  • Revoke that personal access token.

The project token can no longer authenticate GitHub requests.

  • Return to the recorded Notion page URL.
  • Open the page options for Broken Images MCP Investigation.
  • Delete the investigation page.
  • Confirm that the page no longer appears in your active workspace.

Your GitHub investigation and mixed-audience Notion report are now removed.

Nice Work!

Nice Work!

You made it! Your five-server MCP investigation workflow now turns a vague page defect into a developer-ready GitHub issue backed by browser evidence.

You've learned how to:

  • Orchestrate five MCP servers in Claude Code through distinct roles across the investigation.
  • Build a source-backed preliminary brief using Context7 alongside Firecrawl. Show why text extraction cannot prove a rendered image failure.
  • Reproduce the broken images with Playwright through a full-page screenshot plus DOM image states. Diagnose the failed requests with Chrome DevTools. Publish the evidence as an actionable issue in the private GitHub repository mcp-web-investigation.
  • Secret Mission: Publish the investigation as the Broken Images MCP Investigation page in Notion for a mixed technical and non-technical audience.

Ready to quiz yourself?