marimo-inspect

Overview Schema Source Related Servers Discussions Admin

Set Ui Value

set_ui_value

Destructive

Set a live marimo UI widget's value by its variable name to trigger reactive re-execution, with shape validation and read-back verification.

Instructions

Set the value of a live marimo UI element, by its variable name.

The kernel global named by variable_name must resolve to a marimo UI element (e.g. mo.ui.slider, mo.ui.dropdown, mo.ui.text). Its value is replaced with value, triggering reactive re-execution the same way a user interaction would.

Value shape is per widget and is NEVER coerced: a slider/text takes a scalar, a dropdown takes its option key inside a one-element list (for example ["beta"]), a multiselect takes the list of selected keys, a range_slider takes a two-element list, a checkbox takes a bool. The element's own declaration decides; a shape mismatch is refused before anything is applied and the response carries the corrected payload in did_you_mean.

This tool accepts NO source code: it exists for widget interaction only, not for arbitrary code execution. The update is flushed on code-mode context exit, the kernel then re-runs dependent cells, and the element's value is read back before returning — status: ok with verified: true means the element's own value was observed to move (or was already equal), not merely that the update was queued. A value marimo rejected is reported as an error, never as success.

Input Schema

TableJSON Schema

Name	Required	Description
`value`	Yes	New value for the element, in the shape that element accepts.
`server_url`	No	Server URL override.
`session_id`	No	Session ID; omit only when the active-session binding holds for this call (see `list_active_notebooks`).
`variable_name`	Yes	Name of the live kernel global holding the UI element.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.3Sep 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: the update triggers reactive re-execution like a user interaction, is flushed on code-mode context exit, and values are verified by read-back so 'status: ok' with 'verified: true' means the value actually moved. It also discloses the refusal path (shape mismatch rejected before applying, corrected payload in did_you_mean) and that rejected values are never reported as success.

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?

Front-loaded with the one-line purpose, then layered detail in descending priority (type constraint, value shapes, then execution/verification semantics). It is dense and multi-paragraph but nearly every sentence carries non-redundant information; the value-shape enumeration is long but earns its space.

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

Completeness5/5

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

For a mutating tool with a live output schema, it covers everything an agent needs: preconditions, value shapes, error/refusal behavior, timing of the flush, and the meaning of the verification fields. The session-binding caveat is delegated to the session_id schema and list_active_notebooks, which is coherent.

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, but the description adds real per-parameter meaning: 'value' shape is enumerated per widget type (scalar for slider/text, one-element list for dropdown, list of keys for multiselect, two-element list for range_slider, bool for checkbox) and is never coerced. The server_url/session_id parameters are left to the schema, which already documents them.

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?

Opens with a specific verb+resource+scope: 'Set the value of a live marimo UI element, by its variable name.' It immediately distinguishes itself from the cell-editing siblings by stating it accepts no source code, so an agent can tell it apart from edit_cell/run_cell without opening either schema.

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 clear precondition (the kernel global must resolve to a marimo UI element, with examples of types) and an explicit when-not ('NO source code … not for arbitrary code execution'), which routes the agent away from misuse. It does not name a sibling alternative for the code-execution case, so it stops short of full when/when-not/alternatives.

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

Deploy Server