Skip to main content
Glama
Custodia-Admin

Pagebolt

by Custodia-Admin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

create_session

Create a persistent browser session to reuse cookies, localStorage, and login state across multiple screenshots or sequences. Pass the returned session ID to keep authenticated pages available.

Instructions

Create a persistent browser session (Starter+ plan required). The session keeps a live browser page open so you can reuse cookies, localStorage, and auth state across multiple take_screenshot or run_sequence calls. Pass the returned session_id to those tools. Sessions expire after 10 minutes of inactivity (hard cap: 30 minutes). Useful for AI agent workflows that log in once and then take multiple screenshots of authenticated pages.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cookiesNoCookies to pre-load into the session browser page
stealthNoLaunch this session with stealth mode (bypasses bot detection). Note: stealth sessions use a dedicated browser and consume more memory.
viewportNoViewport dimensions for the session browser page

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.0
    • changedInput schema / properties / cookies / items / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "additionalProperties": false,
-    "properties": {
-      "domain": {
-        "type": "string"
-      },
-      "name": {
-        "type": "string"
-      },
-      "value": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "name",
-      "value"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "additionalProperties": true,
+    "properties": {
+      "domain": {
+        "type": "string"
+      },
+      "expirationDate": {
+        "type": "number"
+      },
+      "expires": {
+        "type": "number"
+      },
+      "httpOnly": {
+        "type": "boolean"
+      },
+      "name": {
+        "type": "string"
+      },
+      "path": {
+        "type": "string"
+      },
+      "sameSite": {
+        "enum": [
+          "Strict",
+          "Lax",
+          "None",
+          "strict",
+          "lax",
+          "no_restriction",
+          "unspecified"
+        ],
+        "type": "string"
+      },
+      "secure": {
+        "type": "boolean"
+      },
+      "url": {
+        "type": "string"
+      },
+      "value": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "name",
+      "value"
+    ],
+    "type": "object"
+  }
+]
  2. First observedv1.8.1

TDQS

A4.1/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it delivers real operational facts: plan gating, state persistence across calls, a 10-minute inactivity expiry with a 30-minute hard cap, and that the returned session_id must be passed to consumers. It omits cleanup semantics (that destroy_session should be called) and any failure/auth error behavior.

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?

Four sentences, all earning their place: purpose, mechanism, handoff instruction, and expiry limits. The final sentence restates the use case already implied earlier and could be trimmed, but the description is well front-loaded.

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

Completeness4/5

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

With no output schema, the description usefully discloses that a session_id is returned and how long the session lives, plus the plan requirement. For a stateful resource-creating tool it could go further on teardown and resource/memory implications, but an agent has enough to invoke it correctly.

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%, so cookies, stealth, and viewport are already documented in the schema (including the stealth memory warning). The description adds no parameter-level meaning beyond the flow of the returned session_id, so the baseline of 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?

States a specific verb and resource ('Create a persistent browser session') and immediately scopes the concept of persistence: a live page keeping cookies, localStorage, and auth state. It differentiates itself from siblings by naming the consumers (take_screenshot, run_sequence) and by implying the lifecycle opposite of destroy_session/list_sessions.

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?

Gives a concrete when-to-use scenario ('AI agent workflows that log in once and then take multiple screenshots of authenticated pages') and a prerequisite (Starter+ plan required). It does not state when NOT to use it, e.g. that a one-off screenshot should call take_screenshot directly without a session.

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