Layerz

Pin, unpin or restore version

layerz_manage_version

DestructiveIdempotent

Acts on one version of a model (version: exactly one of revision_id, version_number, id) by op. pin: keeps the version listed, diffable and restorable beyond the plan history window; capped per plan (max_pinned_versions, 403 past the cap); a no-op on a pinned version. unpin: frees the slot; a version past the window then stops being listed. restore: replaces the live items, schema and inputs with that snapshot, and puts back the source settings (window, keys, bindings) and the mapping rules as they stood at that version, after saving the current state as a restore backup version (backup_version_id, null when the live state already matched the latest snapshot); requires summary, the label of the restored state. Returns { ok, version_id, version_number, revision_id, pinned, pinned_count, max_pinned_versions } for pin / unpin, { ok, restored_version_id, restored_version_number, restored_revision_id, backup_version_id, sources?: { sources_restored, rules_written, rules_removed }, warnings[] } for restore — warnings names what could not come back (a source deleted since, a rule whose target is gone, a version written before source versioning). The target is inside the plan window or pinned. Not advertised to read-only keys.

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": {
      "op": "<op>",
      "version": "<version>"
    },
    "name": "layerz_manage_version"
  }
}

Input Schema

Name	Required	Description
`op`	Yes	pin \| unpin \| restore.
`summary`	No	Required with `restore`: label of the restored state in the history.
`version`	Yes	Target version: exactly one of revision_id / version_number / id.
`model_id`	No	Target model UUID. Required for user-scoped API keys; validated against the bound model for model-scoped keys.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds substantial context: the per-plan `max_pinned_versions` cap with a 403 past it, the automatic `restore` backup version, what source settings and mapping rules get restored, and that `warnings[]` names what could not come back. This goes well beyond structured fields.

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?

The description is dense but front-loaded, leading with the core action before per-op detail. It is a single long paragraph with some repetition of the schema's 'exactly one of' constraint, but nearly every sentence carries operational value.

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?

For a destructive, multi-op mutation tool with no output schema, the description spells out both possible return shapes, the backup-version behavior, and the warnings semantics. An agent has enough to invoke each op correctly and interpret results.

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 coverage is 100%, so the baseline is 3, but the description reinforces that `version` takes exactly one of revision_id/version_number/id and explains `summary` is required for restore, adding meaning beyond the field descriptions. It does not elaborate `model_id` scoping beyond what the schema already says, keeping it from a 5.

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 opens with a specific verb set and resource: acts on one version of a model by `op`, where `op` is pin/unpin/restore. Each operation is then defined distinctly, so an agent can select the correct op without opening the schema.

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 clear conditions for each op: pin is a no-op on an already-pinned version, unpin frees a slot and drops out-of-window versions from listing, restore requires `summary`. It also states the target must be inside the plan window or pinned and that the tool is not advertised to read-only keys. It stops short of pointing to sibling tools (e.g. history or diff) as alternatives.

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

All Layerz tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?