re-dotnet

by Heretek-RE

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
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.
Average 4.2/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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
This repository is licensed under MIT License.
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

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

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:

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

Score Badge

Copy to your README.md:

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

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