DotNetMetadataMcpServer

.NET Types Explorer MCP Server

A Model Context Protocol (MCP) server that provides detailed type information from .NET projects for AI coding agents.

Overview

The .NET Types Explorer MCP Server is a powerful tool designed to help AI coding agents understand and work with .NET codebases. It provides a structured way to explore assemblies, namespaces, and types in .NET projects, making it easier for AI agents to generate accurate and context-aware code suggestions.

The server uses reflection to extract detailed type information from compiled .NET assemblies, including classes, interfaces, methods, properties, fields, and events. This information is then made available through a set of tools that can be used by AI agents to explore the codebase in a systematic way.

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Features

• Assembly Exploration: Retrieve a list of all assemblies referenced by a .NET project
• Namespace Exploration: Discover all namespaces within specified assemblies
• Type Exploration: Get detailed information about types within specified namespaces, including:
  • Full type names with generic parameters
  • Implemented interfaces
  • Constructors with parameters
  • Methods with return types and parameters
  • Properties with types and accessors
  • Fields with types and modifiers
  • Events with handler types
• NuGet Package Search: Search for NuGet packages on nuget.org with filtering and pagination
• NuGet Package Version Information: Retrieve version history and dependency information for specific NuGet packages
• Configurable Assembly Resolution: Resolve assemblies from build output, NuGet global packages cache (restore-only, no build required), or automatically try both
• Filtering: Apply wildcard filters to narrow down results
• Pagination: Handle large result sets with built-in pagination

Roadmap

• Add NuGet integration to provide information about actual package versions
• Migrate to official Model Context Protocol C# SDK (modelcontextprotocol/csharp-sdk)
• Support for multiple NuGet package sources (custom/private feeds)
• Add dependency graph building capabilities
• Improve multi-project scenario

Prerequisites

• .NET 9.0 SDK or later
• A .NET project that you want to explore

Configuration

NuGet Package Sources

The server supports querying multiple NuGet package sources simultaneously. Configure custom sources in appsettings.json:

{
  "Tools": {
    "DefaultPageSize": 20,
    "IntendResponse": false,
    "NuGetSources": [
      {
        "Name": "nuget.org",
        "Url": "https://api.nuget.org/v3/index.json",
        "Enabled": true
      },
      {
        "Name": "MyPrivateFeed",
        "Url": "https://my-company.com/nuget/v3/index.json",
        "Enabled": true
      },
      {
        "Name": "dotnet-core (MyGet)",
        "Url": "https://dotnet.myget.org/F/dotnet-core/api/v3/index.json",
        "Enabled": true,
        "Comment": "Example: MyGet public feed for .NET Core preview packages"
      }
    ]
  }
}

Configuration Options:

• Name: Friendly name for the package source
• Url: Full URL to the NuGet v3 API endpoint (must end with /v3/index.json)
• Enabled: Set to false to temporarily disable a source without removing it

Behavior:

• All enabled sources are queried in parallel for better performance
• Results are automatically deduplicated by package ID and version
• If one source fails, the server continues with the remaining sources
• Default source behavior: nuget.org is added ONLY if no sources are configured in appsettings.json

Source Priority and Deduplication:

When the same package is found in multiple sources, the server uses a priority-based strategy:

1. Priority is determined by order: Sources listed first in configuration have higher priority
2. Deterministic results: The first source in the list always takes precedence for duplicate packages
3. Parallel queries: Despite parallel execution, results are processed in priority order
4. Metadata consistency: Package metadata (description, download count, etc.) always comes from the highest priority source containing that package

Example:

{
  "NuGetSources": [
    { "Name": "Internal", "Url": "https://internal.company.com/nuget/v3/index.json", "Enabled": true },
    { "Name": "nuget.org", "Url": "https://api.nuget.org/v3/index.json", "Enabled": true }
  ]
}

In this configuration, if a package exists in both sources, information from "Internal" will be used.

Assembly Resolution Mode

The server supports different strategies for locating package assemblies. Configure this in appsettings.json:

{
  "Tools": {
    "AssemblyResolutionMode": "NuGetCache"
  }
}

The NuGetCache mode is particularly useful when you primarily need to explore third-party package APIs without waiting for a full build cycle. The global packages folder path is read from project.assets.json automatically.

Installation

Option 1: Native Installation

1. Clone the repository
2. Build the project:

   dotnet build -c Release

   Copy to clipboard
3. Publish the project:

   dotnet publish -c Release -r <runtime-identifier> --self-contained false

   Copy to clipboard
   Replace <runtime-identifier> with your target platform (e.g., win-x64, linux-x64, osx-x64).

Option 2: Docker

The server is available as a Docker container, providing better isolation and easier deployment:

1. Pull the image from Docker Hub:

   docker pull vrogozhin/dotnet-types-explorer-mcp:latest

   Copy to clipboard

2. Or build locally:

   git clone https://github.com/V0v1kkk/DotNetMetadataMcpServer.git
   cd DotNetMetadataMcpServer
   docker build -t dotnet-types-explorer-mcp .

   Copy to clipboard

3. Run the container:

   docker run --rm -i \
     -v /path/to/your/dotnet/projects:/workspace \
     vrogozhin/dotnet-types-explorer-mcp:latest

   Copy to clipboard

Benefits of Docker deployment:

• No need to install .NET SDK on your machine
• Isolated environment prevents conflicts
• Consistent behavior across different operating systems
• Includes MSBuild and all required dependencies
• Easy updates by pulling the latest image

Configuration

Native Configuration

To use the .NET Types Explorer MCP Server with an AI agent, you need to configure it in your MCP settings file. Here's an example configuration:

{
  "mcpServers": {
    "dotnet-types-explorer": {
      "command": "/path/to/DotNetMetadataMcpServer",
      "args": [ "--homeEnvVariable", "/home/user" ],
      "disabled": false,
      "alwaysAllow": [],
      "timeout": 300
    }
  }
}

Replace /path/to/DotNetMetadataMcpServer with the actual path to the published executable, and /home/user with your home directory.

Docker Configuration

For Docker deployment, configure your MCP client as follows:

{
  "mcpServers": {
    "dotnet-types-explorer": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "-v",
        "/path/to/your/dotnet/projects:/workspace",
        "vrogozhin/dotnet-types-explorer-mcp:latest"
      ],
      "disabled": false,
      "alwaysAllow": [],
      "timeout": 300
    }
  }
}

Replace /path/to/your/dotnet/projects with the directory containing your .NET projects. The container will have access to all projects in this directory.

Important Limitations

• Build requirement depends on resolution mode. In BuildOutput mode (default), the project must be built before scanning. In NuGetCache mode, only dotnet restore is required — the server resolves package assemblies directly from the NuGet global packages cache. Project-specific types are only available when the project has been built.
• The tool doesn't follow references to other projects. It only inspects the specified project and its NuGet dependencies. If you need to analyze multiple projects, you'll need to scan each one separately.

How project outputs are located

When scanning a project, the server needs the compiled assembly path. MsBuildHelper evaluates the project and attempts to locate the output assembly by probing configurations in this order:

• the requested configuration (by default Debug), then
• Release, and if still not found,
• falls back to checking Debug again as a safe default.

The first existing output wins. If no output is found, a reasonable default path is assumed and a warning is logged. This makes local runs (often Debug) and CI runs (often Release) behave consistently. Ensure you build the project in one of these configurations before scanning.

Usage

The server provides five main tools that can be used by AI agents:

1. ReferencedAssembliesExplorer: Retrieves referenced assemblies from a .NET project
2. NamespacesExplorer: Retrieves namespaces from specified assemblies
3. NamespaceTypes: Retrieves types from specified namespaces
4. NuGetPackageSearch: Searches for NuGet packages on nuget.org with filtering and pagination
5. NuGetPackageVersions: Retrieves version history and dependency information for specific NuGet packages

This tool has been tested with the Roo Code Visual Studio extension, an AI coding assistant that supports the Model Context Protocol. You can find more information about Roo Code on GitHub.

It's possible to use .clinerules file to instruct your codding assistant to use the MCP server.

AI Code Assistant Instructions

If you work with .NET projects that have NuGet package references and need to write code using those packages, you should explore the API of those packages systematically using the Dotnet Type Explorer MCP server. This is especially important when you're not familiar with the package's API or when documentation is limited.

When working with a .NET project:

1. First, make sure the project is built. This tool relies on compiled assemblies to extract type information.

2. Start by retrieving all assemblies referenced by the project file using the ReferencedAssembliesExplorer tool. This gives you a list of all available assemblies.

3. Focus on third-party libraries and NuGet packages, not the Base Class Library (BCL) types like System.* or Microsoft.* which are well-documented elsewhere.

4. Once you've identified the relevant assemblies, use the NamespacesExplorer tool to discover the namespaces within those assemblies. This helps you understand how the library is organized.

5. After identifying the relevant namespaces, use the NamespaceTypes tool to retrieve detailed information about the types within those namespaces in which you are interested in. This includes methods, properties, fields, events, and more.

6. Only use filtering when you're overwhelmed by the amount of data or when you know exactly what you're looking for.

7. If you need to find specific NuGet packages or explore their versions and dependencies, use the NuGetPackageSearch tool to search for packages by name or keywords.

8. When you need detailed information about a specific NuGet package, including its version history and dependencies, use the NuGetPackageVersions tool. This is particularly useful when you need to understand compatibility requirements o

…