DotNetMetadataMcpServer

Purpose

DotNetMetadataMcpServer is a Model Context Protocol (MCP) server designed to provide AI coding agents with detailed type information from .NET projects, helping AI agents understand and work with .NET codebases to generate more accurate, context-aware code suggestions.

Key Capabilities

• Assembly exploration: Retrieve the list of all assemblies referenced by a .NET project.
• Namespace exploration: Discover all namespaces in a specified assembly.
• Type exploration: Get detailed information about types in a specified namespace, including full type names and generic parameters, implemented interfaces, constructors with parameters, methods with return types and parameters, properties with types and accessors, fields with types and modifiers, and events with handler types.
• NuGet package search: Search for NuGet packages on nuget.org, with filtering and pagination support.
• NuGet package version information: Get the version history and dependency information for a specific NuGet package.
• Configurable assembly resolution: Resolve assemblies from build output, the NuGet global package cache (restore only, no build required), or automatically try both.
• Filtering and pagination: Apply wildcard filters to narrow down results, with built-in pagination for handling large result sets.

Usage

The server provides five main tools for AI agents to use:

• ReferencedAssembliesExplorer: Retrieve referenced assemblies from a .NET project.
• NamespacesExplorer: Retrieve namespaces from a specified assembly.
• NamespaceTypes: Retrieve types from a specified namespace.
• NuGetPackageSearch: Search for NuGet packages on nuget.org, with filtering and pagination support.
• NuGetPackageVersions: Retrieve the version history and dependency information for a specific NuGet package.

The following conditions must be met before use:

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

Installation methods:

• Native installation: Clone the repository, build the project (dotnet build -c Release), publish the project (dotnet publish -c Release -r <runtime-identifier> --self-contained false, replacing <runtime-identifier> with the target platform, such as win-x64, linux-x64, osx-x64).
• Docker: Pull the image from Docker Hub (docker pull vrogozhin/dotnet-types-explorer-mcp:latest) or build it locally (git clone https://github.com/V0v1kkk/DotNetMetadataMcpServer.git，cd DotNetMetadataMcpServer，docker build -t dotnet-types-explorer-mcp .), then run the container (docker run --rm -i -v /path/to/your/dotnet/projects:/workspace vrogozhin/dotnet-types-explorer-mcp:latest). Advantages of Docker deployment include no need to install the .NET SDK, environment isolation, consistent behavior across operating systems, inclusion of MSBuild and all required dependencies, and easy updates.

Configuration: Must be configured in the MCP settings file. Native configuration requires replacing the actual path to the published executable and the user's home directory; Docker configuration requires replacing the directory containing the .NET project. Support for appsettings.json Multiple NuGet package sources are configured in (name, URL (must end with /v3/index.json), whether enabled); all enabled sources are queried in parallel, and results are automatically deduplicated by package ID and version; if no sources are configured, only nuget.org is added. Source priority is determined by configuration order, duplicate packages defer to the first source, and metadata comes from the highest-priority source. It also supports configuring the assembly resolution mode (BuildOutput or NuGetCache). NuGetCache mode is suitable for scenarios where you mainly explore third-party package APIs without a full build, and the global packages folder path is automatically read from project.assets.json.

Applicable Scenarios

• When working with a .NET project that has NuGet package references and you need to write code using those packages, systematically explore the package APIs.
• When you are unfamiliar with a package's API or its documentation is limited.
• Exploring third-party libraries such as UI framework APIs.
• Recommended top-down approach: first retrieve the assemblies referenced by the project, then discover namespaces, and finally get type details. Focus on third-party libraries and NuGet packages, not BCL types (such as System.* or Microsoft.*). Use filtering only when the volume of data is too large or you clearly know what you are looking for.

Limitations

• Build requirements depend on the resolution mode: In BuildOutput mode (default), the project must be built before scanning; in NuGetCache mode, only dotnet restore, and the server resolves package assemblies directly from the NuGet global package cache. Project-specific types are available only when the project has been built.
• Inter-project references are not tracked: Only the specified project and its NuGet dependencies are inspected. To analyze multiple projects, each project must be scanned separately.
• Project output location: The server evaluates the project via MsBuildHelper and attempts to locate the output assembly, probing configurations in order: the requested configuration (default Debug), Release, and if still not found, falls back to checking Debug. The first output that exists wins. If no output is found, a reasonable default path is assumed and a warning is logged.

(Note: The official website materials also mention that future plans include adding NuGet integration to provide actual package version information, migrating to the official Model Context Protocol C# SDK, supporting multiple NuGet package sources (custom/private sources), adding dependency graph construction capabilities, and improving multi-project scenarios. The tool has been tested with the Roo Code Visual Studio extension.)