ppsspp-dfx

Overview Schema Source Related Servers Discussions Admin

ppsspp_step

Control PPSSPP CPU execution: step into, over, or out of code, pause, resume, reset, run until an address, or advance to the next HLE callback.

Instructions

PURPOSE: Aggregate CPU step + run-state control (into / over / out, pause, resume, reset, run_until, next_hle).

USAGE: action='into' / 'over' / 'out' / 'pause' / 'resume' / 'reset' / 'next_hle' take only session_id (optional when exactly one session is active); 'run_until' requires address.

BEHAVIOR: STATE-CHANGE. Advances or changes CPU run state. 'reset' reboots the game (lost in-memory state). 'run_until' sets a temp breakpoint and resumes.

RETURNS: {action, address}.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`action`	Yes	CPU step / run-state operation. Valid values: - 'into': step into (including delay slot). - 'over': step over (skip function calls). - 'out': step out of current function. - 'pause': pause CPU (enter stepping mode). - 'resume': resume CPU (exit stepping mode). - 'reset': reset the game (reboot). - 'run_until': run until the specified address is reached (requires address). - 'next_hle': step to next HLE callback.
`address`	No	Target address, as a hex string (e.g. '0x08804000'). Required for action='run_until'; ignored for all other actions.	0x0
`session_id`	No	Active session ID; omit to auto-resolve when exactly one session is active.

Output Schema

TableJSON Schema

Name	Required	Description
`pc`	Yes	Program counter after step, hex string. For into/over/out/run_until/next_hle this comes from the cpu.stepping broadcast. For pause, extracted via safe_get_pc after CPU enters stepping. '0x00000000' for resume/reset (no trustworthy PC available).
`ticks`	Yes	CPU ticks at step completion (0.0 for pause/resume/reset).
`action`	Yes	'into' / 'over' / 'out' / 'pause' / 'resume' / 'reset' / 'run_until' / 'next_hle'.
`reason`	Yes	Step reason from cpu.stepping broadcast (e.g. 'cpu.stepInto'). Empty for pause/resume/reset.
`address`	Yes	Target address for run_until, hex string (e.g. '0x08804000'); '0x00000000' for other actions.
`related_address`	Yes	Related address for temporary breakpoints, hex string. '0x00000000' when absent.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 16, 2026

TDQS

A4.3/5.0

Behavior4/5

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

The description goes beyond the annotations by explicitly warning that 'reset' reboots the game and loses in-memory state, and that 'run_until' sets a temporary breakpoint and resumes execution. This is meaningful behavioral disclosure for a state-changing tool, though pause/resume side effects are not detailed.

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

Conciseness5/5

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

The description is tightly organized into PURPOSE, USAGE, BEHAVIOR, and RETURNS, with no filler. The most important behavioral caveat is surfaced early, and each sentence earns its place.

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 3 parameters, full schema coverage, annotations, and an output schema, the description supplies everything needed to select and invoke the tool: purpose, invocation constraints, state-change behavior, and return shape. The only notable omission is explicit alternative routing, which is a usage-guidelines concern rather than a completeness gap.

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%, so the schema already fully documents action, address, and session_id. The description usefully summarizes the action-to-parameter relationship but largely duplicates what the schema says, keeping it at the baseline for high coverage.

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 description opens with a concrete purpose ('Aggregate CPU step + run-state control') and enumerates all supported actions, so an agent knows exactly what operations the tool covers. This precise operation set distinguishes it from sibling tools like batch_step, breakpoint, or press_button without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit action-dependent invocation rules: most actions require only session_id, run_until requires address, and session_id is optional when exactly one session is active. However, it does not mention when to prefer alternative tools such as batch_step or wait_breakpoint, so it stops short of full guidance.

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