Skip to main content
Glama

Live: session step

live_session_step
Destructive

Run one perceive-decide-act-observe cycle for live SVG editing. Perceive the current scene, optionally apply styles or insert content, and return the updated frame and diff.

Instructions

Run ONE perceive→decide→act→observe iteration of the live-view loop.

When to use: the flagship loop step — call it repeatedly to drive a live edit loop (use live_wait_for_change between steps to react to the user's edits). It COMPOSES the existing live tools (ADR-006); for a single standalone edit call live_apply_to_selection / live_insert_svg / live_set_selected_text directly. Each call is one bounded iteration — no server-side autonomous run.

Key params: action is the AGENT's decision (this tool embeds no LLM), one of the FIXED set apply | insert_svg | set_text (no raw-Action/code path — ADR-002/003; an out-of-enum action is rejected). OMIT action for a PERCEIVE-ONLY step (mutates nothing, no Operation Record). When acting: apply takes fill/stroke/stroke_width/opacity and/or dx/dy/scale/rotate; insert_svg takes a safe-parsed svg_fragment; set_text takes a control-char-checked text. The act runs through run_live_mutation (the SAME path as the standalone tools); mutating a running session is HIGH risk and REQUIRES an explicit approval_token. Requires a session.

Return shape: LiveSessionStepResult — always the PERCEIVE scene + frame; after an act also the operation_id, a focused live_diff_view artifact, and the after scene/frame.

Example: live_session_step(action="apply", approval_token="ok", fill="#3366cc")

Risk class: high when it acts (routes through run_live_mutation — HIGH + approval); low when perceive-only (read-only; no mutation, no Operation Record).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dxNo
dyNo
fillNo
textNo
scaleNo
actionNo
rotateNo
strokeNo
opacityNo
stroke_widthNo
svg_fragmentNo
approval_tokenNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
diffNoFocused before/after diff linked to the record (act steps only).
editNoThe mutation outcome (null when perceive-only).
actedYesWhether a semantic act was performed this step.
actionNoThe semantic act performed, or null on a perceive-only step.
after_frameNoCanvas frame captured after the act (null when perceive-only).
after_sceneNoStructured scene captured AFTER the act (null when perceive-only).
before_frameYesCanvas frame captured before acting.
before_sceneYesStructured scene captured BEFORE deciding/acting.
operation_idNoLive Operation Record id of the act (null when perceive-only).
Behavior5/5

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

The description discloses risk: 'high when it acts (routes through `run_live_mutation` — HIGH + approval); low when perceive-only (read-only).' It also explains the approval token requirement. Annotations already indicate destructiveHint=true, but the description adds valuable context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with sections: purpose, usage, key params, return shape, example, risk class. Front-loaded with main purpose. Every sentence adds value, no redundancy.

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?

Covers all necessary aspects: purpose, usage, parameters, return type (references output schema), example, risk, and design decisions (ADR references). Complete for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description thoroughly explains key parameters: `action` enum, parameter dependencies per action, and the role of `approval_token`. It adds significant meaning beyond the bare schema.

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 clearly states the tool's purpose: 'Run ONE perceive→decide→act→observe iteration of the live-view loop.' It distinguishes from sibling tools by referencing standalone tools like `live_apply_to_selection`, `live_insert_svg`, and `live_set_selected_text`, and explains when to use each.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'When to use' section explains the tool is for repeated loop steps, with `live_wait_for_change` between steps. It also notes when to use standalone tools instead. Clear and actionable guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jjjsood/inkscape-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server