Network & Mocking

Inspect network traffic, mock API responses, and test offline behavior. Inspecting requests is part of core and always available. Mocking and network state control require the network capability.

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--caps=network"]
    }
  }
}

Inspect network requests

browser_network_requests

Returns a numbered list of network requests since loading the page. Part of core — no extra capability needed.

Parameter	Type	Required	Description
static	boolean	no	Include successful static resources like images, fonts and scripts. Defaults to false
filter	string	no	Only return requests whose URL matches this regexp, e.g. /api/.*user
filename	string	no	Save the list to a file instead of returning it as text

→ browser_network_requests { filter: "api" }

  1. [GET] https://api.example.com/me => [200] OK
  2. [POST] https://api.example.com/users/create => [201] Created
  3. [GET] https://api.example.com/settings => [200] OK

  Note: 14 static requests not shown, run with "static" option to see them.

browser_network_request

Returns full details — general info, headers and bodies — of a single request, using the number printed by browser_network_requests.

Parameter	Type	Required	Description
index	number	yes	1-based index of the request
part	string	no	Return only this part: request-headers, request-body, response-headers, response-body
filename	string	no	Save the output to a file instead of returning it as text

→ browser_network_request { index: 2 }

  #2 [POST] https://api.example.com/users/create

    General
      status:    [201] Created
      duration:  45ms
      type:      fetch
      mimeType:  application/json

    Request headers
      content-type: application/json
      ...

    Response headers
      content-type: application/json
      ...

  Call browser_network_request with part="request-body" to read the request body.
  Call browser_network_request with part="response-body" to read the response body.

→ browser_network_request { index: 2, part: "response-body" }

  {"id":42,"name":"Alice"}

Binary response bodies are written to the output directory and the tool returns the file path.

Mock API responses

browser_route

Set up a route to mock network requests matching a URL pattern. When status or body is given the request is fulfilled with that response; otherwise the request continues with the header modifications applied.

Parameter	Type	Required	Description
pattern	string	yes	URL pattern to match, e.g. **/api/users, **/*.{png,jpg}
status	number	no	HTTP status code to return (default 200)
body	string	no	Response body (text or JSON string)
contentType	string	no	Content-Type header, e.g. application/json
headers	string[]	no	Headers to add to the request, in "Name: Value" format
removeHeaders	string	no	Comma-separated list of header names to remove from the request

Mock an API endpoint

You: Mock the /api/users endpoint to return two test users.

→ browser_route {
    pattern: "**/api/users",
    status: 200,
    body: "[{\"id\":1,\"name\":\"Alice\"},{\"id\":2,\"name\":\"Bob\"}]",
    contentType: "application/json"
  }
→ browser_navigate { url: "https://app.example.com/users" }

  - heading "Users" [level=1] [ref=e2]
  - list [ref=e4]:
    - listitem [ref=e5]: Alice
    - listitem [ref=e6]: Bob

Test error handling

You: Test what happens when the API returns a 503 error.

→ browser_route { pattern: "**/api/users", status: 503 }
→ browser_navigate { url: "https://app.example.com/users" }

  - heading "Something went wrong" [level=1] [ref=e2]
  - button "Retry" [ref=e5]

→ browser_take_screenshot

Remove the mock and verify recovery:

→ browser_unroute
→ browser_click { target: "e5" }

  - heading "Users" [level=1] [ref=e2]

Block resources

→ browser_route { pattern: "**/*.jpg", status: 404 }
→ browser_route { pattern: "**/analytics/**", status: 204 }

Add or strip request headers

→ browser_route { pattern: "**/api/**", headers: ["X-Debug: 1"] }
→ browser_route { pattern: "**/api/**", removeHeaders: "cookie,authorization" }

Conditional mocking with code

For complex scenarios — delays, conditional responses, request body inspection — use browser_run_code_unsafe:

→ browser_run_code_unsafe {
    code: "async (page) => {
      await page.route('**/api/search', async route => {
        const url = new URL(route.request().url());
        const query = url.searchParams.get('q');
        await route.fulfill({
          body: JSON.stringify(query === 'empty' ? [] : [{ title: 'Result: ' + query }])
        });
      });
    }"
  }

Manage routes

browser_route_list

Lists all active routes. Takes no parameters.

→ browser_route_list

  1. **/api/users (status=200, body=[{"id":1,"name":"Alice"}]..., contentType=application/json)
  2. **/*.jpg (status=404)
  3. **/analytics/** (status=204)

browser_unroute

Parameter	Type	Required	Description
pattern	string	no	URL pattern to unroute. Omit to remove all routes

Test offline mode

browser_network_state_set

Sets the browser network state. When offline, all network requests fail.

Parameter	Type	Required	Description
state	string	yes	online or offline

→ browser_network_state_set { state: "offline" }
→ browser_navigate { url: "https://app.example.com" }

  - heading "No internet connection" [level=1] [ref=e2]

→ browser_network_state_set { state: "online" }

Restricting origins

Independently of mocking, the server can be told which origins the browser may reach at all:

["@playwright/mcp@latest", "--allowed-origins=https://example.com;http://localhost:*"]
["@playwright/mcp@latest", "--blocked-origins=https://ads.example.com"]

Both take semicolon-separated lists, and the blocklist is evaluated first. These are convenience guardrails, not a security boundary — they do not affect redirects.