Skip to main content
Glama

read_field_value

Read-onlyIdempotent

Reads a field's raw memory value for an instance or static field, automatically resolving its offset and address and using the field type to determine how many bytes to read.

Instructions

读取某个实例或静态字段的原始值(静态字段传 instance="static")。读几个字节由字段类型决定(bool 1 / int 4 / long·double·引用 8)。

自动完成三步:运行时查字段偏移 → 算出字段地址 → 读内存。

读几个字节由字段类型决定(_field_read_width):bool 读 1、int 读 4、 long/double/引用类型读 8。原来固定读 8 字节,4 字节字段会连带读到相邻 字段的 4 个字节 —— 既给出无意义的 as_int64(两个字段拼出来的数), 也会在字段贴近页尾时把一次本可成功的读取变成假失败。

返回里 read_width 是实际读取的字节数,解释字段也按宽度给: 1 → as_int8/as_uint8/as_bool;2 → as_int16/as_uint16; 4 → as_int32/as_uint32/as_float;8 → 再给 as_int64/as_double/as_pointer。

局限:只适合基础类型字段(int/float/bool/enum 等)。 引用类型字段读到的是指针,要读内容需再解引用(用 read_memory)。

静态字段:把 instance 传成 "static"(或空串)即可读静态字段, 不需要对象指针。这是 Mono 上拿单例指针的正路 —— Mono 的 find_instances 受官方限制常常返回 unsupported,而 GameManager.Instance 这类静态字段读出来的 as_pointer 就是实例指针 (宽度 8 的引用类型),可以直接喂给本工具的 instance 去读实例字段。 静态字段会连同基类一起查(declared_by 告诉你它声明在哪个类上)。

Args: instance: 对象指针(十六进制)。可从 Hook 事件的 args[0] 里拿到。 传 "static" 表示读静态字段(不需要对象指针)。 name: 类名。 field: 字段名。 namespace: 命名空间。 image: 程序集名。

Input Schema

NameRequiredDescriptionDefault
nameYes
fieldYes
imageNo
instanceYes
namespaceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds material behavior beyond them: per-type read width, the rationale for width-based reads (avoiding adjacent-field contamination and false failures near page ends), the read_width return field and the cast variants keyed by width, static field lookup including base classes (declared_by), and the 'runtime offset → address → read' sequence.

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

Conciseness3/5

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

The core facts are front-loaded, but the width rule (bool 1 / int 4 / long·double·ref 8) is stated twice in near-identical wording, and the historical aside about previously always reading 8 bytes is a changelog rather than guidance for an agent. Real content, but trimmed it would be materially shorter.

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?

No output schema exists, yet the description explains the return shape (read_width plus the as_* casts by width), covers the static-field path, and names the failure mode it avoids. For a 5-parameter read tool, an agent has everything needed to call and interpret it.

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?

Schema description coverage is 0%, so the description must document all parameters. It does: instance (hex pointer, sourced from Hook event args[0], or "static"), name (class), field (field name), plus namespace and image. The latter two are only labeled ("命名空间", "程序集名") with no format or sourcing guidance, which keeps this from being a 5.

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: reads the raw value of an instance or static field. It also scopes the tool by field type (basic types vs. reference types whose contents require read_memory) and by instance mode ("static" for static fields), so an agent can distinguish it from read_memory and set_field_value without opening the 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 explicit routing: use read_memory to dereference pointer fields, pass instance="static" for static fields, and explains that a static singleton field (for example, GameManager.Instance) is the intended way to obtain an instance pointer on Mono, since find_instances often returns unsupported. It also states the limitation (basic-type fields only) and the payload it returns (as_pointer), which is enough for an agent to choose it correctly.

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