nodriver-mcp-server

Overview Schema Source Related Servers Discussions Admin

Route traffic through a proxy

set_proxy

Destructive

Set the browser to route traffic through a specific proxy, with optional username/password for authentication, and restart to apply the change.

Instructions

Send this browser's traffic through a proxy, with credentials if it wants them.

The proxy itself is a launch flag, so it needs a browser restart — which on an ephemeral profile also drops its cookies. Authentication is handled live: an authenticating proxy stops Chrome at a native dialog that no page and no other CDP command can dismiss, so the page just never loads and nothing says why.

Answering it means enabling the Fetch domain, which pauses every request for a round trip, so that only happens when a username is actually set. A proxy that does not ask for credentials costs nothing extra.

Call with no arguments to see what is configured. The password is never echoed back. Values set here override the NODRIVER_PROXY environment variable.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`bypass`	No	Hosts to reach directly, Chrome's own syntax, e.g. "localhost;127.0.0.1;*.internal". Empty string sends everything through the proxy.
`server`	No	Proxy to route through, e.g. "http://198.51.100.7:8080" or "socks5://198.51.100.7:1080". A bare "host:port" is treated as http. Pass "" to remove the proxy; omit it to leave the current one alone.
`browser`	No	Which browser to act on. Each name is an independent Chrome, created on first use. Omit for the shared default; parallel agents each need their own name.	default
`restart`	No	Restart Chrome now so the proxy takes effect, closing all open pages. Default true; false defers it to the next browser start.
`password`	No	Password that goes with `username`.
`username`	No	Username, for a proxy that demands authentication. Chrome ignores credentials embedded in the proxy URL, so they have to be given here.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.5.0Sep 25, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only supply destructiveHint and idempotentHint flags; the description adds substantial behavioral detail: restart drops cookies on ephemeral profiles, authenticating proxies block at an undismissable native dialog, enabling Fetch pauses requests only when a username is set, and passwords are never echoed. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than minimal, but each paragraph carries a distinct operational consequence: purpose, restart/side effects, auth tradeoffs, and read/no-echo behavior. The core action is front-loaded, and while some phrasing could be tightened, nothing is redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with six optional parameters and no enums, the description covers invocation modes, side effects, failure modes, performance impact, and environment precedence. An output schema exists, so return-value explanation is not required; an agent has enough to call this correctly and anticipate consequences.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real parameter-level meaning: calling with no arguments reads current configuration, auth handling is tied specifically to username being set, and password behavior is documented. This goes beyond the schema's property descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action on a concrete resource: 'Send this browser's traffic through a proxy', and adds credential handling, no-argument inspection, and environment-variable precedence. This makes the tool clearly distinct from siblings like set_browser_flags or block_resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear operational context: call with no arguments to see configuration, values override NODRIVER_PROXY, and the restart behavior is explained. However, it doesn't explicitly name an alternative tool or state when not to use this tool, so it falls short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server