nodriver-mcp-server

Overview Schema Source Related Servers Discussions Admin

Create profile

create_profile

Idempotent

Create a named persistent Chrome profile to keep cookies, logins, and extensions between runs. Use unique names for concurrent browsers to reuse sessions without overwriting existing profiles.

Instructions

Create a named persistent Chrome profile — a reusable user-data dir.

A persistent profile keeps cookies, logins and Web Store extensions between runs. By default it starts with a new tab. Set restore_tabs=True to resume the last tabs, or configure new_tab / urls / restore later with set_browser_flags(startup_mode=...). It is the sturdier alternative to save_session / load_session.

Creating one is harmless by itself: nothing changes until you activate it, here or via use_profile. An existing profile of the same name is left untouched rather than overwritten. Profiles live under ~/.nodriver-mcp/profiles/.

Only one browser instance can use a given profile at a time, so give concurrent setups different names.

Input Schema

Name	Required	Description	Default
`name`	Yes	Profile name, e.g. "google-login". Only letters, digits, "-" and "_" are kept; any other character is stripped out.
`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
`activate`	No	Switch to the new profile straight away. That restarts the browser and closes all open pages. Default false, which only creates the directory.
`restore_tabs`	No	Restore the last open tabs automatically when this profile restarts. Default false (new tab). Only applies when creating a new profile; existing Chrome settings are preserved.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.6.0Oct 16, 2026

addedInput schema / properties / restore_tabs

Added value: +{
+  "default": false,
+  "description": "Restore the last open tabs automatically when this profile restarts. Default false (new tab). Only applies when creating a new profile; existing Chrome settings are preserved.",
+  "title": "Restore Tabs",
+  "type": "boolean"
+}

Changed1 schema field changedv2.5.0Sep 25, 2026

addedInput schema / properties / browser

Added value: +{
+  "default": "default",
+  "description": "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.",
+  "type": "string"
+}

First observedv1.7.2Aug 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover safety (readOnlyHint=false, destructiveHint=false, idempotentHint=true), but the description adds substantial context beyond them: non-overwriting behavior ('An existing profile of the same name is left untouched'), the storage location (~/.nodriver-mcp/profiles/<name>), the exclusivity constraint ('Only one browser instance can use a given profile at a time'), and what activation destroys (restarts browser, closes all open pages). This is exactly the extra behavioral context expected when annotations exist.

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?

Front-loaded with purpose and definition, then behavior, then constraints. Every sentence carries information, though the parenthetical about set_browser_flags is slightly wordy. Still tight and well organized.

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 4-param tool with 100% schema coverage and an output schema, the description covers all the novel behavior an agent needs: activation semantics, non-overwrite guarantee, storage location, concurrency exclusivity, and relationship to sibling session tools. Nothing essential is missing.

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 meaning beyond schema: it explains the default new-tab behavior and how restore_tabs interacts with new_tab/urls and set_browser_flags(startup_mode=...). That cross-parameter relationship is genuinely useful and not in the schema.

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?

States a specific verb+resource ('Create a named persistent Chrome profile — a reusable user-data dir') and immediately defines what a persistent profile is. It distinguishes itself from siblings by contrasting with save_session/load_session and use_profile, so an agent can tell it apart from list_profiles/delete_profile/use_profile.

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

Usage Guidelines5/5

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

Explicitly says when it creates vs when it takes effect: 'nothing changes until you activate it, here or via use_profile', names restore_tabs/new_tab/urls for later configuration, and flags concurrency via 'give concurrent setups different names'. It names the alternative (save_session/load_session) and why this one is better. This is explicit when/when-not/alternative guidance.

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

Deploy Server