Skip to main content
Glama
JeanExtreme002

PyMemoryEditor

Official

scan_value

Read-only

Scan a running process's memory for a specified value to start Cheat Engine-style searches, returning a scan ID and match count for later refinement.

Instructions

Scan the target's memory for a value. The first step of the loop.

This is Cheat Engine's "First Scan". It returns a scan_id, a match count and a few sample addresses — not the addresses themselves, which routinely number in the tens of thousands. Narrow the set with refine_scan after the value changes in the target, and repeat until a handful remain; then read them with list_scan_results.

:param value_type: int, float, bool, str or bytes. :param value: the value to match. Hex is accepted for int ("0x64") and required for bytes ("DEADBEEF"). :param scan_type: exact (default), not_exact, bigger, bigger_or_exact, smaller, smaller_or_exact, between or not_between. :param end_value: the upper bound, required by between / not_between and rejected otherwise. :param bufflength: width in bytes — 4 for a typical int, 8 for a double. Leave at 0 for the default (int→4, float→8, bool→1) or, for str / bytes, to infer it from value.

Numeric widths are restricted to 1, 2, 4 or 8 for ``int``, 4 or 8
for ``float``, and 1 for ``bool``; anything else is refused rather
than half-supported. Text is capped, inferred or not — see
``server_info().limits``.

:param writable_only: restrict the scan to writable memory (the default). A value the program changes lives in writable memory, so this usually cuts the work and the false positives by an order of magnitude. Turn it off only when hunting constants. :param aligned: true (default) compares a numeric value only at addresses that are multiples of its width, which is where programs keep numbers and what every refine assumes. Pass false to find a number stored at any byte offset (packed data, a value inside a byte buffer); it costs bufflength passes over memory. No effect on str / bytes.

A scan stops early at the server's result cap or time budget; when it does, the result sets partial and explains what to narrow. Refining a partial set can converge on the wrong address, because the right one may never have been in it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueYes
alignedNo
end_valueNo
scan_typeNoexact
bufflengthNo
session_idYes
value_typeYes
writable_onlyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.4.0
    • addedInput schema / properties / aligned
      Added value: +{
      +  "default": true,
      +  "title": "Aligned",
      +  "type": "boolean"
      +}
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations (which only cover read/non-destructive semantics) by disclosing that results are truncated to sample addresses rather than full address lists, that scans stop early at a server result cap or time budget and set a "partial" flag, and that the cap can silently poison a refine chain — behavior an agent could not infer from the schema.

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?

Front-loaded with the one-line purpose and then organized per-parameter, so nothing is wasted, but the prose is dense and the bufflength/aligned paragraphs run long for what they convey. Justified by the 8 parameters at 0% schema coverage, yet still slightly heavier than needed.

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?

Covers the full call-and-response loop, parameter edge cases, default rationale, server-side limits referral, and partial-result handling. Although an output schema exists, the description still explains what the scan returns without redundantly restating every field.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the full burden, and it does: value_type values, hex conventions for int/bytes, the full scan_type enum (absent from the schema), end_value's required/rejected conditions, bufflength's per-type defaults and the accepted widths (1/2/4/8, 4/8, 1), plus the meaning and default reasoning behind writable_only and aligned. Only session_id is left undocumented, which the sibling context makes self-evident.

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 and resource ("Scan the target's memory for a value") and immediately positions it in the workflow ("The first step of the loop"), which cleanly separates it from refine_scan and list_scan_results.

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?

Explicitly routes the agent through the loop: scan first, then "Narrow the set with refine_scan after the value changes in the target", then "read them with list_scan_results". It also states the alternative conditions for turning off writable_only ("only when hunting constants") and aligned, plus the caveat that refining a partial set can converge on the wrong address.

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