Skip to main content
Glama

class_detail

Read-onlyIdempotent

Retrieve complete class metadata—fields with types, methods with tokens, and inheritance chains—to locate hook targets; optionally filter by method_name to inspect overloads.

Instructions

查看一个类的完整信息:字段(含类型)、方法(含 token)、继承链;给 method_name 可只看某方法的重载。

这是定位 Hook 落点的核心工具:方法的 token 由这里给出, 再配合 runtime_class_info / find_hook_target 就能拿到真实的运行时地址。

重要:静态元数据里没有字段偏移、也没有方法地址(只有 token)。 字段偏移与方法真实地址必须靠注入后的运行时工具取。

同类名跨程序集时会拒绝并列出候选(ok:false + candidates), 请改用完整名或补 assembly= —— 因为返回的是「这个类的全部字段表」, 选错类不是少几条数据,而是整份结果都是别的类的。

查嵌套类型时,full_name 传 search_classes 给的 nested_name (如 Outer.Inner):嵌套类型的 full_name 只是短名,多个类会撞名, 本工具会因歧义而拒绝(这不是故障,是防止你拿到另一个类的字段表)。

Args: full_name: 类的完整名(如 "PresetLoaderV2"、 "TeamTapas.ProjectR.UserDatas.Service.UserData_Service", 或嵌套类型的 "Outer.Inner")。 include_inherited: 是否包含继承来的字段/方法。 method_name: 只关心某个方法时填这里。填了就只返回该方法的 全部重载(含 token / 参数表 / 是否静态), 等价于旧的 get_method_source,省一轮往返。 assembly: 同名类消歧用(子串匹配,如 "TeamTapas")。留空则 名字必须唯一,否则报错并给出候选。

Returns: {ok, full_name, nested_name, namespace, image, token, ..., fields, methods, parent, base_chain, derived_count, derived, derived_returned, derived_has_more} derived_count 是派生类总数(真值);derived 只是前 50 个名字, 被截断时 derived_has_more 为 True —— 需要完整列表请用 find_derived_classes。

Input Schema

NameRequiredDescriptionDefault
assemblyNo
full_nameYes
method_nameNo
include_inheritedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare 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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does: 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.

Purpose5/5

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.

Usage Guidelines5/5

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.