Skip to main content
Glama
Blender Production MCP

Blender Production MCP

by DiegoArias32

production.diff_scene

Read-onlyIdempotent

Compare checkpoint metadata against the live Blender scene or another checkpoint to identify differences without performing a full binary diff.

Instructions

Compare checkpoint metadata with live scene or another checkpoint; not a full binary diff.

Input Schema

NameRequiredDescriptionDefault
limitNo
offsetNo
checkpointYes
other_checkpointNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already establish that this is a safe, read-only, idempotent operation. The description adds useful behavioral context by clarifying that the comparison is metadata-based and not a binary diff, but it does not describe pagination behavior or other operational limits.

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?

The definition is a single front-loaded sentence with no wasted words. The core action and its key limitation are both stated immediately.

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

Completeness3/5

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

An output schema exists and annotations cover the safety profile, so return values and destructive-behavior details need not be repeated. Still, with four parameters and no schema descriptions, the missing limit/offset guidance leaves invocation details only minimally complete.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry parameter meaning. It indirectly explains other_checkpoint by saying the comparison can target 'another checkpoint' versus the live scene, but it says nothing about the limit and offset parameters, leaving half the parameters unexplained.

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 states a specific verb and resource: comparing checkpoint metadata against either the live scene or another checkpoint. It also clarifies that this is not a full binary diff, which meaningfully bounds the operation, though it does not explicitly distinguish itself from sibling tools like create_checkpoint or restore_checkpoint.

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

Usage Guidelines3/5

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

It implies the tool is for metadata comparison and explicitly excludes full binary diff use, giving some usage context. However, it does not say when to choose this over related siblings such as scene_audit or create_checkpoint/restore_checkpoint, so the guidance remains implicit.

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

Deploy Server

Other Tools