Skip to main content
Glama

hook_method

Installs a hook on a target method to capture calls, arguments, call source, and return values; use the token to select an overload and avoid ambiguous targets.

Instructions

在目标方法上安装 Hook,捕获它的调用(参数、调用来源、返回值)。用 token 指定重载;多候选未指定则拒绝。

风险:Hook 会改变游戏运行行为,且错误的参数类型可能崩溃游戏。 建议先用 find_hook_target 确认落点与 token。

重载:同名方法可能有多个重载,token 各不相同。若目标方法有多个 重载而你又没给 token / param_count,本工具会拒绝猜测并返回 候选清单(ok: false)。这是故意的:盲挂到错误的重载上, Hook 照样会成功,错误要到很久以后才以「数据不对」的形式暴露。 最可靠的做法是从静态元数据取目标重载的 token 传进来。

Args: name: 类名。 method: 方法名。 namespace: 命名空间。 image: 程序集名。 args_type: 参数类型列表,逗号分隔,用于解析参数值。 可选:int/uint/long/ulong/bool/float/double/ptr/string/cstring 例:"ptr,int,float"。留空则不解析参数值。 写错规格名会直接报错(不再静默按指针读)。 实例方法的第一个整型位置是 this:想拿对象指针就写 "ptr"(0 参数方法也一样,第 1 个 ptr 即 this)。 label: 自定义标签,便于在事件里识别(默认 "类名.方法名")。 max_calls: 最多记录多少次调用(防止高频方法刷爆事件队列)。 backtrace: 是否记录调用栈(较慢,排障时用)。 token: 目标重载的 token(如 "0x06000A3D")。选重载首选这个, 静态元数据的 class_detail / get_method_source 里就有。 param_count: 目标重载的参数个数(-1 表示不指定)。仅在拿不到 token 且各重载参数个数不同时可用。 retval_type: 返回值读取类型(int/uint/long/ulong/bool/float/double/ ptr/string/cstring)。留空 = 按静态返回类型自动推断, 这是推荐用法:float/double 的返回值在 XMM0 而不在 RAX, 按 ptr 读会给出毫无意义的整数。 override_retval: 受控改写返回值(默认空串 = 只观察不改,与原行为 100% 兼容)。支持 int/uint/long/ulong/bool/ptr/float/double; 其余类型会被当场拒绝(不假成功)。 比 eval_script 手写 Interceptor 强在三点:它进探针的 hooks 表,所以 hook_status 看得见、unhook 卸得掉、 write_memory 的重叠护栏也保护得到。 浮点返回值同样可覆写(实测走「整体换 XMM0 的 ArrayBuffer」, 见 agent.js 的 encodeRetvalOverride)。请配合 hook_status 的 override_retval 字段核对,并用 drain_events 里的 original_retval 对比改前/改后。

Returns: {ok, hook_id, class, method, chosen: {pointer, rva_hex, token}, retval_type, return_type, candidate_count, usable_count} 失败时 {ok: false, error, candidates: [...]}。

Input Schema

NameRequiredDescriptionDefault
nameYes
imageNo
labelNo
tokenNo
methodYes
args_typeNo
backtraceNo
max_callsNo
namespaceNo
param_countNo
retval_typeNo
override_retvalNo

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 only declare readOnlyHint=false/openWorldHint=true; the description supplies the real risk profile (it alters game runtime behavior, and bad arg types can crash the game) and explains the deliberate refusal-to-guess on ambiguous overloads, including why a wrong hook would silently succeed. It further discloses that override_retval registers in the probe's `hooks` table so hook_status sees it, unhook removes it, and write_memory overlap guards apply.

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 correctly: purpose first, then risk, then overload policy, then args, then returns. It is long, and a few details (internal reference to agent.js's encodeRetvalOverride) do not help an agent decide how to call it, but nearly every sentence addresses a genuine failure mode for a 12-parameter tool.

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 spells out the success payload (ok, hook_id, chosen token/pointer/rva, retval_type, candidate_count) and the failure payload including the candidates list. Combined with the crash risk and overload refusal semantics, an agent has everything needed to invoke it correctly.

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% and the schema is bare titles, so the description carries the full burden — and does: all 12 parameters are explained, including the allowed type specifiers for args_type/retval_type, the `this`-pointer convention for instance methods, and the default auto-inference for retval_type with the XMM0-vs-RAX rationale.

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?

Opens with a specific verb and resource: install a Hook on a target method and capture its calls (args, call site, return value). It also distinguishes itself from related tools by naming find_hook_target as the prerequisite step and by explaining why this is preferable to a hand-written Interceptor in eval_script.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit workflow guidance ('建议先用 find_hook_target 确认落点与 token') and precise selection rules between `token` and `param_count`, plus an explicit escalation path when neither is supplied. It lacks only a clear 'when not to use this, use hook_address instead' exclusion for raw-address targets, leaving that boundary implicit.

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