playcal

Overview Schema Source Related Servers Discussions Admin

playcal_playtest

Repeats playtest observations to classify pass/fail/skip runs, distinguish flaky from consistent failures, and save results as PC0 events for calibration.

Instructions

run observe N times: a checklist of pass/fail/skip per run, red vs flaky (inconclusive), runs saved as PC0 events for calibrate

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "playcal_playtest"
  }
}

Input Schema

Name	Required	Description	Default
`game`	No	game name in the events (default game)	game
`name`	No	screenshot file name without .png (default observe)	observe
`read`	No	Editor read to diff before and during play (default "scene get_hierarchy")	scene get_hierarchy
`level`	No	level name in the events (default playtest)	playtest
`limit`	No	most diff entries to list (default 50)
`scene`	No	godot only: scene to run instead of the main scene (res://...)
`shots`	No	where the red-run screenshot goes, relative to the Unity project (default .playcal/observe)	.playcal/observe
`engine`	No	unity talks to the open Editor; godot runs the main scene headless (default unity)	unity
`events`	No	write the runs as PC0 events (JSONL) for report and calibrate
`expect`	No	check on the read during play, same syntax as playcal loop --expect. Repeatable
`ignore`	No	field to leave out of the diff, repeatable (default: instanceId, isDirty)
`repeat`	No	run N times; some red and some green is inconclusive (exit 7), see playcal playtest
`no_play`	No	don't touch Play Mode; diff two reads --seconds apart
`no_shot`	No	never take a screenshot
`seconds`	No	how long to let the game run before the second read (default 3)
`timeout`	No	seconds to wait for a ready Editor (default 120)
`game_version`	No	game_version in the events (default dev)	dev
`project_path`	No	Unity project folder (needed when several Editors are open), or the Godot project folder

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Nov 7, 2026

TDQS

C2.7/5.0

Behavior3/5

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

With no annotations, the description carries the burden, and it does disclose some real behavior: repeated runs, red vs inconclusive classification, exit 7 on flaky results, and that runs are written as PC0 events. However it never warns that the tool drives Play Mode, takes screenshots, or waits on an open Editor (all only discoverable via parameter descriptions), which are the riskiest side effects for an agent to trip over.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single front-loaded line with zero filler, which is the right instinct. But the clipped note-style syntax ('red vs flaky (inconclusive), runs saved as PC0 events for calibrate') sacrifices parseability, so brevity costs more than it saves for an 18-parameter tool.

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 high-complexity tool: 18 parameters, two engine backends, repeated runs, screenshot and event-file side effects, a special exit code, and no output schema or annotations. One telegraphic sentence is far from sufficient to describe correct invocation and result interpretation for that surface area.

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% across 18 parameters, so the schema already documents defaults, the engine enum, and the effect of each flag. The description adds essentially nothing about parameter interaction (repeat vs seconds vs no_play) beyond what the schema states, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The verb+resource is discernible (run observe N times, produce a pass/fail/skip checklist, classify red vs flaky), and it names the sibling 'observe' it builds on. But the telegraphic phrasing ('a checklist of pass/fail/skip per run, red vs flaky (inconclusive)') is terse enough that an agent must infer this is an engine playtest harness rather than, say, a visual diff tool, and it never distinguishes itself from playcal_observe, playcal_loop, or playcal_visual.

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 or when-not-to-use guidance and no comparison to the many overlapping siblings (playcal_observe, playcal_loop, playcal_visual, playcal_calibrate). Only the downstream hint 'for calibrate' implies a workflow position. An agent cannot tell from this sentence when to pick playtest over running observe directly.

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