Skip to main content
Glama
Silbercue

Public Browser

by Silbercue
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

set_page_data

Transfer large payloads to a browser page by chunking data into window.__pb_data, bypassing the CDP 1 MB message limit. Supports inline strings, binary files, and configurable encoding.

Instructions

Write a payload larger than 1 MB into window.__pb_data[key], chunked past the CDP 1 MB message limit. Source: inline (data) or file (absolute path, read as binary). The page reads window.__pb_data[key] (string or ArrayBuffer per encoding) and window.__pb_data[key + '__complete'] === true. Never write one key from parallel calls — they race. Under ~200 KB use evaluate; for a real use file_upload.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesProperty name under window.__pb_data (JS identifier, see pattern)
sourceYesinline: pass data. file: pass an absolute path, read as binary
encodingNoutf8 (inline default) keeps a string; binary (file default) gives an ArrayBuffer for FileReader/Blob/fetch; base64 keeps the base64 string
chunkSizeNoRaw bytes per chunk before base64 (default 500000; max 700000)

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed7 schema fields changedv2.10.5
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / chunkSize / description
      Previous value: -"Raw bytes per chunk before base64 encoding. Default 500_000 (~670 KB base64, safe under CDP's 1 MB-per-message limit). Capped at 700_000 (~933 KB base64) to leave safety margin."New value: +"Raw bytes per chunk before base64 (default 500000; max 700000)"
    • changedInput schema / properties / encoding / description
      Previous value: -"Encoding interpretation. 'utf8' (default for inline) keeps the data as a string. 'binary' (default for file) decodes to ArrayBuffer in the page so apps can pass it to FileReader / Blob / fetch body. 'base64' keeps the base64 string as-is (the page can decode it itself)."New value: +"utf8 (inline default) keeps a string; binary (file default) gives an ArrayBuffer for FileReader/Blob/fetch; base64 keeps the base64 string"
    • changedInput schema / properties / key / description
      Previous value: -"Property name under window.__pb_data (JS identifier — letters, digits, underscore; cannot start with digit)"New value: +"Property name under window.__pb_data (JS identifier, see pattern)"
    • changedInput schema / properties / source / anyOf
      Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "data": {
-        "description": "The payload as a string (base64 or utf-8)",
-        "type": "string"
-      },
-      "type": {
-        "const": "inline",
-        "type": "string"
-      }
-    },
-    "required": [
-      "type",
-      "data"
-    ],
-    "type": "object"
-  },
-  {
-    "additionalProperties": false,
-    "properties": {
-      "path": {
-        "description": "Absolute file path — the server reads the file as binary",
-        "type": "string"
-      },
-      "type": {
-        "const": "file",
-        "type": "string"
-      }
-    },
-    "required": [
-      "type",
-      "path"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "properties": {
+      "data": {
+        "description": "Payload string (base64 or utf-8)",
+        "type": "string"
+      },
+      "type": {
+        "const": "inline",
+        "type": "string"
+      }
+    },
+    "required": [
+      "type",
+      "data"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "path": {
+        "description": "Absolute file path",
+        "type": "string"
+      },
+      "type": {
+        "const": "file",
+        "type": "string"
+      }
+    },
+    "required": [
+      "type",
+      "path"
+    ],
+    "type": "object"
+  }
+]
    • changedInput schema / properties / source / description
      Previous value: -"Where to read the payload from. type 'inline' → pass `data` as a string. type 'file' → pass absolute `path`; the server reads the file as binary."New value: +"inline: pass data. file: pass an absolute path, read as binary"
  2. First observedv2.7.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers: chunking behavior, the page-side contract (`__complete` flag), encoding-dependent consumer types (string vs ArrayBuffer), and a concurrency race warning. This is a high level of disclosure for a tool with no structured hints.

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?

Every sentence carries useful information and the core purpose is front-loaded. It is slightly denser than necessary and partially repeats source options already in the schema, but there is no filler or padding.

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?

The description thoroughly covers input modes, page behavior, safety, and alternatives. However, it never states what the tool call returns or whether it resolves after chunks are sent versus after the page sets `__complete`. With no output schema, this is a meaningful gap for an agent deciding how to observe completion.

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 100%, so the baseline is 3. The description adds meaningful context on top: inline vs file source semantics, binary reading for files, and how encoding affects whether the page receives a string or ArrayBuffer. This goes beyond the schema's raw type descriptions.

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 ('Write'), a specific target (`window.__pb_data[key]`), and a distinguishing mechanism (chunking past the CDP 1 MB limit). It is clearly differentiated from siblings like `evaluate` and `file_upload`, which are explicitly named as alternatives.

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?

Provides explicit when-to-use guidance: payloads larger than 1 MB. It also names excluded alternatives: use `evaluate` under ~200 KB and `file_upload` for real `<input type=file>` cases. The warning about parallel writes to the same key adds important usage constraint.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Silbercue/public-browser'

If you have feedback or need assistance with the MCP directory API, please join our Discord server