Skip to main content
Glama
andresolbach

nodriver-mcp-server

by andresolbach
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get cookies

get_cookies
Read-only

List browser cookies with domain, path, and secure flag. Filter by URL to get only cookies sent to that site. Returns full cookie values, including live session tokens.

Instructions

List browser cookies with their domain, path and secure flag.

Reads the whole browser cookie jar, not just the current page, unless you pass url. Values are returned in full, so treat the output as sensitive — it contains live session tokens.

To carry these across a browser restart use save_session, or switch to a persistent profile with use_profile.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoOnly return cookies that would be sent to this URL (matching domain, path and secure flag). Empty string returns every cookie in the browser.
browserNoWhich 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

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.5.0
    • 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"
+}
  2. First observedv1.7.2

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=false, so the safety profile is covered. The description adds genuine value beyond that: the whole-jar vs. url-filtered behavior, and the sensitive nature of the output ('Values are returned in full... contains live session tokens'). This is meaningful behavioral context an agent needs before calling.

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

Conciseness5/5

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

Three short paragraphs with no filler: purpose, then scope+sensitivity, then routing to alternatives. The core action is front-loaded in the first sentence, and every sentence earns its place by adding either behavioral or routing information.

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 two-optional-parameter, read-only tool with a present output schema and full schema coverage, the description covers everything an agent needs: what it returns, its scope, sensitivity, and when to use alternatives instead. The output schema handles return-value details, so nothing is missing.

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

Parameters3/5

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

Schema coverage is 100% and both parameter descriptions are already thorough (url's domain/path/secure matching semantics, browser's independent-Chrome behavior). The description reinforces the url scope ('unless you pass url') but adds no new parameter-level meaning beyond the schema, so the baseline 3 applies.

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 verb and resource — 'List browser cookies with their domain, path and secure flag' — and immediately clarifies scope ('Reads the whole browser cookie jar, not just the current page'). This distinguishes it from sibling write/delete tools like set_cookie and clear_cookies, and from persistence tools like save_session.

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?

The final sentence gives explicit when-not guidance: 'To carry these across a browser restart use save_session, or switch to a persistent profile with use_profile.' This names the alternatives and the condition that selects them. The url parameter is also framed as a scoping choice (whole jar vs. filtered).

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

Deploy Server

Other Tools