Bloom

Read frame runtime state

read_frame_state

Read frontend hooks, stores or storage from an authorized private frame-browser session, live Bloom tab, or comment capture. Overview returns a bounded map; storageKey/valuePath and cursors select detailed values. Truncated strings include prefix and omittedCharacters. Results include payloadHash. 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>",
      "from": "<from>"
    },
    "name": "read_frame_state"
  }
}

Input Schema

Name	Required	Description
`from`	Yes	Where the state lives. `"browser"`: your own `browse_frame` session on the frame. `{ contextId }`: the state one of YOUR Bloom tabs holds now — each fresh call asks that tab for a new complete capture (reusing one still in flight), so call again while `completeArtifact.status` is 'materializing'. `{ captureKey }`: the state a comment captured.
`path`	Yes	The canonical Frame path: bloom:file/<Page>/<Filename>.tsx.
`limit`	No	Max entries an overview, read or search returns.
`query`	No	Text to find when `operation` is search.
`range`	No	Slice of a large array, object or string when reading a value.
`cursor`	No	Continuation cursor a prior read or search returned.
`readRef`	No	`from: { contextId }` only: the complete-artifact read lease a prior call returned. Pass it back to keep reading the same immutable capture.
`branchId`	No	Target 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.
`operation`	No	overview (default) returns a bounded map of the state, read expands one `storageKey` + `valuePath` (or continues a `cursor`), search finds values matching `query`.
`valuePath`	No	Path inside `storageKey` to expand, e.g. ['hooks', 0, 'value'].
`storageKey`	No	Storage slot to expand, as an overview names it.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.1/5.0

Behavior3/5

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

It discloses genuinely useful behavior beyond the annotations: live-tab reads re-request a complete capture (consistent with readOnlyHint=false), truncated strings report prefix and omittedCharacters, and results carry a payloadHash. However it says nothing about permissions beyond 'Scope: project:read', rate/expense of repeated capture requests, or what a failed capture looks like.

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?

Five compact sentences, front-loaded with purpose and sources, then return-shape caveats, then scope. Dense but every sentence carries information; the semicolon-chained clauses are slightly compressed for an 11-parameter tool.

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 an 11-parameter tool with nested objects, two required params and no output schema, the description covers sources, the overview/read/search operation split, truncation and hashing of results, and the capture-materialization loop. Remaining gaps are the shape of the 'bounded map' and default/limit behavior.

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?

With 100% schema coverage the baseline is 3, and the description earns more by explaining how the pieces interact — overview yields a bounded map, storageKey/valuePath expand one slot, cursors continue a prior read, and readRef keeps reading the same immutable capture. It does not clarify `limit` defaults or range behavior beyond what the schema already states.

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?

The description opens with a specific verb and resource ('Read frontend hooks, stores or storage') and enumerates the three distinct sources it can read from, which separates it cleanly from read_files and browse_frame in the sibling list.

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?

It gives clear operational context: the three `from` variants map to a private browse_frame session, a live Bloom tab, or a comment capture, and it explicitly instructs calling again while `completeArtifact.status` is 'materializing'. It stops short of naming when to prefer a sibling tool such as read_files or browse_frame instead.

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

All Bloom tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?