Skip to main content
Glama
Sign In

Blender Bridge

by com.blenderbridge
OverviewDiscussionsAdmin

Manage scene checkpoints

scene_checkpoints
Destructive

Scene history, newest first. For returning to a named step, action list supplies its explicit after_state_checkpoint_id and after_state_restorable: restore that checkpoint_id for the state AFTER that command. Never substitute the next command's before checkpoint. before_request_id intentionally means BEFORE a command, as does undo_last_action. Returns add a current history entry and a backup; Undo return requires expected_current_checkpoint_id and is invalidated by new work. action save creates a named point now.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "scene_checkpoints"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelNoHuman-readable name for a checkpoint created by action=save.
limitNoMaximum number of checkpoint-history records returned by action=list.
actionYeslist reads history, save creates a named checkpoint, restore replaces the scene with a selected history state.
request_idNoOptional identifier for this checkpoint operation.
checkpoint_idNoExplicit history checkpoint to restore; use after_state_checkpoint_id for the state after a named operation.
allow_other_fileNoPermit restoring a checkpoint from another Blender file only when that cross-file restoration is authorized.
before_request_idNoRestore the state before this recorded operation, as an alternative to checkpoint_id.
expected_current_checkpoint_idNoCurrent checkpoint guard for a return operation; reject restoration if the scene history has moved on.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / properties / action / description
      Added value: +"list reads history, save creates a named checkpoint, restore replaces the scene with a selected history state."
    • addedInput schema / properties / allow_other_file / description
      Added value: +"Permit restoring a checkpoint from another Blender file only when that cross-file restoration is authorized."
    • addedInput schema / properties / before_request_id / description
      Added value: +"Restore the state before this recorded operation, as an alternative to checkpoint_id."
    • addedInput schema / properties / checkpoint_id / description
      Added value: +"Explicit history checkpoint to restore; use after_state_checkpoint_id for the state after a named operation."
    • addedInput schema / properties / expected_current_checkpoint_id / description
      Added value: +"Current checkpoint guard for a return operation; reject restoration if the scene history has moved on."
    • addedInput schema / properties / label / description
      Added value: +"Human-readable name for a checkpoint created by action=save."
    • addedInput schema / properties / limit / description
      Added value: +"Maximum number of checkpoint-history records returned by action=list."
    • addedInput schema / properties / request_id / description
      Added value: +"Optional identifier for this checkpoint operation."
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds valuable behavior: returns create a current history entry and a backup, and undo return is invalidated by new work. This clarifies side effects beyond the safety flags, though it still does not describe permission requirements or error behavior.

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

Conciseness3/5

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

The description is front-loaded with the resource and core actions, and every sentence contains information. However, the middle sentences are convoluted and fragmented, making the flow harder to parse than necessary.

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

Completeness4/5

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

With 8 parameters, 100% schema coverage, and no output schema, the description provides enough context to call the tool correctly. It covers restore semantics, backup creation, and undo guard invalidation. It could do more to explain cross-file restoration authorization and list behavior, but the core gaps are minor.

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 description coverage is 100%, so the baseline is 3, but the description adds critical nuance beyond the schema: it warns never to substitute the next command's before checkpoint when restoring after_state_checkpoint_id, and explains the distinction between before_request_id and undo_last_action. This meaningfully improves parameter selection.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource (scene checkpoint history) and the three core actions: list, restore, and save. It clearly distinguishes restore semantics from undo_last_action and get_scene_state, though the phrasing is dense and requires careful reading.

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?

It gives explicit guidance on restoring: use after_state_checkpoint_id for the state after a named command, never substitute the next command's before checkpoint, and before_request_id means BEFORE a command just like undo_last_action. It also notes that undo return requires expected_current_checkpoint_id and is invalidated by new work. This is strong contextual guidance, though it lacks explicit alternatives for list vs get_scene_state.

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

All Blender Bridge toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources