Skip to main content
Glama

runtime_class_info

Read-onlyIdempotent

Retrieves real runtime field offsets and method addresses (RVA) for a class to resolve direct hook targets in IL2CPP games. Rejects ambiguous short names; nested types require full nested names.

Instructions

查类的运行时实况:真实字段偏移与方法真实地址(RVA)。

嵌套类型请传完整嵌套名(search_classes 的 nested_name); 短名命中多个时拒绝并给 candidates,不替你猜。

与静态 class_detail 的区别(很重要): · 静态元数据里的字段没有偏移(偏移是运行时泛型实例化后才定的) · 静态元数据里的方法只有 token,没有地址 · 这里给出的是运行时真实值 —— 这才是能直接用来 Hook 的落点

嵌套类型请传完整嵌套名:IL2CPP 的 namespace 只属于最外层类型, 嵌套类型(状态机 State、协程体 d__0、私有内部类)的命名空间是空的、 只有短名。实测 IL2CPP 样本 20,072 个类型里 7,056 个(35%)是嵌套类型, 名为 State 的类型有 131 个而只有 1 个是顶层。所以查嵌套类型时 name 要写成完整嵌套名(如 "TeamTapas.ProjectR.UI2.RUI_FloatingUI.State", 从 search_classes 的 nested_name 直接抄)。只传短名而命中多个时, 本工具返回 ok: false + ambiguous: true + candidates,不会替你猜。

Args: name: 类名(短名;嵌套类型请传完整嵌套名)。 namespace: 命名空间(可选)。不给也能用:会按短名在顶层类型 里解析,唯一才采用;命中多个则返回 ambiguous: true + candidates,让你自己指定。嵌套类型必须用完整嵌套名 (candidates[].full_name)—— 只用短名会被拒绝, 不会随便挑一个(短名会撞上同名的嵌套枚举/状态机)。 image: 程序集名(可选,如 "TeamTapas.ProjectR.dll")。 method_filter: 只看名字含该子串的方法(类方法很多时用)。

Returns: {ok, full_name, fields: [{name, type, offset, is_static}], methods: [{name, token, pointer, rva_hex, in_module, param_count}]}

Input Schema

NameRequiredDescriptionDefault
nameYes
imageNo
fieldsNo
methodsNo
namespaceNo
method_filterNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

Goes well beyond the annotations: it discloses the ambiguity-rejection behavior, the full return shape in a `Returns:` block (which matters since there is no output schema), and the empirical justification (35% of types are nested). Minor gap: it never states the prerequisite that a live session/attached process is required, and the `Returns:` block reads as unconditional while the schema lets callers turn fields/methods off.

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 message is front-loaded, but the full-nested-name rule is stated three separate times (opening line, the '嵌套类型请传完整嵌套名' section, and again under `namespace`), and the 20,072/7,056/131 statistics are more justification than the agent needs. Roughly a third of the text is redundant.

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?

For a 6-param read tool with no output schema and no annotation detail on returns, the `Returns:` block plus the ambiguity contract covers most of what's needed. What's missing is the prerequisite context (does a game need to be open/attached first?) and the two output-suppressing booleans.

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 coverage is 0%, so the description carries the full burden, and it does document `name`, `namespace` (including "不给也能用" fallback semantics), `image`, and `method_filter` in real detail. However the two boolean toggles `fields` and `methods` present in the schema are never mentioned, leaving 2 of 6 parameters undocumented.

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 concrete verb and resource ("查类的运行时实况") and immediately pins the distinctive output: real field offsets and method RVAs. It also contrasts itself with the sibling `class_detail` on exactly the axis that matters (static metadata has no offsets/addresses), so an agent can discriminate without opening a 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?

Explicit routing rules: use this instead of static `class_detail` when you need hook-viable offsets/addresses; use `method_filter` when a class has many methods; use `search_classes`'s `nested_name` for nested types. It also states the failure condition precisely (short name → `ok: false` + `ambiguous: true` + `candidates`) and refuses to guess, so the agent knows the recovery path.

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