Skip to main content
Glama

find_instances

Read-onlyIdempotent

Enumerate live objects of a class through GC liveness to obtain instance pointers for reading fields, writing values, or hooking methods, instead of hunting for them via hooks.

Instructions

枚举类的活对象实例(拿 instance 指针的正路 —— 此前只能靠 Hook 碰运气)。走 GC liveness;IL2CPP 可用(实测毫秒级)、Mono 受官方限制会如实报 unsupported(不用空列表冒充「没有实例」),值类型无堆实例则明确报错。

为什么需要它:read_field_value / set_field_value / hook_method 都要一个对象指针,而在此之前唯一的办法是「Hook 一个恰好会收到 该对象的函数,从 args[0] 里捡」—— 那是碰运气。本工具直接问运行时 「这个类现在有哪些实例」。

实现走 GC liveness(Unity 自家内存分析器用的那套导出)。 注意:il2cpp_class_get_instances 这种「按类直接列实例」的导出 并不存在(5 个真实样本实测),别照着那个名字找。

引擎差异(都是如实声明,不是缺陷):

引擎

情况

IL2CPP

✅ 可用,实测毫秒级(GameObject/Transform/String 各约 10ms)

Mono

⚠️ 官方头文件写明堆遍历「只在 pre-stop-world 回调内有效」,从外部线程调用不保证可用。拿不到时本工具返回 ok:false + unsupported:true,不会用空列表冒充「没有实例」

两个明确的限制:

  • 值类型(struct)没有堆实例,会直接报错说明,而不是返回空列表。

  • 实例数超过 max_count 时截断,overflow:true 表示「还有更多」。

⚠️ 返回的实例包含派生类(这是最容易踩的坑): find_instances(name="Transform", namespace="UnityEngine") 拿回来的 实测全是 RectTransform —— 因为 Unity 里 UI 节点都是 RectTransform, 而它们是 Transform 的派生类。这不是缺陷(liveness 语义如此), 但用基类的字段偏移去读派生类实例可能出错。

所以返回里带 instances: [{pointer, class_name}] 与 exact_class_count / derived_count / class_name_counts, 请按 class_name 甄别你要的是哪一种。

⚠️ 拿到的指针只在游戏继续运行时有意义:对象可能随时被 GC 回收, 或随场景切换失效。应当立即使用(读字段 / 写字段 / 下 Hook), 不要跨多个步骤长期保存。

Args: name: 类名(嵌套类型传完整嵌套名,同 runtime_class_info)。 namespace: 命名空间。 image: 程序集名。 max_count: 最多返回多少个实例(默认 100,上限 100000)。

Returns: {ok, class, engine, count, pointers: [...], instances: [{pointer, class_name}], exact_class_count, derived_count, class_name_counts, overflow} 也可能带 unsupported(引擎不支持这条路径,如 Mono 的时机限制) 或 warning(恢复 GC world 失败,游戏可能卡住)。

Input Schema

NameRequiredDescriptionDefault
nameYes
imageNo
max_countNo
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 declare read-only, idempotent, non-destructive, open-world behavior, but the description adds substantial runtime context: GC liveness semantics, IL2CPP vs Mono differences, `unsupported` handling, truncation via `overflow`, derived-class inclusion, pointer lifetime, and a possible GC-restore warning. These are exactly the behavioral traits an agent needs beyond the annotation hints.

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 definition is long, but it is well structured with a front-loaded summary, engine table, limitations, warnings, args, and returns. Some implementation anecdotes and repeated warnings could be tightened, but nearly all content serves correct invocation.

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?

There is no output schema, but the description fully documents the return shape, including `ok`, `engine`, `pointers`, `instances`, `exact_class_count`, `derived_count`, `class_name_counts`, `overflow`, plus `unsupported` and `warning`. Given the engine complexity and pointer-lifetime caveats, this is complete enough for correct use.

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: `name` requires full nested names, `namespace` and `image` are identified, and `max_count` is given a default and upper bound. This fully compensates for the bare schema.

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?

The description opens by stating a specific verb and resource: enumerate live object instances of a class and obtain `instance` pointers. It clearly contrasts this with the prior Hook-based workaround and ties the output to `read_field_value` / `set_field_value` / `hook_method`, so an agent can distinguish it from related siblings.

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?

It explains exactly when the tool is needed: those other tools require an object pointer, and this is the direct way to get one. It also states when it will not work, including Mono timing restrictions and struct value types, and frames Hook-based discovery as the inferior alternative.

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