Skip to main content
Glama

set_field_value

DestructiveIdempotent

Writes type-safe values to a game object's IL2CPP, Mono, or Unreal field by auto-resolving the offset and encoding. Use it to modify field values with overflow checks and optional write-back verification.

Instructions

写对象字段值(read_field_value 的对称入口):自动查偏移、按类型定宽度与编码、写完回读核对。溢出直接报错不截断;引用类型字段拒绝(改引用属改逻辑,请用 eval_script/Hook)。

⚠️ 危险操作:写错地址或写错值会立刻让游戏崩溃或行为异常。 写之前务必先 read_field_value 读一次,确认偏移与当前值符合预期。

与 write_memory 的分工(不是重复工具): write_memory 要「地址 + 裸十六进制字节」,是原始内存入口; 本工具要「哪个对象的哪个字段 + 一个语义化的值」,是字段入口。 它替你做了三件容易做错的事:查真实偏移、按字段类型定宽度、 按字段类型选整数/浮点/布尔的编码。

写几个字节由字段类型决定(与读取同一张表):bool 1、int16 2、 int32/float 4、long/double/引用类型 8。溢出直接报错,不静默截断 —— 把 300 写进 1 字节字段如果截成 44,你会看到 ok:true 却拿到没要的值。

引用类型字段(class/string/数组)会被拒绝:field_type 认不出基础类型 且宽度为 8 时,本工具报错而不是去写一个指针 —— 换对象引用属于改逻辑, 应该用 eval_script 或 Hook,而不是改一个字段的字节。

静态字段:把 instance 传成 "static"(或空串)即可写静态字段 (与 read_field_value 同一套约定)。静态字段走探针的 *_field_static_set_value,没有「实例 + 偏移」这回事;返回里 is_static 为 true、并给出 declared_by(它可能声明在基类上)。 ⚠️ 静态字段常被全局逻辑读取,改了会影响整个游戏——返回里带 value_before,出问题可以用它写回。

Args: instance: 对象指针(十六进制)。可用 find_instances 拿, 或从 Hook 事件的 args[0] 拿。 传 "static" 表示写静态字段(不需要对象指针)。 name: 类名。 field: 字段名。 value: 要写入的值。整数按字段宽度与符号解释;浮点字段给数字; bool 字段给 true/false/1/0;认不出类型时给 0x... 字节串。 namespace: 命名空间。 image: 程序集名。 verify: 写完后立刻回读一次并放进返回(默认 True)。 这是为了不留「假成功」:写完把实测值给你,而不是只报 ok。

Returns: {ok, class, field, instance, offset, field_address, wrote_hex, write_width, write_kind, value_before?, read_back?...}

Input Schema

NameRequiredDescriptionDefault
nameYes
fieldYes
imageNo
valueYes
verifyNo
instanceYes
namespaceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark this as destructive and non-read-only, but the description adds substantial context beyond them: overflow errors instead of truncation, rejection of reference-type fields, read-back verification, static-field behavior, and value_before rollback information. It also warns clearly that incorrect addresses or values can crash the game.

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 danger warnings, and the sectioning makes it easy to scan. It is appropriately detailed for a destructive seven-parameter tool, though some static/verify details are repeated between the body and the Args section and could be tightened slightly.

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 the destructive mutation behavior, zero schema description coverage, and no output schema, the description is complete enough for safe invocation. It documents return fields, verification behavior, refusal cases, and the static-field special path.

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 description coverage is 0%, so the description must carry parameter meaning, and it does so for all seven parameters. It explains instance as a hex pointer or "static", value encoding by field type, verify as read-back verification, and what name/field/namespace/image refer to.

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: writes an object field value, and explicitly frames itself as the symmetric entry point to read_field_value. It also distinguishes itself from write_memory and eval_script/Hook, so an agent can identify the correct tool without opening sibling schemas.

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 usage rules: read the field first with read_field_value, use write_memory for raw address+bytes, use eval_script/Hook for reference replacement, and pass "static" to target static fields. It also names when the tool will refuse a write, which is unusually actionable.

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