Skip to content

Feature request: set_extra_http_headers tool for Network.setExtraHTTPHeaders #1175

Description

@pedrodurek

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_page tool supports initScript, which can intercept fetch() and XMLHttpRequest calls at runtime. However, initScript runs after the document is already fetched — it cannot set headers on:

  • The initial HTML document request (navigation)
  • <script src="..."> tag loads (parsed from HTML)
  • CSS, image, and font loads

Proposed Solution

Add a set_extra_http_headers tool that calls Puppeteer's page.setExtraHTTPHeaders() (which uses CDP Network.setExtraHTTPHeaders under the hood).

Tool definition:

name: set_extra_http_headers
description: Set extra HTTP headers to be sent with every request. Headers persist until cleared. Pass an empty object to clear.
schema:
  headers:
    type: object
    description: "Header name-value pairs, e.g. {\"X-Custom\": \"value\"}"

Behavior:

  • Headers apply to ALL subsequent requests on the selected page (document, scripts, fetch, XHR, images, etc.)
  • Headers persist across navigations until explicitly cleared with {}
  • Fits naturally in the existing network category alongside list_network_requests and get_network_request

Use Case

We use chrome-devtools-mcp for 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 see X-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 --headers via CDP. Having set_extra_http_headers in chrome-devtools-mcp would eliminate this workaround.

Implementation Notes

The implementation should be straightforward since the MCP already has access to the Puppeteer page object:

// In tools/network.ts
await page.setExtraHTTPHeaders(params.headers);

This is a one-liner on top of existing Puppeteer infrastructure.

Activity

  1. added theissue type on Mar 17, 2026
  2. wolfib commented on Mar 17, 2026

    @wolfib
    Contributor

    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

  3. added 3 commits that reference this issue on Mar 19, 2026
    8a4cf38
    7da4fe2
    31991bc
  4. JayeeHsu commented on Mar 20, 2026

    @JayeeHsu

    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.

  5. wolfib commented on Mar 20, 2026

    @wolfib
    Contributor

    @natorion What's your opinion on adding a new tool for this?

  6. natorion commented on Mar 20, 2026

    @natorion
    Contributor

    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.
  7. tjmaynes commented on Mar 25, 2026

    @tjmaynes

    I would love to see PR #1209 merged in for this request.

  8. added a commit that references this issue on May 12, 2026
    f3519bb
  9. added a commit that references this issue on May 14, 2026
    0435fb6
  10. added a commit that references this issue on May 19, 2026
    d142b33
  11. added a commit that references this issue on May 20, 2026
    6992106
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions