Skip to main content
Glama
Sign In
playcal

playcal

by RizgarOzan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

playcal_snap

Save a JSON read under a name and diff two saved reads, omitting IDs that change between sessions so you can spot real changes.

Instructions

save a JSON read under a name and diff two saves, with ids that change between sessions left out

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": "playcal_snap"
  }
}

Input Schema

NameRequiredDescriptionDefault
dirNowhere saves live (default .playcal/snaps).playcal/snaps
refsNosave: NAME [FILE or - for stdin]. diff: A [B], each a saved name or a .json file
godotNoread the node tree of the Godot main scene (one headless frame)
limitNomost changes to list (default 50)
sceneNowith --godot: scene to read instead of the main scene (res://...)
unityNoread from the Editor, e.g. "scene get_hierarchy"
actionYessave NAME: store a read. diff A [B]: what changed from A to B (or to a live --unity read). list
ignoreNofield to leave out of the diff, repeatable (default: instanceId). --ignore '' keeps everything
project_pathNoUnity project folder with --unity, Godot project folder with --godot

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden, and it only discloses that volatile ids are filtered out of diffs — which the 'ignore' schema property already states as a default of instanceId. It says nothing about the meaningful side effects: that 'save' writes files into a directory, that Unity or Godot reads spin up an Editor or a headless frame (which can be slow and requires a project path), or what the diff output looks like.

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?

One compact sentence with the primary capability front-loaded and no filler. The compression goes slightly too far, though, since the omitted 'list' action and Editor-backed reads are exactly the details that would earn their words.

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

Completeness2/5

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

This is a nine-parameter tool with three actions, two external Editor integrations, and no output schema or annotations to fall back on. The description accounts for only the save and diff paths and never mentions the live-read mode or listing, leaving an agent unable to judge cost, prerequisites, or full capability from the prose alone.

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

Parameters3/5

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

Schema description coverage is 100%, and the per-property descriptions already explain refs, ignore, limit, godot, unity, scene and project_path in detail. The tool description adds essentially no syntax or meaning beyond that, so the baseline 3 applies.

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 names specific verbs and a resource: saving a JSON read under a name and diffing two saves. That distinguishes it from most siblings, but it omits the third supported action ('list') and the fact that reads can be sourced live from a Godot or Unity Editor, so the picture of what the tool actually does is partial. It also gives no signal to separate it from near-neighbours like playcal_baseline or playcal_checkpoint.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no exclusions, and no naming of alternatives such as playcal_baseline or playcal_checkpoint, which are the obvious confusion points for a save/compare tool. Usage must be inferred entirely from the one-line purpose statement.

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