Snapshot the session's localStorage/sessionStorage for the current origin: {url, local_storage, session_storage}. Feed it back via session_create's storage field to restore a logged-in state in a new session — the half of login state that cookies can't carry (many sites keep the session token in localStorage). Call before the session idles out.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session ID |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description is consistent with that, adding behavioral context about capturing localStorage as a complement to cookies. It explains the output shape and the practical benefit, going beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero redundancy: the first states the action and output format, the second gives the use case and timing. It is front-loaded with the core action and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, this description is fully sufficient: it explains what it does, the output shape, how to use the result, and when to call it. No critical information for an agent to decide and invoke it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter session_id is fully documented in the schema (100% coverage), and the description adds no extra meaning beyond its obvious purpose. This matches the baseline for high schema coverage, where the description need not elaborate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Snapshot' and the resource 'localStorage/sessionStorage' for the current origin, with an explicit output structure. It distinguishes this from cookies by noting it captures 'the half of login state that cookies can't carry', making the tool's unique role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives precise when-to-use guidance: feed the output back via session_create's storage field to restore logged-in state, and call before the session idles out. It also implicitly contrasts with cookie-based state, providing context for when this tool is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have distinct purposes, but there's overlap between session_click/click and session_eval/eval. Descriptions clarify that session_* tools operate on persistent sessions while the others are one-off, so ambiguity is low.
The session_* prefix is consistently used for session-related tools (17 of 23), while the remaining tools (cache, click, download, eval, fetch, search) are single-word lowercase verbs. This is a clear pattern, though not strictly verb_noun.
23 tools is above the typical 3-15 range but reasonable for a browser automation server that needs both one-off and session-based operations. The count is justified by the breadth of features, though it's slightly heavy.
The surface covers all major browser automation needs: navigation, clicking, typing, scrolling, screenshot, state inspection, console/network logs, cookies/storage management, JavaScript eval, waiting, and even session export. No obvious gaps for the stated purpose.