marimo-inspect

by ajegorovs

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Set Active Session

set_active_session

Set the active notebook session to bind a session ID and server URL, so later tool calls can omit both parameters.

Instructions

Set the active notebook session for subsequent tool calls.

Binds a session_id (and optionally its server_url) so later calls can omit both session_id and server_url. The binding is written to two places: this call's MCP-session state (visible to a client that keeps one MCP session across calls — an mcp-SDK-based client does) and a process-global fallback consulted only when the MCP-session state has nothing bound. Over stdio one process serves exactly one client, so the fallback carries the binding to every later call, fastmcp's own Client (a fresh MCP session per request on the pinned fastmcp 4.0.3) included. Over HTTP/SSE one process serves many clients, so the fallback is served only while the process has seen a single client session; once a second distinct client session appears, argument-less calls are refused with reason: binding_ambiguous rather than risk handing one client another client's notebook — pass both arguments explicitly there. Use list_active_notebooks first to discover available sessions and their IDs.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`server_url`	No	Optional server URL to bind with the session.
`session_id`	Yes	The session ID to set as active.

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?

With no annotations, the description carries the full burden and does so: it discloses where the binding is written (MCP-session state plus process-global fallback), how stdio vs HTTP/SSE differ, and that ambiguous argument-less calls are refused with reason: binding_ambiguous rather than leaking another client's notebook. That is exactly the non-obvious behavior an agent needs.

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?

The purpose is front-loaded in the first sentence and every subsequent sentence carries behavioral detail, but the middle block is a dense wall of text mixing stdio/HTTP semantics that could be split for faster scanning. Not wasteful, just heavy.

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?

An output schema exists so return values needn't be described. Given the tool's deceptively stateful nature and lack of annotations, the description covers the persistence model, fallback scope, and failure mode thoroughly — nothing essential to calling it correctly is missing.

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 baseline is 3, but the description adds real meaning beyond the schema: that session_id and server_url become omittable in later calls because the binding persists, and why server_url is optionally bound alongside. This exceeds the schema's per-field text.

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 and resource ('Set the active notebook session') and scopes the effect to 'subsequent tool calls', which cleanly separates it from siblings like list_active_notebooks or get_cell_map. An agent can tell what state this mutates without opening the 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?

Explicitly routes the agent to list_active_notebooks first to discover sessions and their IDs, and tells it to pass both arguments explicitly in the multi-client HTTP/SSE case. It lacks an explicit 'when not to use' framing, but the conditional guidance is unusually concrete.

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

Deploy Server