dotnet-decompiler-mcp

by Kommisaar

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: environment checking, decompiling types, decompiling members, getting type summaries, listing namespaces, listing types, and searching symbols. No overlap or ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern: check_env, decompile_member, decompile_type, get_type_summary, list_namespaces, list_types, search_symbol. The pattern is uniform and predictable.
Tool Count5/5
Seven tools is an ideal size for a decompiler MCP server, covering diagnostics, exploration, and decompilation without being overwhelming or insufficient.
Completeness4/5
The tools cover the core exploration and decompilation workflow (list namespaces, types, summary, decompile type/member, search). However, missing are options for decompilation settings (e.g., with/without comments, debug info), which would make it fully complete.
Average 4.7/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Covers key behaviors: checks runtime and DLL presence, returns version info, explains asm_search_dirs. No annotation contradictions. Could mention it's non-destructive.
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 example and returns section. Front-loaded purpose. Slightly verbose but earned.
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?
Covers purpose, behavior, return values, and field meanings. Output schema exists; description complements it. Fully sufficient for a parameterless diagnostic tool.
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?
No parameters, so baseline 4 applies. Description adds value with example output and field descriptions 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?
The description clearly states 'Startup diagnostics: verify runtime / DLL / versions are ready', specifying a unique diagnostic purpose distinct from sibling tools that handle decompilation and symbol search.
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?
Implied as startup diagnostics but lacks explicit guidance on when to use versus alternatives. No mention of prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. While it lists raised exceptions (DllNotFoundError, etc.), it does not explicitly state the tool is read-only or mention any side effects. The behavior is implied but could be more explicit regarding permissions or effects.
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 moderately lengthy but well-structured with sections for summary, tip, examples, args, returns, and raises. Each sentence adds value, though some duplication could be trimmed slightly.
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 input schema lacks descriptions, the description covers all necessary aspects: purpose, usage, parameters, return type (via output schema existence), and possible exceptions. It is complete and self-contained for an agent to use 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?
The input schema has 0% description coverage, but the description compensates with a detailed 'Args' section explaining each parameter (dll, type_name, member_name, asm_paths). Examples illustrate usage, adding substantial 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 it decompiles a single member (method/field/property/event/ctor) to C#. It distinguishes itself from the sibling tool `decompile_type` by being lighter and targeting a single member, which provides specificity.
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?
The description explicitly says to use this tool when only one method or property from a large type is needed, contrasting it with `decompile_type`. It also suggests running `get_type_summary` first to find member names, providing clear context on when to use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the matching behavior (case-insensitive substring), that it returns all matches across DLLs, and lists raised exceptions. It does not explicitly state that the tool is read-only, but that is implied by the search nature. Overall, it provides sufficient behavioral context.
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?
The description is well-structured with sections, examples, and parameter listings. It is concise yet comprehensive, with every sentence adding value. The examples are particularly helpful for quick understanding.
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's complexity (4 parameters, no annotations, output schema existing), the description covers all necessary aspects: purpose, parameters, behavior, return type, and errors. It mentions the return object includes owning type info, which is useful for interpretation.
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 description adds full meaning to all four parameters beyond the schema titles. It explains dlls and query clearly, lists all valid values for kind with descriptions, and explains asm_paths as an advanced parameter. Given the 0% schema description coverage, the description fully compensates.
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: 'Search for symbols by name across one or more assemblies.' It uses a specific verb ('search') and resource ('symbols'), and distinguishes itself from sibling tools like decompile_type by focusing on search across assemblies rather than decompiling specific 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 provides examples and hints about when to use this tool, such as when you're not sure which assembly contains a type. It also refers to decompile_type for asm_paths context. However, it does not explicitly state when not to use or provide a direct comparison with all sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses public-only members, includes signatures, lists exceptions (DllNotFoundError, TypeNotFoundError), and describes return type. Could mention caching or performance, but not required for this static tool.
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?
Well-structured with summary, example, Args, Returns, Raises. Front-loaded with purpose. No fluff. Every 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?
Despite no annotations and 0% schema coverage, the description is complete: covers tool purpose, parameter details, return type, errors, and usage context. Output schema exists but description still provides useful summary.
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 the description adds full semantics: dll is absolute path, type_name is fully-qualified case-sensitive, asm_paths is extra dependency dirs (almost never needed). This adds significant meaning.
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 it gets a detailed member summary of a single type (public members only), lists what it returns (methods, fields, properties, events), and provides an example. It distinguishes itself from siblings like decompile_member and decompile_type.
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 says to use this tool to find exact member names before calling decompile_member. Provides an example and notes that asm_paths is almost never needed, with alternative tools listed in siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses automatic dependency resolution, specific error types raised, and that output includes decompiled source plus metadata. No contradictions.
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 a clear summary, tips, examples, and parameter descriptions. Slightly verbose due to examples and detailed parameter text, but the organization makes it easy to parse. Could be trimmed slightly without losing 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 the complexity (3 params, output schema exists, sibling tools), the description is very complete. It covers usage, behavior, parameter semantics, error handling, and return values (via output schema). No gaps.
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 description compensates thoroughly. It explains each parameter: 'dll' (absolute path), 'type_name' (fully-qualified, case-sensitive, with examples), and 'asm_paths' (optional, default None, when needed). Adds 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 'Decompile a whole .NET type to C# source (with comments),' specifying the verb (decompile), resource (.NET type), and output (C# source). It distinguishes from sibling tools like 'decompile_member' and 'list_types' by focusing on whole type decompilation.
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?
Provides explicit guidance: use 'list_types' first to discover types, pass exact 'namespace.TypeName', and notes that 'asm_paths' is almost never needed due to automatic dependency resolution. This helps the agent choose when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully bears the burden. It discloses error conditions (DllNotFoundError), return format (NamespaceListResult with sorted namespaces and total count), and the dll parameter requirement (absolute path, readable file). This is comprehensive and beyond minimal.
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 example and parameter docs, but it is somewhat verbose with the docstring format including Args/Returns/Raises. Could be slightly tighter without losing clarity, but earns high marks for organization.
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?
The tool has an output schema so return values are covered by that; the description adds error handling and parameter constraints. Given the tool's moderate complexity and the presence of an output schema, the description is complete and leaves no gaps for an AI agent to misinterpret.
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%, but the description adds full meaning: dll is 'Absolute path to the assembly to inspect' and asm_paths is 'Extra dependency dirs (almost never needed — see decompile_type)'. This compensates entirely for the schema's lack of 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?
The description clearly states the tool lists distinct namespaces with type counts, using specific verbs and resources. It distinguishes itself from siblings by positioning it as the first step for exploring unknown DLLs, unlike list_types, decompile_type, etc.
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 advises use as a first step for exploring unknown game/mod DLLs and provides an example. It also notes when asm_paths is rarely needed and directs to decompile_type for context, giving clear guidance on when to use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: namespace filter is prefix match, default lists all types (potentially large), asm_paths purpose, exceptions like DllNotFoundError, and return type summary. No contradictions.
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?
Well-structured with clear sections: purpose, filter explanation, warnings, workflow, examples, Args/Returns/Raises. Each sentence adds value. Front-loaded with main action.
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?
Comprehensive coverage: purpose, usage, parameters, return type, errors, workflow integration. Output schema exists but description still summarizes return. No gaps given tool complexity and 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?
Schema description coverage is 0%, but description adds full meaning: dll is absolute path, namespace is prefix filter with default '', asm_paths is optional dependency dirs. Clarifies types and defaults beyond schema 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?
Description clearly states 'List types in an assembly, optionally filtered by namespace prefix.' Verb 'list' and resource 'types in an assembly' are specific. Differentiates from siblings like list_namespaces (lists namespaces) and decompile_type (decompiles).
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?
Provides a recommended exploration flow (list_namespaces -> list_types -> get_type_summary -> decompile_type), warns about large results with empty filter, and gives concrete examples. Explains when to use namespace filter and that asm_paths is rarely needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dotnet-decompiler-mcp MCP server](https://glama.ai/mcp/servers/Kommisaar/dotnet-decompiler-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Kommisaar/dotnet-decompiler-mcp)

Score Badge

Copy to your README.md:

[![dotnet-decompiler-mcp MCP server](https://glama.ai/mcp/servers/Kommisaar/dotnet-decompiler-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Kommisaar/dotnet-decompiler-mcp)

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/Kommisaar/dotnet-decompiler-mcp'

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