ILSpy MCP Server

Beta: This project is under active development. Expect breaking changes from day to day.

MCP server that gives AI assistants .NET decompilation and static analysis capabilities via ILSpy. Works with any MCP client (Claude Code, Codex, Opencode, Cursor, and more) on Windows, Linux, and macOS.

Ask your favourite AI Chatbot to explain how to use ILSpy MCP Server:

---

• What is this?
• Features
• Supported MCP clients
• Quick start
  • Step 1: Get the binary
  • Step 2: Choose your transport
  • Step 3: Configure your MCP client
• How it works
• Usage examples
• Tool reference
  • Decompilation
  • IL disassembly
  • Type analysis
  • Cross-references
  • Assembly inspection
  • Search
  • Cross-assembly
  • Bulk operations
• HTTP server reference
• Configuration reference
• Comparison with other servers
• Acknowledgements
• License

---

What is this?

ILSpy MCP Server wraps ICSharpCode.Decompiler (the engine behind ILSpy) as a Model Context Protocol (MCP) server. Your AI assistant calls the decompiler directly and gets back structured results it can reason over. No GUI needed.

Features

27 tools across 8 categories:

• Decompilation – types, methods, and entire namespaces to C# source
• IL disassembly – raw CIL/IL at the type or method level
• Type analysis – list types, inspect members, trace hierarchies, find implementors, discover extension methods
• Cross-references – usages, dependencies, instantiation sites
• Assembly inspection – metadata, custom attributes (assembly/type/member), embedded resources, compiler-generated types
• Search – string literals and numeric constants in IL bytecode
• Cross-assembly – resolve types across assemblies, load entire directories
• Bulk operations – export assemblies as complete C# projects

Supported MCP clients

Works with any MCP-compatible client. We recommend Claude Code.

Amazon Q Developer CLI, Augment Code, Claude, Claude Code (recommended), Cline, Codex, Copilot CLI, Crush, Cursor, Gemini CLI, Kilo Code, Kiro, LM Studio, Opencode, Qodo Gen, Qwen Coder, Roo Code, Trae, VS Code, VS Code Insiders, Warp, Windsurf, Zed, and more.

Quick start

Step 1: Get the binary

Choose how you want to install:

Step 2: Choose your transport

Use the flowchart below to decide how to set up the server:

flowchart TD
    A[Where is the DLL you want to analyze?] --> B{Is the DLL on your\nlocal machine?}
    B -->|Yes| C[Use stdio transport\nDefault -- no extra config needed]
    B -->|No| D{Does the DLL need to stay\non a VM for security?\ne.g. malware analysis}
    D -->|Yes| E[Use HTTP transport\nRun the server on the VM]
    D -->|No| C
    C --> F[Go to Step 3:\nConfigure with stdio]
    E --> G[Start the HTTP server on the VM]
    G --> H[Go to Step 3:\nConfigure with HTTP URL]

stdio (default) – The MCP client launches the server automatically. No extra setup. Use this if the DLLs are on your local machine.

HTTP – You start the server manually on a remote machine. Use this for analysis VMs, build servers, or Docker containers. See HTTP Server Reference for startup commands and configuration.

Step 3: Configure your MCP client

Pick your client and follow the steps.

Uninstall

1. Remove the MCP client registration:

2. Delete the extracted directory:

   Windows (PowerShell):

   Remove-Item -Recurse -Force C:\path\to\ilspy-mcp
   

   Linux / macOS:

   rm -rf /path/to/ilspy-mcp
   

3. (Built from source only) Delete the cloned repo:

   rm -rf ILSpy-MCP
   

The server stores no config, cache, or state outside its own directory, so no other cleanup is needed.

How it works

You don’t interact with ILSpy MCP directly. Your MCP client (Claude Code, Cursor, etc.) launches and communicates with it automatically in the background.

To analyze a .NET assembly, mention the full path to the DLL in your chat. The AI assistant picks the right tools automatically.

Usage examples

Replace the paths below with actual DLL paths on your machine:

• Decompile a type – “Decompile the String class from C:\Program Files\dotnet\shared\Microsoft.NETCore.App\10.0.0\System.Runtime.dll”
• List all types – “List all types in C:\Users\me\projects\MyApp\bin\Debug\net10.0\MyLibrary.dll”
• Find a method – “Find the CalculateTotal method in D:\libs\Calculator.dll”
• Decompile a constructor – “Decompile the .ctor constructor of UserService in C:\repos\MyApp\bin\Debug\net10.0\MyApp.dll”
• Analyze type hierarchy – “Show me the type hierarchy for ProductService in C:\repos\ECommerce\bin\Release\net10.0\ECommerce.dll”
• Search members – “Search for members containing ‘Authenticate’ in C:\repos\AuthService\bin\Debug\net10.0\Auth.dll”
• View IL disassembly – “Show me the raw IL for the Serialize method in C:\repos\MyApp\bin\Debug\net10.0\MyApp.dll”
• Find all usages – “Where is the Save method of IRepository called in C:\repos\MyApp\bin\Debug\net10.0\MyApp.dll?”
• Find implementors – “What types implement ILogger in C:\Program Files\dotnet\shared\Microsoft.NETCore.App\10.0.0\Microsoft.Extensions.Logging.dll?”
• Trace dependencies – “What does the ProcessOrder method in OrderService depend on in C:\repos\ECommerce\bin\Release\net10.0\ECommerce.dll?”
• Find instantiations – “Where is HttpClient instantiated in C:\repos\MyApp\bin\Debug\net10.0\MyApp.dll?”
• Inspect assembly metadata – “What target framework and PE bitness does C:\repos\MyApp\bin\Release\net10.0\MyApp.dll target?”
• Read custom attributes – “What custom attributes are on the OrderService class in C:\repos\ECommerce\bin\Debug\net10.0\ECommerce.dll?”
• Extract embedded resources – “List all embedded resources in C:\repos\MyApp\bin\Debug\net10.0\MyApp.dll and extract the SQL migration script”
• Find compiler-generated types – “Show me the async state machines and closures in C:\repos\MyApp\bin\Debug\net10.0\MyApp.dll”
• Export a project – “Export C:\repos\MyApp\bin\Debug\net10.0\MyApp.dll as a C# project to C:\temp\MyApp-decompiled”

Tool reference

Pagination: Tools that return lists (e.g., list_namespace_types, find_*, search_*) accept maxResults and offset parameters with sensible defaults and always include a trailing [pagination:{...}] footer reporting total, returned, truncated, and nextOffset. See docs/PAGINATION.md for the complete contract, including the hard ceiling and worked examples.

Decompilation

decompile_type

Decompile a .NET type to C# source code with AI-analyzed insights about usage patterns.

---

decompile_method

Decompile a specific method or constructor (.ctor/.cctor) to C# source code.

---

list_namespace_types

List all types in a namespace with full signatures, member counts, and public method signatures. Returns a summary – use decompile_type to get full source for individual types.

---

IL disassembly

disassemble_type

Get raw CIL/IL disassembly of a .NET type showing method signatures, fields, properties, and events in IL format.

---

disassemble_method

Get raw CIL/IL disassembly of a specific method with opcodes, labels, and stack information.

---

Type analysis

list_assembly_types

List all types in an assembly, organized by namespace. Start here when exploring an unfamiliar library.

---

get_type_members

Get the complete API surface of a type (constructors, methods, properties, fields, events) without implementation details.

---

find_type_hierarchy

Find inheritance relationships: base classes, implemented interfaces, and derived types.

---

find_implementors

Find all types implementing a given interface or extending a given base class within an assembly.

---

find_extension_methods

Find extension methods available for a specific type.

---

find_compiler_generated_types

Find compiler-generated types (async state machines, display classes, closures, iterators) with their parent method and type context.

---

search_members_by_name

Search for members (methods, properties, fields, events) by name across all types in an assembly.

---

Cross-references

find_usages

Find all call sites, field accesses, and property usages of a specific member across an assembly.

---

find_dependencies

Find all outward dependencies (method calls, field accesses, type references) of a type or specific method.

---

find_instantiations

Find all sites where a given type is instantiated (newobj) within an assembly.

---

Assembly inspection

analyze_assembly

Get an overview of an assembly’s architecture: main namespaces, public types, and design patterns.

---

get_assembly_metadata

Get assembly metadata including target framework, runtime version, PE bitness, strong name, entry point, and all referenced assemblies.

---

get_assembly_attributes

List all custom attributes declared on an assembly with their constructor arguments and named properties.

---

get_type_attributes

List all custom attributes declared on a type with their constructor arguments and named properties.

---

get_member_attributes

List all custom attributes on a type member (method, property, field, event) with their constructor arguments.

---

list_embedded_resources

List all embedded resources in an assembly with name, type, size, and visibility.

---

extract_resource

Extract embedded resource content. Text is displayed inline, binary as base64. Supports offset and limit for paginated binary extraction.

---

Search

search_strings

Search for string literals in assembly IL bytecode matching a regex pattern. Scans all ldstr instructions.

---

search_constants

Search for numeric integer constants in assembly IL bytecode. Finds all ldc.i4 and ldc.i8 instructions loading the specified value.

---

Cross-assembly

resolve_type

Resolve which assembly in a directory defines a given type. Supports partial type name matching.

---

load_assembly_directory

Load and list all .NET assemblies found in a directory. Scans .dll and .exe files recursively up to the specified depth.

---

Bulk operations

export_project

Export a .NET assembly as a complete C# project (.csproj + .cs files) to a target directory. The directory must be empty or non-existent.

---

Design philosophy

The tools in this project are designed for a specific user: an AI agent working through a large .NET assembly with no prior knowledge of it. That assumption drives every interface decision and distinguishes this project from a general-purpose decompilation library.

AI agents are lazy. They will not chase round-trips. They will not infer hidden affordances from tool names. They will read a tool’s description and parameter list once, decide whether it fits their current intent, and either call it or ignore it. If the description is mechanical (“Lists all X of kind Y”), the agent has to translate that into a use case on the fly — and it does that badly. If the output is bare (“match found in method ‘Process’”), the agent has to make a follow-up call just to figure out which Process method — and after a few such round-trips it gives up and hallucinates. The rest of the design follows from these two assumptions.

Descriptions express scenarios, not mechanics. A well-written tool description starts with “Use this when…” and names the situation the user is in. “Use this when you just installed a NuGet library and need to understand its overall architecture” is a better description than “Analyzes an assembly’s types and namespaces.” The scenario framing lets the agent match intent-to-tool in one pass; the mechanical framing forces it to reason about verbs.

Outputs include nested references by default. When a tool’s result references a type, a method, or a metadata token that the agent will obviously want next, this project resolves it inline. IL disassembly includes the fully-qualified targets of call and newobj instructions. Match results include the containing type and assembly. Attribute listings include constructor arguments and named properties. The tradeoff is worth it: spend more work on the server to save the agent a round-trip.

Pagination is mandatory for unbounded output. Any tool whose result count depends on the assembly’s contents — lists of types, lists of usages, search matches, dependency graphs — exposes maxResults and offset parameters and reports truncated/total in the response. Silent truncation is treated as a bug, not a feature. This is a hard rule.

Rich, but not flooding. The tension between “include nested context” and “don’t flood the context window” is real. The project resolves it by defaulting to summary views and offering opt-in verbosity for specific items the agent can point at. Default responses should contain enough for the agent to pick the next call correctly — not an entire dump.

See .claude/skills/mcp-tool-design/SKILL.md for the developer-facing version of these principles, including the new-tool checklist and the verb-noun naming convention used across the MCP surface.

---

HTTP server reference

For remote access (analysis VMs, build servers, containers), run in HTTP mode. See Step 3 for client configuration.

CLI help

Use the help command to see available startup flags:

ilspy-mcp help
ilspy-mcp --help
ilspy-mcp -h

Starting the HTTP server

The server prints ILSpy MCP server listening on http://0.0.0.0:3001 and stays running until you stop it (Ctrl+C).

Changing port and host

All three settings are resolved in priority order: CLI arg > env var > appsettings.json > default. The --host and --port flags apply only when HTTP transport is selected — using them with stdio transport is an error and the server will refuse to start.

Security

No authentication is built in. The server binds to 0.0.0.0 (all interfaces) by default. Protect it with:

• Firewall rules limiting access to trusted IPs
• A reverse proxy (nginx, Caddy) adding TLS and/or auth
• VPN or SSH tunnel between client and server
• Binding to 127.0.0.1 and using SSH port forwarding

Configuration reference

Comparison with other .NET decompilation MCP servers

Several projects expose .NET decompilation over MCP:

Why this one?

The comparison table above covers feature differences. Here is what it does not show:

You download one binary and run it. No .NET SDK, no Python, no Node.js required. Pre-built binaries exist for Windows, Linux, and macOS on x64 and ARM64.

The server calls ICSharpCode.Decompiler in-process rather than shelling out to CLI tools, so there is no text-parsing layer in between. ICSharpCode.Decompiler is under active development with regular releases, unlike dnSpy which was abandoned in 2020.

HTTP transport lets you run the server on a VM or build server and connect remotely. None of the other servers in the table support this.

Cross-reference analysis (tracing usages, finding implementors, mapping dependencies) and assembly inspection (metadata, attributes, embedded resources, compiler-generated types) are not available in any of the other servers either.

Every operation is read-only. The server never modifies assemblies or executes the code it analyzes. The one exception is export_project, which writes decompiled source files to a directory you specify.

Acknowledgements

Forked from bivex/ILSpy-Mcp.

License

MIT – see LICENSE for details.

---

 ________________________________________

 ----------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||