Skip to main content
Glama

Look at or use a canvas frame in a browser

browse_frame

Inspect a Bloom canvas frame or interact with its private browser. Without commands/time, returns the current shared capture's status and, when ready, a one-hour image URL, dimensions and source contentHash. pending includes retryAfterMs; failed includes failure.code/message. Deployments switch the server-rendered shared capture off by default: it then answers failed with failure.code server_frame_render_off, retry changes nothing, and commands "screenshot" returns a live image. render_content identifies defective frame code; infrastructure and timeout failures identify incomplete observations. One-shot capture has a 1500ms browser budget. retry requests another failed observation. With commands/time, clicks, typing and playhead state persist in a private session; screenshots return images. Source changes return stale with state reapplied/dropped and skip acting commands; browser restoration is reported. Command output distinguishes ran, failed and skipped operations. runtimeCost reports measured DOM, long-task and React rendering findings, or explicit measurement failures. The anchor command returns a rendered element/quote target; record enables mp4 recording. The state this browser is left in (tab, open panel, tour stop, playhead) is what a thread captures when create_thread or update_thread passes state "browser", so drive the frame to the state that shows your point before you pin a comment; readers open that comment straight into this state, so its text never explains how to get there. Live browsers close when the canvas activity finishes. The shared capture also returns runtimeCost for its source: over-budget findings earlier live calls recorded, or unavailable. Scope: project:read.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "browse_frame"
  }
}

Input Schema

NameRequiredDescriptionDefault
fromNoReload your live browser into another runtime state (and playhead): a comment's capture, or `"fresh"` — first load, nothing carried over (`state: 'reset'`), to test a frame from zero after earlier calls clicked and typed into it. Replaces the browser's own state; `commands` then run on top (a screenshot when there are none). The result's `state` says whether the frame accepted a seed ('reapplied') or its current code refused it ('dropped'). Inspect the state itself with `read_frame_state`.
pathYesCanonical bloom:file/<Page>/<Filename>.tsx. Frame IDs remain explicit identity fields, never path spellings.
timeNoPin an animated frame's playhead to this many milliseconds, then run `commands` (or take a screenshot when there are none). The pin persists across calls, so a self-animating frame holds still between them; step it by calling again with a later `time`.
retryNoShared capture only: retry a failed capture. Omit for a stable read of the current observation. Has no effect while the deployment's shared capture is off (server_frame_render_off).
recordNoVideo of your live browser. `true` opens a recording browser (your state is restored into it) and every later call records until `false`, which finalizes it without driving a browser. The result's `recording` goes `recording` → `processing` (wait `retryAfterMs`, then call again with `record: false`) → `ready` with an mp4 `url`. The mp4 is deleted one hour after it is ready; download it if you need to keep it. An idle stop or `finish_work` also finalizes it. Off by default: record only when you need to watch motion or a flow.
branchIdNoTarget branch id. Omit it — Bloom derives the branch from the frames you name, from the token's narrowing, or from your only readable branch, and enumerates the candidates if it genuinely cannot.
commandsNoCommands for your private live browser of this frame, run in order. One command per line: `snapshot` (accessibility tree; each element carries `[ref=eN]`) | `screenshot` | `click @eN` | `hover @eN` | `fill @eN "text"` | `type "text"` | `press Key` (e.g. `Enter`, `Shift+Tab`) | `get text @eN` | `wait <ms>` (0–5000) | `seek <ms>` (pins the frame's playhead: motion, rAF and `Date.now` read that instant until the next `seek` or `play`; later calls keep the pin) | `play` (releases the pin so motion runs in real time) | `anchor @eN ["quote"]` (prints the `create_thread` target that pins a comment to that element — its source path, instance key and, with a quote, the text range — and saves nothing) | `anchor "text"` (the same for the one element that shows that text, no snapshot needed; more than one or none fails and says why). Other commands name elements only by `@eN` refs from the latest `snapshot`; CSS, role and text selectors are not supported. Snapshot lines also carry `[path=<sourcePath>]`; refs stay valid across calls until the next `snapshot` or a code change. After a failed command, later `snapshot`/`screenshot`/`get text`/`wait` still run and later actions are skipped (`○`). At most 20. The browser keeps its state between calls. Omit (with `time`) to read the shared capture instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior5/5

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

Annotations only supply the generic safety profile (readOnlyHint=false, openWorldHint=true, not idempotent), while the description adds concrete operational facts an agent could not otherwise know: a one-hour image URL lifetime, a 1500ms browser budget, live browsers closing when canvas activity finishes, retry being a no-op under server_frame_render_off, the mp4 deletion window and recording state machine, a 20-command cap, and refs staying valid across calls until the next snapshot. That is substantive behavioral context well beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and no sentence is pure filler, but the body is a dense run-on chain of semicolon-separated clauses that mixes failure codes, recording lifecycle, runtimeCost, anchoring and thread-state guidance with no headings or paragraph breaks. It also duplicates parameter documentation already present in the schema, which lengthens an already long description without adding new information.

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?

For a seven-parameter, no-output-schema tool whose annotations say little, the description covers failure modes (pending/retryAfterMs, failure.code, stale, server_frame_render_off), state persistence, and the interaction with create_thread/update_thread that determines what a pinned comment shows. The main gap is return shape for successful command batches beyond the ran/failed/skipped distinction.

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 the schema already carries parameter meaning and the baseline is 3. The prose largely restates the schema text for retry, record, time, from and commands, adding only light framing such as the note that omitting commands with time reads the shared capture instead of driving a browser.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific dual verb+resource: "Inspect a Bloom canvas frame or interact with its private browser," and it immediately disambiguates the read path (no commands/time) from the drive path (with commands/time). It also names a sibling, read_frame_state, for state inspection. It loses a point because the tool's two modes are only separated mid-paragraph, so an agent must read several sentences before the split becomes explicit.

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 implied rather than stated: omitting commands/time reads the shared capture, passing them drives a live session, and retry is only for failed observations. There is no explicit when-not-to-use guidance and no routing to discovery siblings such as list_canvas_frames for finding a valid path, which matters because path is the only required parameter.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources