Skip to main content
Glama

decompile

Idempotent

Extract real C# source code from Mono/.NET assemblies to analyze method bodies, either for a single type or an entire assembly.

Instructions

反编译 Mono/.NET 程序集,拿到真正的 C# 源码(薄封装 ilspycmd)。

给 type_name 反编译单个类型(小结果内联在 source);给 output_dir 反编译整个程序集(只落盘 + 返回文件清单,不内联源码)。 嵌套类型会退让到最外层并写 nested_note,decompiled_type 如实报 实际产出的类型名。只支持 Mono,IL2CPP 会明确报错。 依赖是可选的,见 get_diagnostics 的 decompiler.available。

为什么需要它:静态元数据只能给出「有哪些类/字段/方法、签名如何」, 但给不出方法体逻辑。想知道「这个方法到底怎么算伤害的」, 就要反编译看源码 —— 这是元数据索引与运行时 Hook 都替代不了的一环。

只支持 Mono/.NET。IL2CPP 的 GameAssembly.dll 里没有托管元数据, 传进来会明确报错(IL2CPP 的 C# 反编译需要先造 DummyDll,本项目暂未实现)。

两种粒度,用参数区分(故意只做一个工具,避免让你猜该用哪个):

· 反编译**一个类型**:给 type_name(可选 output_dir)
  源码小于 20 万字符时直接内联在 `source` 里返回。
· 反编译**整个程序集**:只给 output_dir
  产物可能上万文件,因此只落盘 + 返回文件清单统计,**不内联源码**。

Args: assembly: 程序集路径(.dll / .exe)。Mono 游戏通常是 <游戏目录>/<游戏名>_Data/Managed/Assembly-CSharp.dll。 留空则用当前会话识别出的那个(Mono 游戏可直接用)。 type_name: 类型名,支持 Namespace.Type。传空表示反编译整个程序集。 嵌套类型可传 Outer.Inner 或 Outer+Inner: 由于 ilspycmd 无法单独定位嵌套类型(产物始终是最外层那一份), 会自动退让到最外层类型,并在 nested_note 里说明。 decompiled_type 报的是实际产出的类型名(即最外层), 不是请求名 —— 这样调用方不会把外层源码误当成内层源码。 declared_types 已核对,内层类型的声明确实在这份产物里。 output_dir: 输出目录。给了就落盘(整程序集模式必填)。 split_files: 整程序集模式下是否一个类型一个文件(默认 True)。 True 出 800+ 个小文件(实测 3.5 秒),便于按需读取; False 出单个大文件(实测 11.5 秒),便于整体搜索。

Input Schema

NameRequiredDescriptionDefault
assemblyNo
type_nameNo
output_dirNo
split_filesNo

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?

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.