ppsspp-dfx

Overview Schema Source Related Servers Discussions Admin

ppsspp_memory_info_search

Read-onlyIdempotent

Search PPSSPP memory regions by tag to locate allocations or textures, using optional address and type filters for targeted results.

Instructions

PURPOSE: Search PPSSPP's memory-tracking metadata for allocation/texture tags matching a string.

USAGE: session_id + match (case-insensitive substring, required); optional address/end/type filters.

BEHAVIOR: READ-ONLY. Returns a single extent per matching tag.

RETURNS: {regions[], count, raw, text}.

Input Schema

TableJSON Schema

Name	Required	Description
`end`	No	Optional end address for the search range, as a hex string (e.g. '0x08810000'). If omitted, PPSSPP searches to the end of the address space.
`type`	No	Optional type filter (e.g., 'texture', 'vertex'). If omitted, all region types are returned.
`match`	Yes	Case-insensitive substring to match against memory region tags (e.g., 'texture', 'vertex', 'framebuf').
`address`	No	Optional start address for the search range, as a hex string (e.g. '0x08804000'). If omitted, PPSSPP searches the entire address space.
`session_id`	Yes	Active session ID.

Output Schema

TableJSON Schema

Name	Required	Description
`raw`	Yes	Raw `memory.info.search` response from PPSSPP.
`text`	Yes	Unified text representation: one line per region, formatted as '0x{ADDR:08X}-0x{END:08X} {TYPE} {TAG}'.
`count`	Yes	Number of regions in the result.
`regions`	Yes	Matching memory regions. Each entry has type / address / size / ticks / pc / tag / allocated (field presence depends on PPSSPP version).

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 declares READ-ONLY, which is consistent with the annotations, and adds value beyond them with 'Returns a single extent per matching tag'. This is useful behavioral context not captured by readOnlyHint or idempotentHint alone.

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 compact and organized into four labeled sections, with the purpose front-loaded. Every sentence contributes either a selection cue, invocation detail, behavioral trait, or return shape; there is no filler.

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 a full 100% parameter schema, a rich annotation set, and an output schema, the description covers the remaining needs: purpose, required/optional arguments, read-only behavior, and return structure. Nothing an agent needs to invoke it correctly is missing.

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 input schema already documents all five parameters. The description restates the required/optional split but adds no new meaning beyond the schema, matching the baseline of 3 for high schema 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 names a specific verb ('Search') and a precise resource ('PPSSPP's memory-tracking metadata') and narrows it further to allocation/texture tags. This is distinct from sibling tools like read_memory, memory_map, and search_disasm, so an agent can tell them apart.

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?

The USAGE section states exactly which parameters are required (session_id + match) and which are optional filters (address/end/type). It provides clear context for calling the tool, though it does not explicitly name alternatives or when-not-to-use conditions.

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