Skip to main content
Glama
Sign In
real-browser-mcp-server

real-browser-mcp-server

by codeiva11
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

storage_inspector

Inspect and manage browser cookies, sessions, and client-side storage. Save or load session state to avoid re-logging, and control IndexedDB and service workers.

Instructions

Inspect and manage client-side storage & sessions. Supports 7 actions: cookies (get all current cookies), save_session (persist cookies & storage state to file), load_session (restore state from file without re-logging), clear_cookies, autosave (auto-save session on every navigation), indexeddb, service_workers.

Input Schema

NameRequiredDescriptionDefault
actionNocookies
enabledNoFor autosave action: true to enable, false to disable
passphraseNoAES-256-GCM passphrase. When provided with save_session the file is encrypted; required to load an encrypted session. Never logged or stored.
sessionPathNoFile path to save or load session state (cookies & localStorage) from disk

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv3.3.10
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "cookies",
-  "save_session",
-  "load_session",
-  "clear_cookies",
-  "indexeddb",
-  "service_workers"
-]New value: +[
+  "cookies",
+  "save_session",
+  "load_session",
+  "clear_cookies",
+  "autosave",
+  "indexeddb",
+  "service_workers"
+]
    • addedInput schema / properties / enabled
      Added value: +{
+  "description": "For autosave action: true to enable, false to disable",
+  "type": "boolean"
+}
  2. Changed1 schema field changedv3.3.1
    • addedInput schema / properties / passphrase
      Added value: +{
+  "description": "AES-256-GCM passphrase. When provided with save_session the file is encrypted; required to load an encrypted session. Never logged or stored.",
+  "type": "string"
+}
  3. First observedv3.2.13

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose real behavior beyond the schema: encryption behavior via passphrase, and that autosave fires on every navigation. However it omits what clear_cookies destroys, whether save_session overwrites an existing file, and any permission or side-effect warnings for a mutation-capable tool.

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?

One sentence of purpose followed by a compact, parallel action list. Front-loaded and no filler; every clause carries information an agent needs to pick an action.

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

Completeness3/5

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

There is no output schema, yet the description says nothing about what cookies, indexeddb, or service_workers return, nor how errors surface when sessionPath is missing or passphrase is wrong. For a 4-parameter, unannotated tool with no return documentation, this is a meaningful gap.

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 75% and the description adds genuine value on top: it maps each enum value to its semantic meaning (e.g. save_session persists cookies & storage to file, load_session restores without re-logging). It is silent on the interaction of passphrase with load_session/autosave, but the parameter descriptions in the schema cover that adequately.

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 ('Inspect and manage client-side storage & sessions') and then enumerates all 7 supported actions with brief glosses, so an agent knows exactly what capability surface exists. No sibling tool in the list touches cookies/IndexedDB/service workers, so the boundary is inherently clear from the wording alone.

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

Usage Guidelines3/5

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

Usage is only implied through the action glosses ('restore state from file without re-logging' hints at the load_session scenario). There is no explicit when-to-use/when-not guidance, no statement of prerequisites, and no comparison to any alternative approach for state persistence.

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