Skip to main content
Glama
Sign In
playcal

playcal

by RizgarOzan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

playcal_lock

Prevents concurrent edits by locking Unity/Godot scenes and assets for one agent at a time; supports take, release, list, and check actions with TTL-based ownership.

Instructions

lock scenes and assets so several agents don't edit the same file at once

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_lock"
  }
}

Input Schema

NameRequiredDescriptionDefault
dirNowhere locks live (default .playcal/locks).playcal/locks
ttlNohow long a lock lasts, e.g. 90s, 30m, 2h (default 30m)
forceNorelease: also drop someone else's lock
ownerNowho holds the lock (default $PLAYCAL_OWNER)
pathsNoscene or asset paths, e.g. Assets/Scenes/Level4.unity
actionYestake PATH...: lock all or none. release PATH...: unlock yours. list: live locks. check PATH...: exit 1 if someone else holds one

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

B3.1/5.0
Behavior2/5

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

No annotations exist, so the description carries the full disclosure burden, yet it omits the behaviors that matter most for a coordination primitive: locks expire after a TTL, a 'release' action exists, 'force' can drop another agent's lock, and 'check' signals conflict via exit code. The mutual-exclusion purpose is conveyed, but an agent could invoke it without knowing locks are time-limited or that forced takeover is possible.

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?

A single front-loaded sentence with the verb and the rationale, no filler or repetition. Its brevity is efficient rather than padded, though it leans toward under-specification, which is penalized under contextual completeness rather than here.

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 six-parameter, four-action tool with no annotations and no output schema, so the description should explain action modes, TTL expiry, ownership, and the all-or-none/exit-code contracts. None of that appears, leaving the agent dependent entirely on reading the schema before it can call the tool safely.

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%, including per-action semantics for the 'action' enum, so the schema does the heavy lifting. The description only echoes that paths refer to scenes and assets and adds no syntax, default, or interaction detail beyond the schema. Baseline 3 is appropriate.

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?

States a specific verb+resource pair ('lock scenes and assets') plus the motivating scenario (multiple agents editing the same file). The tool's domain is unmistakable against the sibling set (observe, query, replay, snap, etc. cover different concerns). It stops short of naming any sibling explicitly, which keeps it at 4 rather than 5.

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?

The clause 'so several agents don't edit the same file at once' implies the usage context (concurrent multi-agent work), but there is no explicit when-to-use rule, no guidance on pairing take with release, and no statement of when locking is unnecessary. Usage is inferable but left to the agent to reconstruct.

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