Skip to main content
Glama
AstralVoidZ
by AstralVoidZ

ppsspp_scan

Read-only

Scan PPSSPP emulator memory for byte patterns, tracked values with narrowing sessions, or charset-aware strings to locate game data and addresses.

Instructions

PURPOSE: Three-mode memory scanner — byte-pattern search, Cheat-Engine-style value scan with narrowing sessions, and charset-aware string harvesting.

USAGE: mode='pattern' + pattern + start_addr/end_addr (migrated from read_memory scan); mode='value' + phase='initial'/value/width → handle, then phase='narrow'/op/value to converge, 'list'/'drop' to manage; mode='strings' + charset + start_addr/end_addr → [{address, text}]. background=true submits a detached job instead (recommended for full-band scans) and returns {action:'submitted', batch_id, ...} — poll ppsspp_batch_status(batch_id=...).

BEHAVIOR: READ-ONLY. Large ranges are read across multiple reads; unreadable regions are skipped per-chunk (one WS round-trip each), but CONSECUTIVE read timeouts (10 s each, >5 in a row) abort the scan — a wedged PPSSPP fails the scan cleanly instead of pinning the session lock. pattern/strings ranges over 2 MiB are AUTO-BACKGROUNDED (returns {action:'submitted', batch_id, ...} even with background=false) — measured: 24 MB @ 4 KiB chunks takes 53-96 s depending on PPSSPP build, always past the ~30s client timeout, while @ 64 KiB chunks it is 3.4-40 s (build-dependent). Value sessions live in a bounded per-server registry (cap 4, FIFO), are bound to the creating session, and the initial-scan cap is 8 MiB foreground / 32 MiB background. Background scans carry a 600 s wall-clock budget; exceeding it fails the job and releases the session. The registry is process-global: parallel sessions share one cap and FIFO order, so another session's scans can evict your handle under load.

ROUTING: what-changed-between-two-points -> ppsspp_diff_memory (snapshots); who-accesses-this-address -> ppsspp_breakpoint(action='trace'); value candidates with known addresses -> read_memory directly.

RETURNS: pattern → {action, address, value: [matches], size}; value initial → {scan_handle, width, candidates, passes}; value narrow → {scan_handle, candidates, passes}; value list → {scan_handle, addresses: [...]}; value drop → {scan_handle, dropped}; strings → {charset, count, strings: [{address, text}]}; background submission (explicit background=true OR pattern/strings range > 2 MiB) → {action: 'submitted', batch_id, session_id, estimated_s}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opNoComparison for value scans (initial + narrow; default eq).eq
modeYesScan mode: - 'pattern': byte-pattern search (hex/ascii) over a range — migrated from read_memory(action=scan). - 'value': Cheat-Engine-style value scan with narrowing sessions (phase: initial → narrow → list → drop; width u8/u16/u32, op eq/ne/lt/gt). - 'strings': charset-aware string harvesting (charset shift_jis/utf8/ascii, min_len, quality filter) — returns [{address, text}].
phaseNoValue-scan phase (value mode): 'initial' scans the range for `value`; 'narrow' re-reads candidates and filters by `op`+`value` (requires explicit session_id; auto-resolve not supported for this phase); 'list' returns current candidates; 'drop' releases the session.
valueNoValue to scan/narrow for (value mode).
widthNoValue width (value mode; default u16).u16
charsetNoString charset (strings mode; default shift_jis).shift_jis
min_lenNoMinimum string length (strings mode; default 6).
patternNoPattern to scan for (pattern mode). Interpreted per pattern_type: 'hex' (default, e.g. 'AABBCCDD') or 'ascii'.
qualityNoCJK-ratio quality floor for shift_jis (strings mode; 0..1, default 0.2; 0 disables). Random bytes can chance-decode to kana — the filter keeps signal. ascii/utf8 have no quality filter — expect noise in code regions.
end_addrNoRange end, exclusive, hex string (same format as `address`).
backgroundNoRun as a detached background job: returns a batch_id immediately; poll ppsspp_batch_status(batch_id=...), cancel via ppsspp_batch_cancel. Value initial cap lifts 8 MiB → 32 MiB in background mode. NOTE: pattern/strings ranges over 2 MiB are auto-backgrounded even when this is false — a foreground scan that outlives the ~30s client timeout is the classic 'frozen session' trap.
chunk_sizeNoBytes per read request during chunked scans (default 65536 — measured ~6x faster end-to-end than the old 4096 default; clamped to [64, 65536]).
session_idNoActive session ID; auto-resolved when exactly one session is active. Required for the pattern / value initial / strings phases, which start a new scan. The narrow / list / drop phases only re-read addresses already recorded by an earlier phase, so they do not need it passed -- but it must still resolve to the same session.
start_addrNoRange start, inclusive, hex string (same format as `address`).
max_resultsNoMaximum number of matches (pattern mode, default 100).
scan_handleNoValue-scan session handle (narrow/list/drop phases).
pattern_typeNoHow to interpret `pattern` (pattern mode). 'hex' (default) or 'ascii'.hex

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hintNo
modeNoScan mode: pattern / value / strings.
sizeNoMatch count (pattern mode).
countNoHit count (pattern & strings modes; matches the value/strings list in this response).
valueNoMatches (pattern mode).
widthNoValue width (u8/u16/u32).
actionNo
passesNoCompleted passes (value narrow).
addressNoScan start (pattern mode).
charsetNoCharset used (strings mode).
droppedNoTrue when the session was dropped.
stringsNoHarvested strings (strings mode).
batch_idNo
addressesNoCandidate addresses (value list).
truncatedNoTrue when the strings hit cap was reached and remaining matches were dropped (narrow the range or raise min_len).
candidatesNoCandidate count (value initial/narrow).
session_idNo
estimated_sNo
scan_handleNoValue-scan session handle.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.7
    • changedInput schema / properties / session_id / description
      Previous value: -"Active session ID; auto-resolved when exactly one session is active (required for pattern/value initial/strings; ignored for narrow/list/drop phases which only re-read candidate addresses — narrow still needs it)."New value: +"Active session ID; auto-resolved when exactly one session is active. Required for the pattern / value initial / strings phases, which start a new scan. The narrow / list / drop phases only re-read addresses already recorded by an earlier phase, so they do not need it passed -- but it must still resolve to the same session."
  2. Addedv0.1.6

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnly/destructive/idempotent; the description adds substantive behavior the annotations cannot carry — consecutive-timeout abort rules, per-chunk skipping of unreadable regions, auto-backgrounding above 2 MiB, a FIFO registry cap of 4 shared process-globally (other sessions can evict your handle), an 8/32 MiB initial-scan cap, and a 600 s job budget. This is exactly the operational context an agent needs before committing to a long scan.

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 front-loaded and sectioned (PURPOSE/USAGE/BEHAVIOR/ROUTING/RETURNS), so an agent can stop reading early. It is long, and the auto-backgrounding rule is repeated in USAGE, BEHAVIOR, and the background parameter, which is mild redundancy for a 17-parameter tool.

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 three-mode, 17-parameter tool with concurrency and timeout hazards, the description covers mode selection, session lifecycle, failure modes, and background handoff. An output schema exists, so the RETURNS section is a convenience rather than a necessity, and nothing an agent needs to invoke this 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?

Schema description coverage is 100%, so the baseline is 3; the description goes further by specifying cross-parameter contracts (which params matter per mode, that narrow/list/drop must resolve to the same creating session, that the initial cap lifts under background=true). It doesn't restate hex-format syntax or enum values already in the schema, which is the right restraint.

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 PURPOSE line names a specific verb+resource split into three concrete modes (byte-pattern search, value scan with narrowing, charset-aware string harvesting), which is far more than a restatement of the name. Combined with the ROUTING section naming siblings (ppsspp_diff_memory, ppsspp_breakpoint, read_memory), an agent can place this tool precisely in the family.

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?

The USAGE block gives explicit parameter combinations per mode and the phase workflow (initial → narrow → list/drop), and the ROUTING block states when to use a sibling instead ('what-changed-between-two-points -> ppsspp_diff_memory', 'who-accesses-this-address -> ppsspp_breakpoint', 'known addresses -> read_memory directly'). When-not guidance is explicit, including the 'frozen session' trap.

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