Skip to main content
Glama
AstralVoidZ
by AstralVoidZ

ppsspp_session

Start, stop, and inspect PPSSPP debug sessions, and wait for the emulated CPU to boot before memory access. Prevents early-read failures with a clear boot-ready check.

Instructions

PURPOSE: Start / stop / inspect PPSSPP debug sessions — action=start / stop / get / wait_ready; wait_ready blocks until the emulated CPU is up.

USAGE: action='start' needs iso_path (pass wait_ready=true to block until the CPU is up in the same call); stop/get/wait_ready need session_id. Call wait_ready AFTER start and BEFORE any memory tool — PPSSPP answers WebSocket before the CPU boots. start(resilient=true) self-heals boot wedges (blacklist quarantine + relaunch with the same session_id, ≤2 retries).

BEHAVIOR: STATE-CHANGE. start spawns a PPSSPP subprocess + WS debugger; stop terminates it (never taskkill the process yourself); wait_ready polls the probe lock-free and fails [BOOT_TIMEOUT] on wedge suspicion; get is read-only.

RETURNS: SessionResponse {session_id, iso_path, pid, ws_url, created_at, last_active_at, exec_count, ws_connected, recovered, ppsspp_version} — or, for wait_ready, {action, ready, elapsed_s, probe_addr, probe_value, note}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesSession operation. Valid values: - 'start': launch a new PPSSPP session (requires iso_path). Set wait_ready=true to block until the emulated CPU is up (same probe/budget semantics as 'wait_ready'). - 'stop': terminate an existing session (requires session_id). - 'get': query session health (requires session_id). - 'wait_ready': block until the emulated CPU has started (requires session_id). Call this after 'start' BEFORE any memory/disassembly tool — PPSSPP answers WebSocket before the ISO finishes booting, and early reads fail with 'CPU not started'.
iso_pathNoAbsolute path to the ISO file (required when action=start).
resilientNoaction=start only: self-healing boot — on wedge evidence (CPU-ready probe exhausted, handshake never accepted, process died) the launcher is torn down, the GPU-backend failure blacklist is quarantined (rename), and the session relaunches with the SAME session_id up to 2 retries; the response carries recovered=N (0 = first launch). Exhaustion raises [BOOT_TIMEOUT]. Ignored in fake mode.
timeout_sNoBoot budget in seconds (action=wait_ready, action=start with wait_ready=true, or the per-attempt CPU-ready budget when action=start with resilient=true; default 75, clamped to [1, 300]).
probe_addrNoHex address polled by the readiness probe (action=wait_ready, action=start with wait_ready=true, or the resilient-start gate; default '0x08804000', the project's top.prx load base).0x08804000
session_idNoSession ID (required when action=stop / get / wait_ready).
wait_readyNoaction=start only: block until the emulated CPU is ready before returning (same probe/budget as action=wait_ready; raises [BOOT_TIMEOUT] on wedge suspicion). Fake test mode is ready immediately. Default false keeps the historical two-call flow.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pidNoPPSSPP process PID (None if stopped).
ws_urlNoWebSocket URL (ws://host:port/debugger).
iso_pathNoAbsolute path to the ISO file.
restoredNoF-6(a): 1 when this session was restored from sessions.json (a previous server run left it behind) rather than started fresh in this process — its game state may be stale.
recoveredNoH2: resilient-start relaunch count (0 = the first launch succeeded; >0 means the game state was reset by a wedge heal — breakpoints need re-arming).
created_atNoISO 8601 timestamp of session creation.
exec_countNoNumber of tool calls made against this session.
session_idNoSession UUID-like identifier.
ws_connectedNoTrue if WebSocket is currently connected.
last_active_atNoISO 8601 timestamp of last tool call.
ppsspp_versionNoPPSSPP build fingerprint captured from the version handshake (None until the session transport binds).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond annotations, the description details state-change semantics: start spawns a subprocess and WS debugger, stop terminates it, wait_ready polls a probe and fails with [BOOT_TIMEOUT], and get is read-only. It also discloses the self-healing quarantine and relaunch behavior with the same session_id, adding substantial behavioral context that annotations alone do not provide.

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 long but well-organized into PURPOSE, USAGE, BEHAVIOR, and RETURNS sections, and every sentence carries actionable detail. It is appropriately sized for a multi-action tool, though it could be trimmed slightly without losing meaning.

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?

Given the tool's complexity (7 parameters, 4 actions, self-healing behavior), the description covers start, stop, get, and wait_ready flows, return shapes, failure modes, and ordering prerequisites. The output schema exists and the RETURNS section states what each response contains, so nothing an agent needs to call it correctly is missing.

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?

Input schema already covers all parameters at 100%, so the baseline is 3. The description adds value by tying parameters to behavior ('wait_ready=true to block until the CPU is up in the same call', resilient self-heals with up to 2 retries) and by giving operational warnings like 'never taskkill the process yourself'. This goes beyond simple parameter repetition, though the schema already does heavy lifting.

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?

Description opens with 'PURPOSE: Start / stop / inspect PPSSPP debug sessions' and enumerates action values start/stop/get/wait_ready, giving a precise verb-resource mapping. It differentiates from the sibling ppsspp_session_list by focusing on lifecycle operations rather than listing sessions.

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?

Usage section explicitly states which action requires which parameter ('action='start' needs iso_path', 'stop/get/wait_ready need session_id'), and gives ordering guidance ('Call wait_ready AFTER start and BEFORE any memory tool'). It even warns against taskkilling and explains resilient mode's retry behavior, leaving no ambiguity about when or how to use the tool.

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