How do I use re-dotnet?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@re-dotnet list types in sample.dll" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

re-dotnet

by Heretek-RE

Overview Schema Related Servers Score Discussions

Python

Local

re-dotnet

MCP server for .NET assembly analysis. Vendor-neutral wrapper around AsmResolver (PE + .NET metadata) and ICSharpCode.Decompiler / ILSpy (C# decompiler).

Why

The other RE-AI MCP servers (re-lief, re-rizin, re-capa) handle native PE, ELF, MachO, DEX, ART, OAT — but none of them read the .NET CLI header or the ECMA-335 metadata tables. A MonoLauncher-style launcher that ships its payload as a managed .NET assembly is invisible to those tools; the import hash is empty, the strings table is uninformative, and rizin only sees native wrapper code.

re-dotnet fills that gap. It enumerates TypeDef / MethodDef / FieldDef, walks the #US string heap, and decompiles a single class or method to C# on demand.

Related MCP server: dnSpy-MCP

Architecture

The MCP server itself is pure Python. The heavy lifting is done by a small .NET 10 CLI binary, re-dotnet-cli, built from src/re_dotnet/dotnet/Re.Dotnet.Cli/:

Claude Code (MCP stdio)
  │
  ▼
re-dotnet server (Python, this directory)
  │  subprocess.run(...)
  ▼
re-dotnet-cli (self-contained .NET 10 binary, single-file publish)
  │
  ├─ AsmResolver 6.x        (PE + .NET metadata, obfuscation-robust)
  └─ ICSharpCode.Decompiler 9.x  (C# decompiler)

The subprocess boundary is intentional:

No pythonnet. pythonnet is a fragile ABI bridge that breaks on every Python minor. Process isolation is robust.
No Mono. .NET 10 is the only supported runtime.
Single-file publish. The CLI is a self-contained binary; no dotnet --info dance, no DOTNET_ROOT env vars, no GAC.

The Python wrapper locates the binary via this fallback chain (see runner.py):

$RE_DOTNET_CLI_PATH (escape hatch for tests)
<server>/bin/re-dotnet-cli (install.sh default)
The dev build under src/re_dotnet/dotnet/.../bin/
re-dotnet-cli on $PATH

Tools

Tool	What it does
`check_dotnet`	Health check — return .NET runtime + AsmResolver + Decompiler versions
`parse_assembly`	Enumerate TypeDef rows; return assembly header + one row per type
`decompile_type`	Decompile a single class to C# via ILSpy
`decompile_method`	Decompile a single method to C# via ILSpy
`list_strings`	Walk field-default constant strings (the #US heap subset)
`get_entry_point`	Return the managed entry point (`<Module>::.cctor` or `Main`)

Install

./install.sh builds the .NET CLI via dotnet publish and copies the resulting binary to servers/re-dotnet/bin/.

To build standalone:

cd servers/re-dotnet/src/re_dotnet/dotnet/Re.Dotnet.Cli
dotnet publish -c Release -o ../../../../bin

To run:

re-dotnet                          # stdio transport (default for MCP)
python -m re_dotnet                # equivalent

Requirements

.NET 10 SDK or runtime (dotnet --version ≥ 10.0)
2 GB disk for the .NET SDK + the self-contained binary

Deobfuscation notes

The ILSpy decompiler produces clean C# for non-obfuscated assemblies. For binaries that have been through commercial obfuscation (control-flow flattening, string encryption, JIT-hooking), the decompiler will surface Unable to decompile ... errors. The remediation path is to run the .NET deobfuscator first (the OSS de4dot shells out, GPL-3.0 — the RE-AI plugin keeps it process-isolated so the plugin's own distribution stays clean) and then re-run decompile_type / decompile_method on the cleaned output.

Pairing with `re-leak-scan`

A .NET-style launcher that calls out to telemetry endpoints (Sentry, Logstash, Confluence, Google Drive) will have those URLs as field-default constants. Run re-leak-scan (T2.2) on the assembly, or call list_strings here and pipe the output through a regex filter for the four endpoint families.

Available Tools

11 tools

check_dotnetA

Return .NET runtime + re-dotnet-cli + ilspycmd availability.

Reports WARN (not ERROR) if either binary is not found — this lets Claude Code load the plugin in degraded mode and surface a useful message instead of crashing.

The :func:runner._cli_binary / :func:runner._decompiler_binary fallback chains search $RE_DOTNET_CLI_PATH / $RE_DOTNET_DECOMPILER_PATH first, then <server>/bin/, then $PATH.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses that missing binaries produce a WARN (not ERROR) for degraded mode, and lists fallback search paths. This adds useful behavioral context beyond the basic functionality.

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?

The description is well-structured and front-loaded with the purpose. It provides necessary detail about the WARN behavior and fallback paths without excessive verbosity. It could be slightly more concise, but it is efficient.

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

Completeness4/5

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

Given the tool's simplicity (no parameters, no output schema), the description is sufficient. It covers what is returned, the error handling, and how binaries are located. It could clarify the return format slightly, but it is adequate.

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

Parameters4/5

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

The input schema has zero parameters (100% coverage), so the baseline is 4. The description does not need to explain parameters.

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?

The description clearly states the verb 'Return' and specifies the exact resources: '.NET runtime + re-dotnet-cli + ilspycmd availability'. It distinguishes from sibling tools like classify_dotnet_protection or decompile_method, none of which check availability.

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

Usage Guidelines4/5

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

The context implies this is a pre-flight check, and the warning vs error behavior is explained. However, it does not explicitly say when to use it (e.g., before other tools) or provide alternatives.

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

classify_dotnet_protectionA

Walk a .NET assembly for canonical obfuscation patterns.

Returns category-only labels (type-name-renaming, control-flow-flattening, string-encryption, managed-anti-debug, resource-encryption, native-aot-stub). Never names a specific commercial obfuscator.

The walker uses the re-dotnet Python helper :mod:re_dotnet.protection_classifier (pure-Python IL/Metadata subset; no need for the .NET CLI binary to be built). The CLI is only used for type-name listing (already covered by :func:parse_assembly).

Args: path: path to a .dll / .exe .NET assembly max_per_category: per-category cap (default 50)

Returns::

{
  "path": "...",
  "matches": [{"category": "...", "evidence": "...",
               "evidence_member": "..."}, ...],
  "by_category": {"type-name-renaming": 12, "string-encryption": 4, ...}
}

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`max_per_category`	No

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses behavioral traits: it only returns category labels, never names specific obfuscators, and uses a pure-Python helper without requiring the .NET CLI binary. It also describes the output structure.

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?

The description is front-loaded with the main purpose and lists categories. It includes implementation details (re-dotnet helper) that are useful for understanding dependencies. While slightly verbose, every sentence adds value, and the structure with Args and Returns is clear.

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

Completeness4/5

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

The tool lacks an output schema, but the description compensates by providing a detailed return format with an example. It covers parameters, behavior, and output structure. However, it does not mention error handling or edge cases.

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?

The input schema properties have no descriptions (0% coverage), but the description's Args section provides clear explanations: path is a .dll/.exe path, max_per_category is a cap with default 50. This adds meaning beyond the schema's type annotations.

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?

The description uses a specific verb 'Walk' and resource '.NET assembly', and explicitly lists the category labels it returns. It distinguishes itself from sibling tools by focusing on classification of obfuscation patterns, not specific obfuscator names.

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

Usage Guidelines4/5

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

The description explains when to use this tool (to get category labels for canonical obfuscation patterns) and provides an alternative suggestion: for type-name listing, use parse_assembly instead. However, it does not explicitly state when not to use this tool.

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

decompile_methodA

Decompile a single method to C# via ilspycmd.

Args: path: path to a .dll / .exe .NET assembly fqn: "Namespace.Type::MethodName" (the :: separator matches the C++ convention; do not use . between type and method name — those are both parts of the type FQN)

Returns::

{"path": "...", "fqn": "...", "code": "C# method body..."}

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`fqn`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

Describes return format (JSON with path, fqn, code) and mentions decompiling to C#. No annotations provided, so full burden on description. Lacks disclosure of side effects, prerequisites, or error conditions.

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

Conciseness5/5

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

Starts with a clear one-line summary, followed by structured argument list and expected return format. Every sentence serves a purpose, no fluff.

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

Completeness4/5

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

Coverage is good: purpose, parameters, return value documented. Could mention potential errors (e.g., invalid path or FQN), but the tool is simple and the description is sufficient for common use.

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 has 0% description coverage, but description fully explains both parameters: 'path' as .NET assembly path, 'fqn' with detailed format and separator rules. Adds meaning well beyond schema.

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?

Description clearly states the verb 'decompile', resource 'single method', and tool used 'ilspycmd'. Distinguishes from sibling 'decompile_type' which targets a whole type.

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

Usage Guidelines3/5

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

Provides detailed argument format (especially FQN with '::'), which aids correct invocation. However, no explicit guidance on when to use this vs siblings like 'decompile_type'.

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

decompile_typeA

Decompile a single class to C# via ilspycmd.

Args: path: path to a .dll / .exe .NET assembly fqn: fully-qualified type name (e.g. MyGame.PlayerController). Discover candidates with :func:parse_assembly first.

Returns::

{"path": "...", "fqn": "...", "code": "C# source..."}

On decompiler failure (e.g. an obfuscated control-flow pattern ilspycmd refuses to lift, or ilspycmd not installed), returns code: null and a non-null error field. ilspycmd is the industry-standard CLI for ILSpy; for protected binaries the next step is re-decompile (which calls into de4dot for unpacking) before re-running this tool.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`fqn`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Since no annotations are present, the description carries full burden. It discloses success/failure behavior: returns code on success, or 'code: null' with a non-null 'error' field on failure. It also explains possible failure causes (obfuscated patterns, missing ilspycmd). Side effects are unlikely and not mentioned, which is fine for a read-only decompilation tool.

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?

The description is concise and well-structured: a opening sentence defines the purpose, followed by Args and Returns sections, then notes on failure handling and next steps. It front-loads the purpose and avoids unnecessary details. Every sentence adds value.

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

Completeness4/5

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

Given the tool's complexity (2 parameters, no output schema, no annotations), the description covers essential aspects: purpose, parameters, return format, failure modes, and workflow (parse_assembly first, re-decompile if needed). It lacks explicit error field name in the example, but the text clarifies. Overall, it equips an AI agent adequately.

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

Parameters4/5

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

Schema coverage is 0%, but the description provides meaningful parameter semantics: 'path' is described as a path to a .dll/.exe .NET assembly, and 'fqn' is explained with an example (MyGame.PlayerController) and guidance to discover candidates via parse_assembly. This adds significant value beyond the schema's bare titles.

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?

The description clearly states the tool's purpose: 'Decompile a single class to C# via ilspycmd.' It uses a specific verb (decompile) and resource (single class), differentiating it from related sibling tools like decompile_method (for methods) and parse_assembly (for discovery).

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

Usage Guidelines4/5

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

The description instructs users to discover candidates with parse_assembly first and notes that on failure (e.g., obfuscation), the next step is 're-decompile' for unpacking. This provides clear context and a workflow, but does not explicitly distinguish from other alternatives like decompile_method in terms of when to use which.

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

detect_managed_anti_debugA

Scan IL method bodies for managed anti-debug primitives.

Looks for IsDebuggerPresent, Debugger.IsAttached, Debug.Assert, Debugger.Break, and the curated indirect-check set (timing traps, process-name blacklists, registry probes). Returns {method_fqn, primitive, evidence_il_offset} per hit. The category is "managed-anti-debug"; no vendor is named.

Args: path: path to a .NET assembly max_per_method: cap per method (default 500; a single method with 500+ anti-debug calls is itself a signal — the cap is for safety, not for normality)

Returns::

{
  "path": "...",
  "hits": [{"method_fqn": "...", "primitive": "...",
            "evidence_il_offset": N}, ...],
  "by_primitive": {"IsDebuggerPresent": 4, ...}
}

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`max_per_method`	No

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description does a good job disclosing behavior: it explains the max_per_method cap (500) with rationale that a single method with 500+ is itself a signal. It also names the category and notes no vendor is named. However, it does not explicitly state that the tool is non-destructive or read-only, which is implied but not confirmed.

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?

The description is well-structured with a brief intro, a list of primitives, and separate Args/Returns sections. It is somewhat lengthy but every sentence adds value, front-loading the purpose. A minor improvement could be even more concise.

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

Completeness4/5

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

Given the complexity of anti-debug detection and the lack of an output schema, the description provides a thorough overview of what the tool does and returns. It lists the output structure with fields. It does not cover error handling or edge cases, but is sufficient for understanding the tool's functionality.

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

Parameters4/5

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

Schema description coverage is 0%, so the description fully compensates by explaining both parameters: 'path' as the .NET assembly path and 'max_per_method' with default 500 and a justification. This adds meaning beyond the bare schema types.

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?

The description clearly states the tool scans IL method bodies for managed anti-debug primitives, listing specific checks like IsDebuggerPresent, Debugger.IsAttached, etc. It also describes the output format, making the purpose unmistakable. It distinguishes itself from siblings by focusing on anti-debug detection.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus siblings. The description implies it is for detecting anti-debug primitives in .NET assemblies, but lacks when-not-to-use or alternative recommendations. Given the sibling tools, an explicit note would help.

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

get_entry_pointA

Return the managed entry point (<Module>::.cctor or Main).

Useful for "what does the launcher do first?" — point a decompiler at the entry point before reading the rest of the class graph.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

No annotations; description indicates return of entry point but lacks details on return format (e.g., string vs. object) and potential failure modes.

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

Conciseness5/5

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

Two concise sentences, front-loaded with purpose, no wasted words.

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

Completeness2/5

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

Lacks explanation of parameter and return format. No output schema or annotations, so description should provide more behavioral and semantic details.

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

Parameters2/5

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

Schema coverage is 0% and description does not explain the single required parameter 'path'. It adds no meaning beyond 'path'.

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?

The description clearly states the tool returns the managed entry point (`.cctor` or `Main`), which is a specific resource. It distinguishes from sibling tools that focus on decompilation or protection classification.

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

Usage Guidelines4/5

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

Provides usage context: useful for understanding initial execution before decompiling. However, no explicit when-not-to-use or alternatives given.

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

get_fieldsA

List the fields of one type (Mono / .NET pure assembly).

Same routing pattern as :func:get_methods. The CLI subcommand is list-fields in :mod:Re.Dotnet.Cli.Ops.MetadataOps.

A12 (v2.8.1): added so the CD-3 patch coordinates (which need the field name _isSteam) can be discovered without decompile_type first.

Args: path: path to a .dll / .exe .NET or Mono assembly fqn: fully-qualified type name limit: max rows to return (default 200)

Returns::

{"path": "...", "fqn": "...", "type_fqn": "...",
 "count": N,
 "fields": [{"name": "...", "field_type": "...",
             "is_public": bool, "is_static": bool,
             "is_read_only": bool, "is_literal": bool,
             "constant": "..."}, ...]}

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`fqn`	Yes
`limit`	No

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. Describes the read-only listing behavior, default limit (200), and detailed return structure. No side effects mentioned but not needed for a listing tool.

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-structured with sections, front-loads main purpose. Some technical references (CLI subcommand, version note) add length but are contextually relevant. Not overly verbose.

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

Completeness5/5

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

No output schema, but description provides full return JSON structure. No annotations, but covers all necessary behavioral and param details. Complete for a 3-parameter listing tool.

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 0%, but description includes Args block explaining each parameter: path (path to .dll/.exe), fqn (fully-qualified type name), and limit (max rows, default 200). Adds meaning beyond schema titles and types.

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?

Clearly states 'List the fields of one type (Mono / .NET pure assembly).' Verb 'list' and resource 'fields of a type' are specific. Distinguishes from siblings like `get_methods` (methods) and `decompile_type` (full decompilation).

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

Usage Guidelines4/5

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

Provides usage context: same routing as `get_methods`, and a version note explaining its use case for discovering field names without `decompile_type`. Lacks explicit when-not or exclusion scenarios, but gives clear context.

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

get_methodsA

List the methods of one type (Mono / .NET pure assembly).

Pure routing: the C# CLI already implements list-methods in :mod:Re.Dotnet.Cli.Ops.MetadataOps (uses System.Reflection.Metadata via the .NET 10 runtime). This MCP wrapper is the v2.8.1 (A12) addition that exposes the Mono path the r03-stress run flagged as missing.

A12 note (v2.8.0): on Mono assemblies (e.g. CD's MonoLauncher) this tool did not exist; callers had to fall back to decompile_type + regex on the C# source. The MCP wrapper fixes the routing gap; the underlying CLI subcommand is already battle-tested on the IL2CPP path (re-il2cpp.get_methods uses the same code path).

Args: path: path to a .dll / .exe .NET or Mono assembly fqn: fully-qualified type name (e.g. MyGame.PlayerController) limit: max rows to return (default 500)

Returns::

{"path": "...", "fqn": "...", "type_fqn": "...",
 "count": N,
 "methods": [{"name": "...", "signature": "...",
              "is_public": bool, "is_static": bool,
              "is_virtual": bool, "is_abstract": bool,
              "is_final": bool, "is_special_name": bool,
              "rva": N, "token": "..."}, ...]}

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`fqn`	Yes
`limit`	No

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns a list of methods with detailed attributes and is a wrapper around a CLI subcommand. No destructive behavior implied.

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

Conciseness3/5

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

The description includes background context (A12 note, Mono path) that is informative but somewhat verbose. It is structured with sections (description, args, returns) but could be more concise.

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

Completeness4/5

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

Given no output schema, the description provides a detailed return format. It also explains the tool's purpose, parameter details, and development context, making it sufficiently complete for an agent.

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

Parameters4/5

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

All three parameters (path, fqn, limit) are explained with descriptions and default value for limit. This compensates for 0% schema description coverage.

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?

The description clearly states the tool's purpose: listing methods of a type in Mono or .NET assemblies. It distinguishes from sibling tools like decompile_type and get_fields.

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

Usage Guidelines4/5

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

Provides context on when to use this tool (e.g., for Mono assemblies, fixing a routing gap) and mentions an alternative fallback (decompile_type + regex). Lacks explicit when-not-to-use but offers clear guidance.

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

list_stringsA

Extract user-visible strings from the .NET #US heap.

Two modes:

"field-default" (default): walks every type's const string field-default values. Best for the pure-.NET path where most strings live in static readonly fields.
"ldstr" (v2.8.1, A11): walks every method body's IL stream and captures every ldstr operand. Best for the Mono path (CD's MonoLauncher is the canonical example) where most useful strings live in ldstr operands, not field-defaults.

The C# CLI subcommand is list-strings for field-default and list-ldstr for ldstr (both implemented in :mod:Re.Dotnet.Cli.Ops.MetadataOps). On encrypted / obfuscated #US heaps the CLI returns count: 0 silently — that's a legitimate "heap unreadable" signal, not a regression.

Args: path: path to a .dll / .exe .NET assembly mode: "field-default" (default) or "ldstr" limit: maximum strings to return (default 500)

Returns::

{"path": "...", "mode": "...", "count": N, "truncated": bool,
 "strings": [{"fqn": "...", "kind": "...", "il_offset": N,
              "string": "..."}, ...]}

ParametersJSON Schema

Name	Required	Default
`path`	Yes
`mode`	No	field-default
`limit`	No

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description fully covers behavior: it explains the two modes, CLI subcommands, and the silent 'count: 0' response for encrypted heaps. It lacks details on performance or side effects but is adequate for a read-only analysis tool.

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?

The description is structured into clear sections (modes, CLI, args, return) and includes relevant details. It is somewhat lengthy but efficient given the tool's complexity; a slightly tighter focus on essential info could improve conciseness.

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

Completeness4/5

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

Given no output schema, the description provides a complete return format example and covers edge cases. It lacks information on error handling or permissions but is sufficiently complete for a .NET string extraction tool within the given sibling context.

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?

The schema has no descriptions (0% coverage), so the description compensates fully: it explains each parameter's purpose, default values, and mode options. It also provides a detailed return format example, adding significant meaning beyond the schema.

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?

The description clearly states the tool's purpose: 'Extract user-visible strings from the .NET #US heap.' It distinguishes two modes (field-default and ldstr) with specific use cases, making it distinct from sibling tools which target different .NET analysis tasks.

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

Usage Guidelines4/5

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

The description provides explicit guidance on when to use each mode (pure-.NET vs Mono path) and mentions edge cases (encrypted heaps). However, it does not directly compare to alternative tools or state when not to use this tool, leaving some ambiguity.

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

parse_assemblyA

Enumerate TypeDef rows in path.

Returns the assembly header (name, version, target framework, entry point) plus a one-row-per-type summary. This is the .NET cousin of re-lief.parse_binary and re-il2cpp .get_assembly_types — the analyst's first call on a .NET-style launcher or mod-loader.

Output shape::

{
  "header": {
    "path": "...",
    "assembly_name": "...",
    "assembly_version": "...",
    "target_framework": "...",
    "corlib": "...",
    "is_mixed_mode": bool,
    "entry_point": "Namespace.Type::Method",
    "file_kind": "assembly" | "netmodule",
    "type_count": N,
    "method_count": N,
    "field_count": N,
  },
  "types": [
    {"fqn": "...", "namespace": "...", "name": "...",
     "is_public": bool, "method_count": N, "field_count": N,
     "property_count": N, "event_count": N, "nested_type_count": N,
     "base_type": "..."},
    ...
  ],
  "truncated": false
}

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations provided, the description fully discloses the tool's behavior by detailing the output structure, including fields like 'truncated' flag. It implies a read-only enumeration without modification, and the shape of the return value is comprehensively described.

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?

The description is well-structured with a clear action first, then a detailed output specification. It is concise for the amount of information provided, though the code block could be considered lengthy.

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?

Given the tool has a single parameter and no output schema, the description provides a complete understanding of usage and output. It includes comparative context with other tools, meeting all needs for this simple tool.

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

Parameters3/5

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

The single parameter 'path' is only cursorily mentioned ('in *path*') without explanation of its meaning or format. With 0% schema description coverage, the description should provide more context, such as that it expects a file path or assembly location.

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?

The description clearly states the action ('Enumerate TypeDef rows in *path*') and specifies the resource (assembly file). It distinguishes from siblings by noting it's the 'first call' for .NET-style launcher or mod-loader, and compares to external tools like re-lief.parse_binary and re-il2cpp.get_assembly_types.

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

Usage Guidelines4/5

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

The description implies usage as an initial step for .NET binaries ('analyst's first call'), providing context for when to use it. However, it lacks explicit guidance on when not to use it or direct alternatives among the listed sibling tools, though the comparison to external tools partially compensates.

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

run_il_simplificationA

Run a d810-ng-style IL simplification pass set on one method.

Currently supported passes:

constant_fold — replace arithmetic on constants with the constant result.
dead_branch_elim — remove branches that are provably dead after constant folding.
opaque_predicate_eval — evaluate predicates whose truth is provable from prior dataflow.
string_decrypt — replace ldstr; call Get<name>(); ret patterns with the literal string. The decryption function name is auto-detected from the assembly's #Strings heap.

Args: path: path to a .NET assembly method_fqn: "Namespace.Type::MethodName" passes: optional override; default is ["constant_fold", "dead_branch_elim", "opaque_predicate_eval", "string_decrypt"].

Returns::

{
  "path": "...",
  "method_fqn": "...",
  "passes_applied": [...],
  "before_il_size": N,
  "after_il_size": M,
  "il_before": "...",
  "il_after": "..."
}

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`method_fqn`	Yes
`passes`	No

TDQS

A3.9/5.0

Behavior2/5

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

No annotations exist, so the description carries full burden. It does not disclose whether the tool modifies the assembly in-place or only returns transformed IL. While it lists passes and return format, the mutation aspect is unclear, which is a significant gap for a tool that likely modifies code.

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?

The description is well-structured with sections for introduction, passes list, args, and returns. It is front-loaded with the main purpose. Slightly lengthy due to detailed pass explanations, but each sentence adds value.

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?

Given no output schema and no annotations, the description covers all aspects: purpose, parameters, pass semantics, and return format with a JSON example. It is thorough enough for an agent to invoke the tool 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?

With 0% schema coverage, the description fully explains each parameter: path as .NET assembly path, method_fqn with format, and passes with allowed values and defaults. This provides essential meaning beyond the bare schema.

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?

The description clearly states the tool runs a d810-ng-style IL simplification pass set on one method, listing specific passes and differentiating from sibling tools like decompile_method.

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

Usage Guidelines3/5

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

The description provides context on what the passes do but does not explicitly state when to use this tool versus alternatives like decompile_method or get_methods. Usage is implied but not guided.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

All tools have clearly distinct purposes—from runtime checks to assembly parsing, decompilation, and obfuscation detection. No overlapping functionality.

Naming Consistency4/5

Most tools follow a verb_noun pattern (e.g., decompile_method, get_fields), with only minor variations like run_il_simplification. Overall consistent and readable.

Tool Count5/5

11 tools is an ideal size for a domain-specific reverse engineering server—comprehensive without being overwhelming.

Completeness5/5

The tool surface covers assembly metadata, method/field enumeration, decompilation, protection analysis, anti-debug scanning, string extraction, and IL simplification—no obvious gaps for .NET analysis.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
mcp-klever-vm A
io.github.klever-io
MCP server for Klever blockchain smart contract development.
Blockchain Developer Tools Code Execution
16331
Hex.pm MCP B
io.github.joshrotenberg
MCP server for hex.pm and hexdocs.pm: search, inspect, compare, and audit Elixir packages
Developer Tools Documentation Access
2422

Related MCP Servers

dotnet-sherlock-mcp
Developer Tools Code Analysis
jcucci
A
license
Not graded
quality
A
maintenance
ILSpy for LLM coding agents. Reflection-based MCP server with 31+ tools to explore .NET assemblies, NuGet packages, types, members, attributes, and XML docs.
Updated a month ago (2026-08-06 14:26 UTC)
6
MIT
dnSpy-MCP
Code Analysis Developer Tools
notgate
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server for static .NET assembly analysis, offering decompilation, IL disassembly, metadata inspection, and protection detection tools without executing target assemblies.
Updated 5 months ago (2026-04-16 00:20 UTC)
17
re-dotnet-patch
Developer Tools Code Analysis
Heretek-RE
A
license
B
quality
C
maintenance
MCP server for structured patching of Mono / .NET assemblies.
Updated 3 months ago (2026-06-10 19:50 UTC)
6
MIT
dotnet-decompiler-mcp
Developer Tools Code Analysis
Kommisaar
F
license
A
quality
C
maintenance
An MCP server that decompiles and inspects .NET assemblies to C# source, wrapping ILSpy. Enables querying .NET DLLs via natural language to decompile types, list members, and search symbols.
Updated 2 months ago (2026-06-20 09:25 UTC)
7

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Heretek-RE/re-dotnet'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

re-dotnet

Why

Architecture

Tools

Install

Requirements

Deobfuscation notes

Pairing with re-leak-scan

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Pairing with `re-leak-scan`