Actions & State

An Action is one thing you did during a recorded session. When you hit Record and use your MCP app, each interaction becomes an Action in sequence. When you Replay, Studio re-runs each Action against the live server and checks that the results still match.

MCP

These actions talk directly to your MCP server.

Tool call - invokes a tool by name with the params you provided. Studio records the full response: the output content, whether it succeeded, and any widget URI the tool returned.

Resource read - reads a resource by URI. Studio records the contents returned.

Widget interaction

These actions happen inside the widget UI rendered by Studio.

Widget click - clicks an element inside the widget iframe. Studio finds the element using a CSS selector and records whether the click matched. Any tool calls or widget renders triggered by the click are captured as part of this action.

Widget text input - types a value into an input field inside the widget iframe. Captured the same way as a click, including any follow-on tool calls the input triggers.

Widget snapshot

A snapshot is a frozen copy of the widget UI at the moment an action completed. It captures exactly what was rendered in the widget iframe after a tool response, a click, or text input.

Snapshots are stored with the session for debugging. They are not automatically checked during replay, because widget output is rarely stable enough to compare exactly.

When to use them: if a replay step fails and you’re not sure why, look at the snapshot for that step. If the snapshot looks correct but the live replay behaves differently, the issue is in your server or widget logic after the recording was made. If the snapshot itself looks wrong, the bug was already present when you recorded.

CSP sandbox: Studio renders widgets in a sandboxed iframe with a strict Content Security Policy. Snapshots reflect what was inside that sandbox. External resources blocked by CSP won’t appear, which matches what you saw in Studio during recording.

State

State is how Studio tracks call counts across a session. It records how many times each tool was called, each resource was read, and each widget was interacted with.

This matters because result payloads alone don’t catch everything. A tool might return the same response but get called twice instead of once. State catches that.

When you replay, Studio checks both the result (what the server returned) and the call counts for each step.