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

Beyond the readOnly/idempotent annotations, the description discloses real behavioral traits: it is an approximate graph, referenced_count is the true total independent of limit, referenced_types caps at 100 with a referenced_has_more flag, and ambiguous same-name classes are rejected with disambiguation candidates.

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

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

Front-loaded purpose, then caveats, then usage rationale, then Args — a logical order with little waste. The bold emphasis and backticks add mild formatting noise but not enough to detract materially.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by describing the shape of the result (referenced_count, referenced_types with has_more). Combined with the read-only annotations and two clearly documented params, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage the description must carry parameter meaning, and it does: full_name is the fully qualified class name, and assembly disambiguates same-named classes via substring match with a concrete example ('TeamTapas'). Minor gap that full_name itself needs little elaboration.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb+resource and even defines what 'references' covers (fields/parent class/method return types), so an agent knows exactly what is being computed. The caveat that it is an approximate dependency view, not an exact call graph, further sharpens the purpose.

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

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

It supplies a clear use case — judging whether changing a class will ripple to many places — and notes that cross-assembly name collisions are rejected with candidates following the same rule as class_detail. It does not explicitly compare against class_hierarchy or find_derived_classes, so it falls short of a full when/when-not decision.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true. The description adds genuinely useful behavior: window lookup fails honestly rather than silently falling back to full screen, output goes to disk to stay under the 256 KB response cap, and max_side never alters coordinate semantics. That is real added context beyond the annotations, so it earns above baseline.

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

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

It is front-loaded with the core contract and the ocr routing rule, and the Args/Returns blocks are scannable. It loses a point for redundancy: the 'screenshots are evidence, not an oracle' rule is stated twice, once in the lead and again in a full warning block with a quoted source, which is more philosophical justification than an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the Returns block supplies the response shape ({ok, path, width, height, backend, region, coordinate_space, ...}), and defaults plus failure behavior are covered for every parameter. Nothing an agent needs in order to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 does so for all four parameters: region as 'x,y,w,h' absolute screen coordinates defaulting to the main screen, window as a title substring that takes priority over region, save_path defaulting to a temp dir, and max_side defaulting to 1920 with 0 meaning no scaling. It even clarifies that max_side affects only the saved file, not coordinates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line states a concrete verb and resource in both modes (screen / window), plus the defining output contract: saved to disk with a returned path, not base64. It also draws a sharp boundary against the sibling `ocr`, so an agent can pick between them without reading either schema.

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

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

It explicitly says when NOT to use it ('要判断「现在在哪个界面」请用 `ocr`') and names the concrete scenario where it belongs (capturing evidence when acceptance fails, paired with `ocr`'s save_on_failure). Both the alternative and the selection condition are stated outright.

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

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

Annotations already declare it read-only, idempotent, and non-destructive. Beyond that, the description discloses key behavior: ambiguous class names are rejected with ok:false and candidates, nested-type full names are short and can collide, and derived results are capped at 50 with derived_has_more signaling truncation.

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

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

Purpose and key constraints are front-loaded, and the Args/Returns sections are useful because the schema lacks descriptions and there is no output schema. It is slightly verbose with repeated emphasis (ambiguity handling for assembly and nested types stated in two separate blocks), but the length is largely justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and zero schema description coverage, the description is complete: it documents all four parameters, the return shape including derived_count vs. derived truncation, ambiguity failure behavior, and the boundary between static metadata and runtime tools. An agent has what it needs to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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: full_name examples include nested types, assembly is a substring match for disambiguation, method_name returns all overloads with token/parameter/static info, and include_inherited controls inherited fields and methods.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: view a class's full details — fields with types, methods with tokens, inheritance chain — and narrows scope when method_name is supplied. It also explicitly positions itself against sibling tools (runtime_class_info / find_hook_target for runtime work, find_derived_classes for full derived lists), so an agent can distinguish it without opening schemas.

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

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

Gives explicit when-to-use (locating Hook targets via method tokens) and when-not-to-use (static metadata has no field offsets or method addresses; use post-injection runtime tools for those). It names the alternatives and the conditions that select them, including search_classes for nested_name and find_derived_classes when the derived list is truncated.

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

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

Annotations already cover read-only/idempotent/closed-world safety, and the description still adds real behavioral traits: down is level-by-level with depth and parent meaning level and true direct parent, a single layer exceeding 500 entries sets down_has_more=true, and cross-assembly name collisions are rejected with candidates offered. It also flags the corrected legacy bug so an agent does not misread depth/parent — exactly the kind of context structured fields cannot carry.

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

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

Purpose is front-loaded in the first clause, followed by semantics, then caveats, then Args — a sensible order with no filler. The parenthetical note about the earlier buggy version is useful but sits awkwardly next to the find_derived_classes pointer, slightly muddling the routing message.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter, read-only tool with no output schema, the definition covers purpose, directional semantics, truncation behavior, disambiguation failure mode, and the alternative tool. It does not state what the result looks like beyond down_has_more/parent, nor what happens for a nonexistent full_name, which are the main remaining holes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the load, and the Args section defines all four parameters including the up/down/both values for direction and substring matching for assembly. Gaps remain: the depth default of 6 and any bounds are unstated, and no accepted values are shown for direction beyond the bare list.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource (查看类的继承体系) and immediately scopes it to upward base-class lookup and downward derived-class lookup. It names the sibling it is not (find_derived_classes for grabbing all transitive descendants at once) and ties itself to class_detail's disambiguation rule, so an agent can place it precisely among 40+ siblings.

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

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

It routes the agent explicitly: use find_derived_classes to fetch all transitive descendants in one shot, and use assembly to resolve same-named classes across assemblies. What is missing is a positive statement of the primary use case (e.g. 'use this to understand the local inheritance shape of one class') and any when-not-to-use condition beyond the transitive bulk case.

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

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

Goes well beyond the annotations by disclosing the critical failure contract: any failed step yields `ok=false` plus `error`, the session is deliberately preserved for retry, and a false success would leave the agent with a still-tampered process. This is exactly the kind of intent-vs-result detail annotations cannot express, and it is consistent with destructiveHint=false / idempotentHint=true (teardown restores rather than destroys, and retry is safe).

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

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

The core action is front-loaded in sentence one, but the same guarantee is restated three times ('只有真的恢复原状才 ok=true', '任一步失败会 ok=false + error 并保留会话以便重试', and again in the trailing paragraph). The duplication roughly doubles the length without adding information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a session-teardown tool with no output schema, the description supplies what matters most: the meaning of the `ok`/`error` result and the retry-preserving behavior. The remaining gap is the two boolean teardown flags, which are left unexplained for a 2-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the schema only gives titles and defaults. The description's '关闭索引' loosely maps to `close_index` and '卸载所有 Hook / 断开注入' to `close_runtime`, but it never explains what happens when either flag is false, nor when to override the defaults. Partial compensation only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening states a specific verb and resource ('关闭当前会话') and enumerates exactly what teardown means: unload all hooks, detach injection, close the index. That enumeration implicitly separates it from narrower siblings like `unhook` or `hook_status`, though no sibling is named. An agent can tell what this does 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.

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

'做完了就调用它，把游戏恢复原状' gives a clear trigger condition (work is finished, restore original state). There are no explicit exclusions or named alternatives such as `unhook` for partial teardown, so it stops short of a 5.

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

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

Beyond the annotations (readOnlyHint=false, idempotent=true, destructive=false), it explains the disk-write behavior that justifies the mutation hint, the 200k-char inline threshold, the nested-type degradation plus nested_note and decompiled_type semantics, and the IL2CPP error path. Timings (3.5s vs 11.5s) further disclose the cost profile.

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

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

Well front-loaded with headers and an Args section, and nearly every line earns its place. The Mono-only / IL2CPP point is restated in two places, which is mild redundancy that could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description explains the return shape (inline source, file listing without inline source, nested_note, decompiled_type) and the error behavior, which is everything an agent needs to call it correctly given its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries full burden, and it documents all four parameters: assembly defaults to session-detected with an example path, type_name accepts Namespace.Type and Outer.Inner/Outer+Inner with the fallback rule, output_dir is required for whole-assembly mode, and split_files explains its default and the file-count/time trade-off. This fully compensates for the empty schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (反编译 Mono/.NET 程序集, get real C# source) and immediately names the underlying implementation (薄封装 ilspycmd). It also clearly separates its purpose from the metadata tools (class_detail, search_methods) and runtime hooks, so an agent can pick it 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.

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

Explicitly gives the two usage modes (type_name → inline source; output_dir → whole-assembly, disk only), explains the 'why' (metadata cannot expose method body logic), states the Mono-only / IL2CPP-errors constraint, and points to get_diagnostics' decompiler.available for the optional dependency. It names the alternatives that cannot replace it.

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

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

Annotations already mark it read-only, idempotent and non-destructive, so the description does not need to repeat that. Instead it discloses behavior beyond the annotations: how results come back (evidence + confidence), and that a UE version is frequently unavailable and yields an empty string plus a reason rather than a guess, which prevents an agent from misreading a missing version as failure.

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

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

The description is front-loaded with the primary purpose, then scope, then the caveat about missing version info, then Args. It is short and every block adds value; the empirical note about two samples justifies the no-guessing rule rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does explain the return shape (evidence, confidence, and empty string + reason when the version is absent). Given annotations covering the safety profile and only one optional parameter, what remains is minor; the set of evidence types the agent can expect is only sketched.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the parameter meaning, and it does: exe is the game executable path, and leaving it empty falls back to the current session's main program. That default behavior is not visible in the schema, which only shows default ''.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific task: decide whether one exe is an Unreal Engine game, and return verifiable evidence plus a confidence level. The scope line ('only judges this one program, no whole-machine scan') separates it from scan-style siblings such as find_game_processes, though it does not name a sibling directly.

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

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

The description says it handles a single program rather than a machine-wide scan, which implies when to use it. However, it never names the alternative (find_game_processes / inspect_binary / inspect_game) or states an explicit condition for choosing this tool over them.

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

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

The description discloses the key trait the annotations only hint at: 取走即消费 (drain-and-consume), matching idempotentHint=false, plus that non-matching and over-limit events are preserved in order and never swallowed. This is exactly the behavioral nuance an agent needs before calling a consuming operation, and it is consistent with readOnlyHint=false / destructiveHint=false.

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

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

Front-loaded with the core consume semantics, but the text repeats itself almost verbatim: the whole-queue filtering point appears three times and the '不匹配的事件留在队列里，不会被吞' sentence twice. Roughly a third of the description is redundant restatement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description supplies the return shape ({ok, returned, pending_approx, dropped, events:[...]}) plus the event field layout. Combined with the consumption semantics and the kind-filter pitfall, an agent has everything needed to call and interpret it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the burden — and it does: limit is '本次最多取多少条', kind is '只取某类事件' with example values (hook / notice / log). It additionally explains that kind filters the whole queue rather than the head, which is meaning the schema cannot convey. Defaults (200, "") are left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 取走 (drain) the probe's buffered Hook events, with parenthetical clarification that these are call records. It is clearly distinguishable from read-only log readers, though it never names the sibling probe_log explicitly.

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

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

Gives concrete usage context: '想持续观察就每隔一会儿调用一次，累加统计即可' tells the agent to poll periodically and accumulate stats. It also warns which failure mode (empty list from queue-head-only filtering) leads callers astray. It lacks an explicit 'use X instead when…' comparison against probe_log.

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

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

Annotations already flag destructiveHint=true, openWorldHint=true, readOnlyHint=false and idempotentHint=false, so the safety bar is lower; the description still adds genuine substance by documenting the available globals (mod/api/funcs/hooks, monoFuncs/BE) and the hard constraint that return values must be JSON-serializable. It does not say what happens on a thrown exception or a crashed process, which for an arbitrary-code tool is a notable omission.

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

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

The critical framing ('escape hatch', 'when preset tools are not enough') is front-loaded, then globals, then return contract, then examples — a sensible dependency order. It is on the long side and the monoFuncs explanation is slightly instructional rather than definitional, but every block is usable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description correctly steps in to define the return contract as JSON-serializable values. Combined with the annotations and the examples, an agent has enough to invoke it competently; only failure-mode and side-effect disclosure is thin for a tool that runs arbitrary code in a live process.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single `code` parameter, so the description must carry the load — and it does, defining it as a JS expression or statement block and supplying four concrete examples spanning a plain expression, an address chain, an IIFE and a `typeof` probe. What it lacks is any statement about error/exception surfacing or size limits on the payload.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb + resource (execute arbitrary Frida JS inside the game process) and immediately frames its niche with '应急逃生舱' (escape hatch of last resort) and '与 AiMod 的 eval_script 同定位'. An agent can distinguish it from the 40+ targeted siblings like hook_method or read_memory 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.

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

'当预置工具不够用时，直接下发 JS 探测' gives explicit triggering context, and naming the preset tools collectively as the alternative routes the agent correctly. It falls short of a full 5 because it never says when NOT to use it (e.g. prefer the dedicated tool for a known operation) nor warns about how easily the escape hatch can destabilize the session.

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

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

Annotations already cover readOnly/idempotent/non-destructive/closed-world, and the description adds genuine behavior: base classes outside the index still yield valid results with an explanatory note, plus total vs returned vs has_more truncation semantics. However it repeats that total is unaffected by limit twice, so added value is diluted.

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

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

Front-loading is good, but the total/limit/has_more rule is stated three times across the body, and the Args/Returns blocks restate material already given in prose. Tightening to one statement of the pagination rule would lose nothing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 Returns block enumerates every field including item shape, and edge cases (base outside the index, truncation) are covered. An agent has everything needed to call it and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description fully compensates: base_full_name needs the fully-qualified name with an example, assembly is substring-matched (a detail absent from the schema), and limit caps only returned rows while total stays the full match count.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: find all types deriving from a base class, explicitly including indirect inheritance, with an optional assembly filter. Clear enough to separate from search_classes, but it never names the nearest alternative (class_hierarchy) so the distinction must be inferred.

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

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

Gives two concrete when-to-use recipes with literal call examples, including the primary Mod use case (MonoBehaviour in Assembly-CSharp). It also explains why passing assembly beats guessing from assembly-name prefixes, which is real decision guidance rather than restating the name.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: the full return shape, the case-insensitive substring filter, and the important caveat that `is_64=None` means 'not measured' rather than '32-bit', which prevents a real misinterpretation.

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

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

The purpose sentence is front-loaded, Args and Returns are cleanly separated, and every line adds information. No filler or duplicated schema boilerplate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description supplies the return structure and per-field caveats, and it documents both parameters. What's missing is only a brief note on how the game heuristic behaves or how large the result set might be.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 the load, and it does: it explains `name_filter` as a case-insensitive process-name substring and `only_games` as a heuristic game-process filter defaulting to True. It stops short of defining what 'looks like a game' means, which keeps it from a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('列出正在运行的游戏进程') plus a secondary capability (identify the il2cpp/mono runtime), which is far more than a restatement of the name. It doesn't explicitly contrast itself with siblings like runtime_info or inspect_game, so it's clear but not sibling-differentiating.

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

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

Usage is only implied: the `only_games=True` default hints that discovery comes first and filtering is secondary, and one can infer this is a pre-step to opening/inspecting a process. There is no explicit when-to-use, when-not-to-use, or named alternative.

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

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

The annotations already declare this is a read-only, idempotent, open-world, non-destructive lookup, so the safety profile is covered. The description still adds real context beyond that: it discloses that the class is materialized at runtime (a side effect beyond pure metadata reads) and defines the ambiguity outcome with its payload. It does not discuss cost, failures, or whether materialization affects game state, which keeps it at 4 rather than 5.

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

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

The opening sentence front-loads the core purpose, and the workflow block is genuinely load-bearing for correct invocation. It is longer than strictly necessary — the closing per-field notes on address/rva_hex/token partly repeat the workflow paragraph — but no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must explain return values, and it does: candidates containing address (feedable to hook_address), rva_hex (comparable to static RVA), token (confirms the same overload), plus the ambiguous flag. Combined with the documented params and annotations, 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden, and it does: name accepts a short name but nested types need the full nested name; method overloads are disambiguated via param_count on candidates; namespace is optional, and when omitted resolution is restricted to top-level types and only adopted if unique, otherwise ambiguous. That is meaning well beyond the bare typed properties.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: locate the hookable address (with RVA and token) of a method. It distinguishes itself from the sibling tools it names explicitly (search_classes/class_detail for static lookup, hook_address for consuming the result), so an agent can place it in the pipeline without opening the schemas.

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

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

It gives an explicit three-step workflow: first confirm the target method in static metadata with search_classes/class_detail and capture its token, then call this tool to materialize the class at runtime, then compare the returned token with the static token. It also states the failure behavior when the name is ambiguous (returns ambiguous: true plus candidates), which is exactly the when-not case an agent needs.

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

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.

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.

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.

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.

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.

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.

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

Beyond the annotations it explains the consequence of misuse (unbounded memory growth) and pre-empts the idempotency misreading — why idempotentHint=false must not be read by a client as 'free to retry'. It also discloses the automatic restore in agent.js dispose, which is exactly the kind of context annotations cannot carry.

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

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

Purpose and the critical warning are front-loaded, and the Args block anchors the parameter. The middle section defending the idempotentHint choice is somewhat meta and longer than an invoking agent strictly needs, though it does prevent a real misuse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter stateful mutation with no output schema, everything needed is present: what changes, the risk of leaving it on, restoration obligation, and the fallback cleanup path. Sibling tooling handles the surrounding hook workflow, so nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the single parameter, and it does: 'disable: True pauses GC, False resumes'. It does not flag that the schema default is true, which makes a bare call silently pause GC — a meaningful omission for a stateful toggle, but the core semantics are covered.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first line states a concrete verb and resource: pause/resume the game's garbage collector. It is unmistakably distinct from siblings like hook_method, unhook, and read_memory, and the toggle nature is spelled out immediately.

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

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

It gives explicit when-to-use (pause during hooking so observed objects aren't collected), when-to-restore (always resume after observation ends, otherwise memory grows), and even documents the safety-net behavior on probe unload that should not replace caller-side restoration. Both the positive and negative conditions are covered.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, non-destructive, closed-world), so the description's job is to add context. It does add useful behavior: the process scan is skipped by default, costs about 2.7 seconds when enabled, and an 'unavailable' result means dependent tools will fail for environmental reasons rather than being buggy. It does not describe what the diagnostics output actually contains, which is the main remaining gap.

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

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

Front-loaded with the purpose and default, then rationale, then the parameter. Mostly tight, though the 'default does not scan local processes' point is stated twice (in the opening and again in the Args block), which is mild redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should say what the diagnostics return. It enumerates the checked areas (Python, Frida, engine parsers) but not the shape of the result or how unavailability is signaled, leaving a small inference gap for a tool whose whole output is the answer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 for the single `scan_processes` parameter. It explains the default (False), the concrete cost of enabling it (~2.7s), and why it is redundant with `find_game_processes` — everything an agent needs to decide whether to set it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: checking whether the runtime environment (Python, Frida, engine parsers) is usable. It explicitly distinguishes itself from the sibling `scan_processes`/`find_game_processes`, so an agent can tell which tool answers which question.

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

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

Gives explicit timing guidance ('call once before starting work') and explicit routing: for listing running games, call `find_game_processes` instead, because this tool defaults to not scanning and duplicates that responsibility. Both the when and the when-not are stated.

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

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

The annotations already declare this as read-only, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds useful scope about what state is inspected and positions it as a first diagnostic step, but it does not describe output freshness, cost, or return shape beyond the three content categories. With annotations doing the heavy lifting, this is adequate but not rich.

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

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

The description is two compact sentences, front-loaded with the resource and state categories, followed by the troubleshooting trigger. Every clause adds useful signal, and there is no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only diagnostic tool with no output schema, the description provides enough context to know when and why to call it. It lists the main state categories but does not explain the returned structure in detail; that is a minor gap given the lack of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it correctly focuses on what the no-argument call returns.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and verb: viewing current session state, and it enumerates the three main contents (selected game, index statistics, runtime injection status). It does not explicitly differentiate itself from similar diagnostic siblings such as get_diagnostics or runtime_info, but the scope is clear enough for an agent to understand what it returns.

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

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

It gives a concrete usage context: when troubleshooting 'why can't find a class / hook fails', look here first. This establishes a priority entry point for diagnosis. It does not name explicit alternatives or exclusions, but the intended situation is clear.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the description's job is lighter, yet it still adds real behavior: the hook lands in the probe's hooks table, is visible via hook_status, and is removable with unhook. It also warns that an invalid args_type spec fails immediately and that unsupported override_retval types are rejected on the spot. It does not say whether a live session/process is required before calling, which would have made this a 5.

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

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

Front-loaded with the scope statement and the hook_method contrast, and the args block is easy to scan. However, the applicability clause is repeated almost verbatim in the opening two paragraphs ('适用于原生函数、系统 API、以及「模块基址 + RVA」算出的地址' twice), which is wasted space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter mutation tool with no output schema, the description covers target identification, argument typing, throttling, backtracing, and return-value override behavior, plus lifecycle integration with hook_status/unhook. It stops short of explaining how captured calls are retrieved (the drain_events sibling) and leaves 'label' undocumented, so an agent still has a small inference to make.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 the parameters, and it does: address format (hex example), args_type syntax and failure mode, retval_type enum list, max_calls, backtrace, and the full override_retval semantics with accepted types and the empty-string default meaning. The only gap is the 'label' parameter, which appears in the schema but is never mentioned.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (install hook) and resource (arbitrary address), and explicitly scopes itself as 'not limited to managed methods', which cleanly separates it from the sibling hook_method. An agent can decide between the two without opening either schema.

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

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

Gives concrete when-to-use conditions: native game functions, system APIs, and addresses computed as module base + RVA from static analysis. It also implicitly routes managed-method hooking to hook_method by contrasting scope and by referencing hook_method's argument semantics.

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

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.

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.

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.

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.

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.

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.

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by explaining what the returned trigger counts mean and how to interpret a zero-count case, which is genuine behavioral context. It does not cover whether a session must be open, though.

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

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

Two short sentences: the first states what the tool returns, and the second pre-emptively explains how to interpret the counts. It is tightly front-loaded with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters and no output schema, the description covers the essential: what is listed and how to read the counts. The one gap is that it does not state any prerequisite, such as an active game session or an attached process, which the sibling set (open_game, inject_process) suggests is relevant.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the parameter-semantics baseline is 4. There is nothing parameter-related for the description to clarify, and it correctly does not pad with parameter talk.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a concrete verb and resource: '列出当前所有 Hook 及其触发次数' (list all current Hooks and their trigger counts). This clearly distinguishes the tool from the action-oriented siblings hook_method, hook_address, and unhook. It does not explicitly name a sibling, but the resource is specific enough to make the distinction obvious.

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

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

The description gives a concrete diagnostic scenario: use the trigger counts to judge whether a Hook was installed correctly, and a zero count on a per-frame method indicates a wrong target. This is clear usage context, though it does not mention what to do instead or which alternative tool to use when the diagnosis fails (for example, find_hook_target or drain_events).

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

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

Adds substantial context beyond annotations: permission requirement (no admin needed, measured 2026-10), the integrity-level condition that actually causes failure (High vs Medium), anti-debug protection as a distinct failure mode, and forced session-context switching with context_switched/context_warning signaling. The idempotency claim matches idempotentHint=true and destructiveHint=false is consistent with a non-destructive attach.

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

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

Front-loaded and generally well-organized, but the session-context switch is explained three times (first sentence, the dedicated paragraph, and again in the Returns section), and the '为什么必须切' rationale plus the token-reconciliation metaphor consume space without adding actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-required-param, no-output-schema tool, the description covers inputs, the return shape (ok, pid, init with module/base/api_available/api_missing/fallbacks, plus context_switched/context_warning), failure modes, and permission setup. An agent has everything needed to call it and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden and does: pid (blank → auto-locate main program), auto_find (whether to auto-search without pid), preferred_module (IL2CPP module name, auto-detected as GameAssembly.dll / libil2cpp.so). Each parameter gets meaning the bare schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: injecting a runtime probe into a running game process. It also states the consequence (enables runtime_*/hook_*/drain_events) and the scope (one injection per process), which clearly separates it from siblings like hook_method or find_game_processes.

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

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

Explicitly states the prerequisite relationship — the online tools runtime_*/hook_*/drain_events only work after injection — and that repeat calls reuse the existing session rather than re-hooking. It does not route the agent on how to obtain a pid (find_game_processes is a sibling), only that blank pid triggers auto-find.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral detail: key conclusions are duplicated at the top level and inside `pe`, and the full section/import data stays in `pe`. That is real information about the response shape that the annotation set does not carry, though it does not discuss cost, rate limits, or handling of non-PE files.

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

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

Three short paragraphs plus an Args block, front-loaded with the core purpose followed by use cases. The bolded emphasis on the duplicated fields is slightly redundant but earns its place by warning against unnecessary drilling.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does enough: it names the returned top-level keys, explains the `pe` sub-object's contents and its relationship to the top level. Minor gaps remain, such as failure behavior on non-PE or missing files, but nothing blocks a correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the single `path` parameter has no schema description, so the description must compensate. It partially does by specifying that path accepts an executable or DLL file path, narrowing the expected input beyond a bare string.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (analyze PE files, exe/dll) and enumerates the extracted artifacts: architecture, sections, exports, imports, runtime type. This clearly separates it from siblings like decompile, inspect_game and find_hook_target, which operate at different levels.

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

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

Gives three concrete use cases: detecting packing, detecting whether the binary is managed (.NET), and locating exportable functions to hook. There is no explicit exclusion or pointer to an alternative (e.g., when to prefer find_hook_target instead of reading the export table), so it stops short of full routing guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety bar is low, yet the description still contributes a return-shape sketch ({ok, engine, main_exe, il2cpp/mono/ue key paths}) plus the scope constraint that it inspects one directory rather than the machine. It omits cost/performance expectations and what happens on an unrecognized or invalid directory.

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

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

Front-loaded with the core purpose, then a short usage note, then structured Args/Returns. The middle sentence about not scanning the whole machine is slightly rambling but earns its place as a scoping rule; nothing else is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only probe with strong annotations, the description covers purpose, scope, and an inline summary of return keys, which substitutes adequately for the absent output schema. A brief note on failure modes (non-game directory, missing exe) would close the remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter has 0% schema description coverage (only the bare title 'Game Dir'), so the description must carry the semantics. It does clarify game_dir as the 游戏安装目录 (game installation directory) rather than any arbitrary folder or process name, but that is the minimum needed and no format, path style, or read-permission constraints are given.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (探测一个游戏目录) and enumerates the concrete outputs: engine identification, main executable, and key files. That makes it clearly distinguishable from neighbors like inspect_binary, detect_ue, and ue_profile, which operate on binaries or specific engine families rather than a whole install directory.

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

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

Explicitly frames the usage as 'one game project directory at a time' and tells the agent not to enumerate all games on the machine, with the action being 'just pass the directory in'. It gives an operative condition but never names an alternative tool (e.g. detect_ue or inspect_binary) for deeper or engine-specific follow-up.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, and the description adds real context beyond them: a refusal path for already-running processes, automatic session-context switching with an index rebuild, the context_switched return field, and a context_warning instead of guessing when the exe's game can't be inferred. It even explains the failure mode it prevents (index/runtime image mismatch with ok:true). It does not cover what happens to the previously active session or timing/return payload shape, keeping it below 5.

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

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

Front-loaded with the core action and the key refusal rule, but the session-context-switching behavior is explained twice in near-identical paragraphs, and the parenthetical about 140 vs 143 images is over-detailed. The Args block is efficient, but the body could be roughly halved without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a launching/mutating tool with no output schema, the description covers prerequisites (session identity follows exe), failure modes (already-running process, uninferable game), and names the return fields the agent should inspect. The only real hole is the undocumented `preferred_module` parameter and what a successful launch returns beyond context_switched.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the burden and largely succeeds: `exe` documents the empty-string default (use the session's identified main program) and `args` documents Windows-style splitting, quote handling for spaced paths, and that backslashes are not escapes. The third parameter, `preferred_module`, is never mentioned anywhere, leaving one of three parameters completely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (launch game + inject probe before initialization) and immediately differentiates from the sibling inject_process by explaining why launching first is stronger. The scope is unambiguous and an agent can pick it over inject_process 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.

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

Explicitly names when to use it (intercepting one-shot initialization logic before objects exist), the alternative it beats (manually starting the game then inject_process), and a hard refusal condition (same-name process already running, which wastes 60s). That is when/when-not/alternative all in one place.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds behavior the annotations don't: offset/limit paging and the fact that has_more is returned truthfully when a page is truncated. Missing only ordering/return-shape details, which is minor here.

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

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

The purpose and the paging rule are front-loaded, followed by a compact Args block. Every line carries information, with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter read-only listing tool with no output schema, the description covers what is listed (dlls plus type counts), how to page (offset/limit/has_more), and why to call it. Nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 the parameter meaning, and it does: pattern is a name substring filter (with an example), offset is the start index, limit is the page size. Defaults aren't restated, but the semantics are fully clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource: list the game's assemblies (dlls) with their type counts, plus pagination. This clearly differentiates it from siblings like search_classes or class_detail. The only friction is that the tool name 'list_images' suggests images rather than assemblies, so the description has to do remedial work.

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

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

It gives a concrete decision rule: use it to determine which dll holds the game logic and thereby shrink the search space. It doesn't name an explicit alternative when this tool is the wrong choice, but the intended scenario is unambiguous.

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

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

Adds real behavior beyond the annotations: cost profile (4.1s full-screen 2560x1440 vs tens of ms for ROI), the critical semantic that matched_count==0 means 'not found this run' rather than 'does not exist', that best_match is highest-confidence rather than first, and that coordinate_space is guaranteed screen_absolute. It also explains the file write implied by readOnlyHint=false via save_on_failure, so description and annotations are consistent.

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

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

Front-loaded with the key claim, but the ROI-vs-full-screen point is repeated three times and the 4.1s vs tens-of-ms benchmark is stated twice verbatim, plus the matched_count==0 caveat appears both in prose and again in the 'matching semantics' block. 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully specifies the return shape (ok/engine/count/results/texts/matched/matched_count/best_match/click_point/coordinate_space/image) and the field semantics that matter. For an 8-parameter, open-world, side-effecting tool, nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% with no enums and no defaults documented in prose, so the description carries full burden — and it does: it gives the 'x,y,w,h' screen-absolute format for region, the window-title-substring alternative, the three match modes (contains/exact/regex, which the schema does not enumerate as an enum), the threshold 0.3 default, and the failure-screenshot semantics of save_on_failure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (OCR recognition of screen text) plus the differentiating output guarantee (screen-absolute coordinates directly usable for clicking). An agent can immediately distinguish this from siblings like capture_screen, wait_for, or verify_state.

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

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

Explicitly frames the tool as the 'weak vision' workhorse and gives the decision rule — most acceptance checks only need 'are these characters on screen and where'. It also names the region-vs-window choice and the save_on_failure option. It stops short of naming sibling tools or stating when NOT to use it (e.g. when pixel-level visual comparison is needed).

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

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

Goes well beyond the annotations by disclosing that switching games resets the session and safely unloads an already-injected runtime — a real side effect an agent must know about. It also explains caching behavior and the reused=true fast path, matching the idempotentHint while adding actionable detail on when a rebuild does or does not occur.

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

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

Front-loaded with the core action and session-role statement, then organized into engine bullets, repeat-call note, Args, and Returns. It is somewhat long and the Returns block lists a raw dict shape, but each section carries distinct information without filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description supplies the return shape (ok, engine, metadata_path, index counts, elapsed, reused). Combined with engine support notes and the pointer to get_diagnostics for UE capabilities, an agent has everything needed to call this correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description fully compensates: game_dir as the recommended entry, metadata_path for nonstandard layouts with per-engine file names, engine for forced override ('generally not needed'), cache_dir's default of ~/.gamemod/cache, and force_rebuild's trigger condition. Every one of the five parameters gains meaning not present in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource: selects a game and builds (or reuses) its metadata index, with cross-engine auto-detection spelled out for IL2CPP/Mono/UE. It also states the tool's role as session-context setter for all downstream query tools, which cleanly separates it from siblings like find_game_processes or inspect_game.

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

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

Explicitly says all query tools afterwards use this game as context and that switching games resets the session, and it documents the cheap repeat-call path (reused=true, ~10ms). It does not name a competing sibling (e.g., inspect_game vs find_game_processes) or state when not to call it, so it stops short of full routing guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes further: it discloses that only the tail is read and never the whole (possibly hundreds of MB) file, how encoding detection falls back utf-8 → utf-8-sig → gbk, and that reads do not consume the log. These are real behavioral traits beyond the annotation set.

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

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

The operational content is front-loaded and correct, but a large block of the text is research justification ('of 7 surveyed bot projects, none used logs…') that does not help an agent decide or invoke. That padding dilutes an otherwise tight definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description supplies the full return shape including encoding, total_lines_in_tail, matched_count, has_more and truncated_head, plus defaults for every parameter. An agent has everything needed to call and interpret results, even though structured fields are sparse.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 all parameter meaning — and it does: path, pattern (regex, empty = all tail lines), max_lines (default 200, returns the *last* N), tail_bytes (default 262144 bytes). The 'last N lines' and 'tail bytes' semantics are precisely the non-obvious parts the schema omits.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource and scope: reads the *tail* of a game log and filters by regex, with automatic encoding detection. It also explicitly distinguishes itself from the sibling `drain_events` (non-consuming vs. consuming), so an agent can pick between them without opening either schema.

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

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

Explicitly gives the use case — repeated polling until a log line appears — and names the alternative (`drain_events`) plus the condition that separates them (consume-once vs. re-readable). It also states the negative-assertion use case (`matched_count` for 'no ERROR appeared'), which is a concrete when-to-use signal.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely useful behavior - hex-formatted output and a 16 MB size ceiling - but says nothing about failure modes, such as an unreadable or invalid address, or whether an open session/process is required.

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

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

Front-loaded one-line purpose, then a compact purpose list, then an Args block. Every sentence adds information; there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read tool with no output schema this covers the essentials (format, limit, use cases). It is missing the preconditions that matter for a process-memory reader - whether a session or opened process is required - and any hint about error behavior on partial reads.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 the parameter meaning and it largely does: address is a hex string with a concrete example ("0x1a2b3c4d"), and size is a byte count capped at 16 MB. Only the default value (16) is left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (read game process memory) plus the return encoding (hex). This is enough to separate it from write_memory and eval_script, though it never explicitly contrasts itself with the closest sibling, read_field_value.

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

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

Lists three concrete use cases (verifying field offsets, reading raw object bytes, observing memory changes), which gives a clear context for invocation. It stops short of exclusions or naming an alternative (e.g. use read_field_value when the type is known), so it falls one notch below full marks.

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

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

Beyond the annotations (`readOnlyHint`, `idempotentHint`, `destructiveHint: false`), the description discloses that pure pagination is lazy and fast while `pattern` forces full result-set parsing, and that handles are session-scoped and return `available_handles` on expiry rather than silently switching results. These are meaningful operational behaviors not captured in the annotations.

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

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

The description is front-loaded with the core operation and uses clear chunks for usage modes, cost, and handle validity. It is somewhat repetitive: the merged `search_query_result` history is explained twice, which slightly dilutes conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read tool with no output schema and no structured parameter descriptions, the description is largely complete: it covers operation, usage modes, cost, handle validity, and expiry behavior. The remaining gap is that it does not explicitly describe the returned page shape or pagination metadata.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden and does so: `handle` comes from `search_classes`-type tools, `offset` is the start position, `limit` is page size with an upper bound of 2000, and `pattern` is a case-insensitive substring filter where empty means no filtering. It also explains the two handle sources (`search_*` indexes and `cap-` truncated-result handles).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource: paginated reading of a prior query's complete result by handle, plus optional in-result filtering. It distinguishes the two modes and references the removed sibling `search_query_result` as a special case, so the agent can tell what this tool is for.

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

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

The description explicitly separates two usage modes: pure pagination with `offset`/`limit`, versus filtering with an added `pattern`. It also explains the cost difference and advises narrowing with `search_*` parameters before using `pattern`, which is exactly the routing guidance an agent needs.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description adds real value beyond them: what the response contains and how to interpret image_count_matches as evidence of a mismatched game instance.

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

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

Two short, front-loaded sentences: the first names what is inspected, the second explains the self-check. Bold markers are used for emphasis without padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-shape burden and does cover the principal fields plus the diagnostic interpretation. It omits any note on what a healthy versus unhealthy 'available APIs' listing looks like, but an agent can still call it confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4; there is nothing further the description could add on parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: view the probe status of the injected game, enumerating IL2CPP modules, image count and available APIs. That distinguishes it from generic siblings like get_diagnostics or list_images, though it never names those siblings explicitly.

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

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

The consistency-check paragraph implies this is called to confirm the probe is attached to the right game instance and to troubleshoot otherwise, but there is no explicit statement of when to prefer this over list_images, get_diagnostics or runtime_class_info.

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

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

Annotations already cover readOnly/idempotent/non-destructive/openWorld, and the description adds that the default scope is the current IL2CPP module and that this is the discouraged path — implying it is more costly than symbol lookup. It does not explicitly state the cost or that scanning a large module can be slow, but nothing contradicts the annotations.

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

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

Front-loaded with purpose and the fallback warning, then a clean Args block. The warning is, however, stated twice almost verbatim (bold line plus the ⚠️ paragraph), which is redundant text that could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter tool with no output schema, the definition never says what a hit looks like — module + RVA, absolute address, or count — nor whether offsets are relative to the module base, which matters since the whole point is to feed a hook target. Adequate but leaves the return shape to guesswork.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the load and it does: it gives the pattern syntax (hex with "??" wildcards) plus a concrete example "48 8B ?? ?? E8", states module defaults to the current IL2CPP module, and explains max_results as a cap on hits returned.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb+resource: perform an AOB (signature) scan inside a game module. It also positions the tool against the sibling approach (metadata + RVA via find_hook_target), so an agent can tell immediately what this does and what it is not for.

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

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

Explicitly names itself as the fallback (兜底手段) and says to prefer metadata + RVA localization first, then gives the precise conditions where scanning is warranted: symbols stripped, or target is native code. Both when-to-use and when-not-to-use are stated.

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

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds real value on top: results carry a `handle`, large result sets must be paged, ambiguous short names are rejected outright, and the 2000-item page cap. It omits the prerequisite that a game session must be open (open_game/get_session are siblings), which is the main behavioral gap.

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

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

Purpose and filters are front-loaded, then the Args/Returns blocks. The nested_name vs full_name section is the longest part but earns its space by citing a concrete failure mode (131 types named `State`, only 1 top-level). The 20,072 figure is illustrative padding that could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-param search tool with no output schema, the inline Returns block compensates well (ok/handle/total/returned/has_more/items with field names). What's missing is the session prerequisite and any explanation of `offset` / `exclude_compiler_generated`, leaving two knobs an agent must guess at.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the burden, and it documents pattern, subtype_of, assembly, only_enums, and limit (including the 2000 ceiling that the schema does not state). Two of seven params are undocumented: `offset` and especially `exclude_compiler_generated`, whose non-obvious default of true interacts directly with the coroutine-body caveat the description raises.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource set ("搜索游戏里的类、结构体、枚举") and positions itself as the primary entry point for mod development. The resource boundary versus search_fields, search_methods, and class_detail is obvious from the naming, and the read_query_result follow-up makes the tool's role in a two-step flow explicit.

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

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

Gives a clear when-to-use-which rule for the downstream step: use the returned `handle` with read_query_result for paging and re-filter inside results with its `pattern` param. It also gives a concrete anti-pattern warning (don't query by full_name). It never says when to prefer class_detail or search_fields over this tool, so an exclusion is missing.

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

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

Annotations already cover read-only/idempotent, and the description adds substantial extra behavior: `total` is the true match count unaffected by limit, paging is via offset/limit not the handle, oversized results carry handle_truncated/handle_note, and ambiguous owner matches fail with a candidate list instead of silently merging unrelated classes.

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

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

The first line front-loads purpose and the Args/Returns blocks are scannable, but the owner disambiguation is explained twice (once in the preamble, again in Args), and the 'why we don't guess' rationale, while useful, adds length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter read tool with no output schema, the description supplies the return shape ({ok, handle, total, offset, limit, returned, has_more, items}), paging semantics, and the truncation edge case, leaving nothing an agent needs missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description does all the work: it defines `pattern` as a case-insensitive name substring, `offset`/`limit` as paging (limit caps at 2000), `owner` as full or unique-short class name, and `assembly` as a disambiguator only relevant when owner matches multiple classes.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (search fields by name) and what is returned (owning class and field type). Explicitly positions itself as the preferred entry point when locating a field such as '金币' or '血量', which distinguishes it from the sibling class/method search tools.

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

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

Gives explicit when-to-use ('按字段名搜' first-choice entry), explains that `owner` scopes to a single class, and states that ambiguous short names are rejected with candidates, requiring `assembly=` or a fully qualified name to disambiguate. It even justifies the refusal policy rather than leaving the agent to discover it.

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

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

Beyond the annotations (readOnly/idempotent/non-destructive), the description adds real behavioral detail: a short owner name must be unique or the call is rejected with candidates, assembly is only for disambiguation, and limit is capped at 2000. It does not mention cost or auth, but the added rejection/uniqueness semantics are substantive.

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

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

Front-loads the purpose and return shape, then a compact Args list, then the return envelope. Slightly redundant — the owner semantics are stated twice (once in the intro, once in Args) — but otherwise efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by spelling out the return envelope ({ok, handle, total, offset, limit, returned, has_more, items}) and clarifying that total is the true match count. Combined with full param coverage, it is nearly complete; only the numeric defaults are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 the load, and it does: it defines pattern (case-insensitive substring), offset (skip count for paging), limit (page size, max 2000), owner (scoped, unique-short-name rule), and assembly. It omits the default values (limit=100, offset=0) present in the schema, a minor gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("按名字搜索方法") and immediately lists what is returned (owning class, return type, token), so an agent knows exactly what the tool yields. It implicitly distinguishes itself from search_classes/search_fields via the method-name focus and the owner cross-reference, though it never names those siblings explicitly as alternatives.

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

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

It gives useful in-context guidance — offset pairs with total/has_more for paging, and assembly exists only for owner disambiguation — but it never says when to choose this over search_fields, search_classes, or find_hook_target. Usage is implied rather than stated against alternatives.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile needs no restating. The description does add that results carry `returned`/`has_more` and that an empty page explains which kind of 'empty' occurred, but that last point is vague and nothing is said about limits, scale, or cost on large archives.

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

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

Purpose, return fields, and the motivating scenario are front-loaded before the Args block, so the agent gets the essentials first. The '这是 UE 游戏上最实用的一步' line is partly promotional but doubles as usage framing, so it mostly earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and zero schema-level parameter descriptions, the description covers the needed ground: what is listed, how to filter/page, and the shape of the paging response. A reader can call it correctly without opening the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the Args block is doing the real work: all five parameters are explained, including kind's auto/pak/utoc values (absent from the schema), pattern's case-insensitivity, and offset's paging role. Minor gaps remain — no max value for limit, and it references a `total` field not otherwise described.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: list which assets are packed inside a .pak/.utoc container, with filtering and paging. An agent can immediately tell this is an archive-listing tool. It does not, however, distinguish itself from nearby siblings such as ue_manifest or ue_profile, which plausibly overlap.

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

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

Gives an explicit use case ('想知道这游戏有哪些资源、本地化文本在哪个文件里, 就靠它'), which tells the agent the triggering question well. It stops short of exclusions — there is no statement of when to prefer ue_manifest or another sibling instead.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description only needs to add context and it does: auto-discovery of the manifest when `path` is empty, pagination via offset/limit, and the truncation signal `has_more`. It says nothing about behavior when no manifest is found, which is the main remaining gap.

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

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

The purpose and its validation use case are front-loaded, followed by a compact Args block where each line adds information. It is slightly longer than needed because the preamble and the Args section partly restate the same concepts.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, five-parameter tool with no output schema, the description covers discovery, filtering, and pagination well enough to call it correctly. What it omits is the shape of the result (e.g. whether it returns paths plus counts) and failure behavior, which an agent would want given there is no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 all five parameters – and it does, explaining that an empty `path` triggers auto-discovery, that `game_dir` is only used in that case, that `pattern` is a path-substring filter, and that offset/limit are paging controls. This fully compensates for the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource (read the UE packaging manifest `Manifest_*Files*.txt`) and explains its role as the ground truth of which files should exist. It never names a sibling, but the pak/utoc validation framing implicitly separates it from the other `ue_*` tools.

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

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

It gives a clear use case – verifying file lists parsed out of pak/utoc – which tells the agent when to reach for this tool. There is no explicit when-not guidance or named alternative (e.g. `ue_list_entries`), so it stops short of full routing guidance.

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