Skip to main content
Glama
andresolbach

nodriver-mcp-server

by andresolbach
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

List sessions

list_sessions
Read-only

List saved browser sessions with their save time and contents, showing cookie and localStorage counts, to help you choose which session to load.

Instructions

List saved session files with their name, save time and contents.

Shows the filename to hand to load_session, along with how many cookies and localStorage entries each one holds, newest first.

Sessions live in ~/.nodriver-mcp/sessions/ and are never cleaned up automatically, so old logins accumulate there over time.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds genuine value beyond that: sessions persist in ~/.nodriver-mcp/sessions/, are never cleaned up automatically, and accumulate over time — a meaningful behavioral disclosure about side effects of the feature (disk growth, stale logins) that annotations do not express.

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 sentences with zero filler: the core action is front-loaded in the first sentence, the output's purpose follows in the second, and the storage/retention context in the third. Every sentence earns its place.

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 simple read-only listing tool with one documented optional parameter and an output schema, the description covers everything an agent needs: what is listed, ordering, how the result feeds a sibling workflow, and the storage location. Return-value details are already handled by the output schema, so nothing critical 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 description coverage is 100%: the single optional 'browser' parameter is already fully documented in the schema, including guidance on parallel agents needing distinct names. The description adds no parameter-level detail, but per the rubric, the baseline of 3 applies when the schema does the heavy lifting.

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+resource ('List saved session files') and further specifies exact fields (name, save time, contents), ordering (newest first), and the storage location. It also names the consumer of its output (load_session), which clearly separates it from siblings like save_session and load_session without opening any schema.

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?

The description gives clear usage context by stating the output is 'the filename to hand to load_session', effectively describing the save/load workflow. However, it never explicitly names alternatives or states when NOT to use this tool (e.g., versus list_pages or list_browsers), so it stops short of a 5.

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