Skip to main content
Glama
AstralVoidZ
by AstralVoidZ

ppsspp_search_memory_info

Read-onlyIdempotent

Search PPSSPP memory-tracking metadata for region tags matching a string, returning matching extents to aid debugging.

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
NameRequiredDescriptionDefault
endNoOptional end address for the search range, as a hex string (e.g. '0x08810000'). If omitted, PPSSPP searches to the end of the address space.
typeNoOptional type filter (e.g., 'texture', 'vertex'). If omitted, all region types are returned.
matchYesCase-insensitive substring to match against memory region tags (e.g., 'texture', 'vertex', 'framebuf').
addressNoOptional start address for the search range, as a hex string (e.g. '0x08804000'). If omitted, PPSSPP searches the entire address space.
session_idYesActive session ID.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rawYesRaw `memory.info.search` response from PPSSPP.
textYesUnified text representation: one line per region, formatted as '0x{ADDR:08X}-0x{END:08X} {TYPE} {TAG}'.
countYesNumber of regions in the result.
regionsYesMatching 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.

  1. Addedv0.1.6

TDQS

A3.6/5.0
Behavior3/5

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

The 'READ-ONLY' statement merely restates readOnlyHint/destructiveHint=false already in annotations, and the RETURNS shape is largely covered by the output schema. The one genuinely additive detail is 'Returns a single extent per matching tag', which clarifies result granularity, but permissions, pagination/limits, and failure modes are unaddressed.

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?

Four labeled sections, front-loaded PURPOSE, zero filler sentences. The agent can parse purpose, inputs, safety, and return shape at a glance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations carrying the safety profile, a 100%-covered schema, and an output schema describing the {regions[], count, raw, text} return, the description covers what an agent needs to invoke correctly. Only cross-tool routing guidance 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 all five parameters (including hex-string address/end semantics and the type filter examples) are already documented in the schema. The description only repeats the case-insensitive substring nature of 'match' and the optionality of the filters, adding nothing new.

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

Purpose4/5

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

States a specific verb and resource: searching PPSSPP's memory-tracking metadata for allocation/texture tags. This is distinguishable from siblings like ppsspp_search_disasm (disassembly) and ppsspp_scan (memory scanning), though no sibling is named explicitly.

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

Usage Guidelines3/5

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

The USAGE line identifies the required inputs (session_id + match) and the optional filters, which implies when the tool applies. However, it gives no guidance on when to prefer this over ppsspp_search_disasm, ppsspp_scan, or ppsspp_read_memory, and no exclusions.

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