Open a page for editing and get the session_id every other studio tool needs. The page has four files: index.html, style.css, app.js and manifest.json. One session per page at a time, the studio's own assistant included. A session ends after 30 minutes without a call, and keeps nothing. End it with studio_save, or with studio_close to drop the changes.
| Name | Required | Description | Default |
|---|---|---|---|
| page_id | Yes | The page_id studio_list_pages returned. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the concurrency lock (one session per page, including the studio's own assistant), a 30-minute idle expiry, and that an expired session retains nothing. The one gap is whether the mutation annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) fully align — the description implies re-opening is blocked rather than idempotent, which is consistent, but it doesn't say what happens to edits on timeout beyond 'keeps nothing' (discarded, presumably).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences with the core action and the returned session_id front-loaded, then constraints, then the two exit paths. Every sentence contributes new information; nothing is restated from the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description names the return value (session_id) and explains the full session lifecycle — start, concurrency limit, expiry, and the two ways to end. An agent has everything needed to call this and to sequence the sibling studio tools correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single page_id parameter is already documented as coming from studio_list_pages, so the description adds no additional parameter meaning. Baseline 3 applies when the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Open a page for editing") and immediately names the artifact it produces ("session_id every other studio tool needs"), which distinguishes it from studio_list_pages and the read/write file tools. The mention of the four files further pins down what a 'page' is in this system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly establishes this as the prerequisite for all other studio tools, and routes the agent at the end: studio_save to keep changes, studio_close to drop them. It also gives the failure constraint ("one session per page at a time") so the agent knows when a second call would conflict.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
