Repository navigation
Feature request: set_extra_http_headers tool for Network.setExtraHTTPHeaders #1175
Description
Activity
Hello pedrodurek! Thank you for filing this.
Thank you for the great description, it makes it easy to follow your reasoning.
We have been trying to keep the amount of tools limited and to keep the scope of individual tools rather broad. The more tools DevTools MCP offers, the more tokens are used up by it. I would therefore like to collect additional feedback on this feature request, so that we can evaluate whether this use case justifies adding one more tool
Reacted by Pedro Durek- added 3 commits that reference this issue
on Mar 19, 2026 Many companies rely on injecting custom HTTP headers for swim-lane routing in their test environments. This is a common and essential need that would greatly benefit from native support in chrome-devtools-mcp.
A common use case is frontend engineers using chrome-devtools-mcp to implement pixel-perfect designs in test environments that require swim-lane header injection for routing.Reacted by andy cao, Pedro Durek, TJ Maynes and Dairon M.@natorion What's your opinion on adding a new tool for this?
I don't like adding a new tool for this. I think it makes more sense to add it to emulate - which is semantically similar:
Instead of creating a brand-new tool, we can extend the existing emulate tool to accept an extraHTTPHeaders object.
- Why it's better: The emulate tool already acts as the central hub for page-level state modifications (e.g., userAgent, viewport,
networkConditions, geolocation). Custom HTTP headers conceptually fit perfectly alongside these other state overrides. - Context Efficiency: Minimizing the total number of MCP tools is generally a best practice. Exposing too many hyper-specific tools
increases the system prompt size and consumes token context for the LLM. - Implementation: We just extract extraHTTPHeaders from the emulate parameters and call await
page.setExtraHTTPHeaders(params.extraHTTPHeaders). To clear them, the user can pass {} or null.
Reacted by TJ Maynes and Pedro Durek- Why it's better: The emulate tool already acts as the central hub for page-level state modifications (e.g., userAgent, viewport,
I would love to see PR #1209 merged in for this request.
- added a commit that references this issue
on May 12, 2026 - added a commit that references this issue
on May 14, 2026 - added a commit that references this issue
on May 19, 2026 - added a commit that references this issue
on May 20, 2026
Feature Request
Problem
There is currently no way to set custom HTTP headers on all requests (including the initial document navigation and
<script>tag loads) via the MCP tools.The
navigate_pagetool supportsinitScript, which can interceptfetch()andXMLHttpRequestcalls at runtime. However,initScriptruns after the document is already fetched — it cannot set headers on:<script src="...">tag loads (parsed from HTML)Proposed Solution
Add a
set_extra_http_headerstool that calls Puppeteer'spage.setExtraHTTPHeaders()(which uses CDPNetwork.setExtraHTTPHeadersunder the hood).Tool definition:
Behavior:
{}networkcategory alongsidelist_network_requestsandget_network_requestUse Case
We use
chrome-devtools-mcpfor visual regression testing of a Shopify storefront widget. The widget's JS bundle is served via a<script>tag in the HTML. To test a PR branch, the storefront server needs to seeX-Promise-Tophat: <branch>on the document request to serve the branch-specific bundle URL.Currently we work around this by using a separate tool (
agent-browser) that supports--headersvia CDP. Havingset_extra_http_headersin chrome-devtools-mcp would eliminate this workaround.Implementation Notes
The implementation should be straightforward since the MCP already has access to the Puppeteer
pageobject:This is a one-liner on top of existing Puppeteer infrastructure.