Simpler.Asia

studio.snapshot_version

Name a studio project's version (the current one unless version is given) so it is never deleted by retention; naming a named version renames it. At most 20 named versions per project. Adds no new version, so an editor open on the project keeps saving. Refuses: a project_id outside your scope (NOT_FOUND): studio_project_list lists your projects; pass one of their ids; a label that is empty, over 80 characters or more than one line (SIMPLER_STUDIO_SNAPSHOT_LABEL_INVALID): send one line of 1 to 80 characters; 20 names already used (SIMPLER_STUDIO_SNAPSHOTS_FULL): remove one with studio.remove_snapshot; a project with no saved version (SIMPLER_STUDIO_SNAPSHOT_NOTHING_SAVED): save it first; a version the project no longer stores (SIMPLER_STUDIO_VERSION_NOT_STORED): call studio.list_versions and pick a listed one; an environment where names are not switched on yet (SIMPLER_STUDIO_SNAPSHOTS_UNAVAILABLE): saving and restoring still work; ask the owner to apply DB_MEDIA migration 0005. Free.

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": {
      "project_id": "<project_id>",
      "label": "<label>"
    },
    "name": "studio.snapshot_version"
  }
}

Input Schema

Name	Required	Description
`label`	Yes	The version's name, one line, for example "Approved by client".
`version`	No	The version to name; the current version when left out.
`project_id`	Yes	The studio project (vp_...) whose history to use.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=false, so the description carries most of the burden and does well: it discloses that no new version is created, that an open editor keeps saving, that naming an already-named version renames it, and the 20-name ceiling. It stops short of describing the success response or whether renaming affects collaborators.

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?

Front-loaded with purpose and the two key semantics (idempotent-ish naming, no new version) before the refusal list. The error catalog is long and compressed into one run-on sentence, which costs readability but every clause carries remediation an agent needs.

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 no output schema, the description covers side effects, limits, and a full error taxonomy including the migration prerequisite. The only real gap is what a successful call returns or how the named version is identified for later use.

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; the description adds real value on top by explaining that version defaults to the current version and that project_id out of scope yields NOT_FOUND, and it restates the one-line/80-character label rule alongside its error code.

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?

States a specific verb and resource (name a version) plus the outcome (never deleted by retention) and the rename-on-existing behavior. This distinguishes it cleanly from studio.list_versions, studio.restore_version and studio.remove_snapshot without opening any schema.

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?

Explicitly gives the default (current version when version is omitted), the cap of 20 named versions per project, and names concrete alternatives for each precondition failure (studio_project_list, studio.remove_snapshot, studio.list_versions, saving first). An agent can decide and recover without guessing.

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

All Simpler.Asia tools Inspect

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

Need Help?