PyMemoryEditor

Official

Overview Schema Source Related Servers Discussions Admin

find_pointer_paths

Read-only

Find static pointer paths that reach a given dynamic memory address, turning temporary values into reusable chains for consistent access across runs.

Instructions

Reverse-scan for static pointer paths that reach an address.

The inverse of resolve_pointer_chain, and the step that turns a throwaway find into something reusable: an address from scan_value is different every run, but a path rooted in a module's image is the same recipe every time. Run this on the address you confirmed, then replay the best path in the next run with resolve_pointer_chain.

:param target_address: the dynamic address to find paths to. :param max_depth: pointer levels to follow. Cost grows sharply with depth; 1–4 is the useful range and 3 is a good default. A chain needs at least one level, so 0 clamps to 1 rather than to the default — and null means "use the default", as it does for every argument here. :param max_offset: largest offset a single hop may add — effectively the assumed struct size. Larger finds more and noisier paths. An explicit 0 is meaningful rather than "unset": it keeps only hops that point exactly at the address. null means "use the default" (1024) — it used to mean 0, i.e. the narrowest search possible, which is the opposite of what a client sending null for an unset field intends. :param max_results: stop after this many paths.

This is the most expensive tool here, and it runs in two phases: it maps every pointer in the target's writable memory, then walks that map backwards. Only the first phase reports progress, so the server's time budget bounds it precisely and the second phase only between paths — a deep walk that finds nothing can still run long. Expect seconds to minutes on a large process, and start shallow.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`max_depth`	No
`max_offset`	No
`session_id`	Yes
`max_results`	No
`target_address`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare read-only, open-world, non-destructive, non-idempotent behavior, but the description adds substantial operational context beyond them: two-phase execution, progress reporting only in the first phase, time-budget limitations, seconds-to-minutes runtime, and sharply increasing cost with depth. These are exactly the behavioral traits an agent needs before invoking an expensive 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 with purpose and structured by parameter, and its length is largely justified by the tool's complexity and expense. Still, the historical note about max_offset formerly meaning 0 and some repeated null-default phrasing are more verbose than the agent strictly needs.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description is otherwise very complete for a complex, expensive read operation, but omitting session_id semantics and including null guidance that conflicts with the integer-only schema keep it from being fully complete.

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?

With 0% schema description coverage, the description carries the burden and does so well for max_depth, max_offset, and max_results, including clamping, default/null behavior, and cost implications. However, the required session_id parameter is never described, and the stated null semantics for integer fields are not reflected in the input schema, leaving a notable gap.

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?

States a specific verb (reverse-scan) and resource (static pointer paths that reach an address), and explicitly positions itself as the inverse of resolve_pointer_chain. An agent can distinguish it from scan_value, refine_scan, and resolve_pointer_chain without opening any schema.

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?

Gives direct usage guidance: run this on the address you confirmed, then replay the best path with resolve_pointer_chain. It also names the relevant sibling context (scan_value, resolve_pointer_chain) and advises starting shallow, so when and how to use it are explicit.

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

Deploy Server