Chrome DevTools MCP for .NET Repos

Trigger On

• the repo needs browser-level debugging for ASP.NET Core, Blazor, WebAssembly, or any .NET app with a web UI
• the user wants an MCP server that can inspect console output, network traffic, screenshots, traces, and DOM state
• the repo needs agent-friendly browser control instead of manual DevTools work

Workflow

1. Choose the browser mode first.

- new ephemeral browser: default when you want a clean session - existing browser: use --browserUrl or --wsEndpoint - running browser with a user profile: use --autoConnect only when Chrome 144+ and remote debugging are already enabled

1. Prefer repo-local config over ad hoc shell commands.

- store the MCP server block in the repo or agent config so every run is repeatable

1. Start from the smallest useful surface.

- use --slim when you only need navigation, JavaScript execution, and screenshots - leave the full toolset enabled when you need network, performance, or emulation

1. Be explicit about privacy and cost.

- disable usage statistics or CrUX-backed performance enrichment when policy or sensitivity requires it

1. Validate against the real app, not a mock page.

- use the app's local dev server, preview URL, or a production-like environment that reflects the bug

Deliver

• a repeatable MCP server config for the repo or agent host
• a browser connection mode that fits the environment
• a safe default for privacy, performance, and reproducibility

Validate

• npx -y chrome-devtools-mcp@latest --help prints the expected flags on the current host
• the MCP client can list the server and open a page in the target browser
• the agent can capture at least one screenshot or console/network observation from the real app
• the chosen mode matches the task: --slim for quick browser checks, full mode for debugging and performance

Related skills