Produce binlog-mcp container images

[YuliiaKovalova]

Binlog MCP Server is a Model Context Protocol (MCP) server for analyzing MSBuild binary logs (.binlog files). It exposes ~28 tools that provide structured access to build errors, warnings, targets, tasks, properties, and project metadata so AI agents can triage CI failures and answer build-diagnostic questions.

• Source: https://github.com/dotnet-microsoft/ai-tools/tree/main/src/Microsoft.AITools.BinlogMcp (Microsoft-internal repo)
• Package: Microsoft.AITools.BinlogMcp published to the public dnceng/dotnet-tools Azure DevOps NuGet feed (https://dev.azure.com/dnceng/public/_artifacts/feed/dotnet-tools/NuGet/Microsoft.AITools.BinlogMcp). Installable today with:
  dotnet tool install --global Microsoft.AITools.BinlogMcp --prerelease --add-source https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json
• Issue tracking: https://github.com/dotnet/skills
• Catalog listing: [MCP Server Request] Binlog MCP Server microsoft/mcp#2728 (onboarding request), Add Binlog MCP Server to the catalog microsoft/mcp#2729 (catalog README entry, open for review)

Use Case

The binlog-mcp server is already integrated into .NET CI workflows in microsoft/testfx via the gh-aw MCP Gateway for AI-assisted build failure analysis. Currently, these workflows use a DumpBinlog workaround (a small C# shim that pre-dumps binlog tool output to JSON files) because the gh-aw MCP Gateway requires stdio MCP servers to be containerized.

Publishing mcr.microsoft.com/dotnet/binlog-mcp would:

• Eliminate the DumpBinlog shim
• Allow agents to query binlog-mcp interactively via MCP protocol (instead of reading pre-generated JSON)
• Enable external developers to use binlog-mcp in their own workflows without installing .NET tools locally on the runner

Support policy

Issues, discussions, and skill-integration tracking happen at https://github.com/dotnet/skills.

The container will follow the preview release cadence of Microsoft.AITools.BinlogMcp (currently 1.0.0-preview.26272.1). Once the package reaches stable (1.0.0), we will establish a standard support policy aligned with .NET tooling and a fixed release cadence.

Supported OSes

Azure Linux distroless (matching the dotnet/monitor / dotnet/yarp pattern for diagnostic / appliance tools). Open to additional platforms if you recommend them.

Repo name

binlog-mcp (produces mcr.microsoft.com/dotnet/binlog-mcp)

Desired tags

Follow the package version:

• 1.0.0-preview.26272.1 (specific version)
• 1.0-preview, 1-preview, preview (rolling preview tags)
• latest (once stable)

CODEOWNERS

@JanKrivanek (binlog-mcp owner)
@YuliiaKovalova (workflow integration owner)

Build / installation pattern

Unlike dotnet/monitor (which downloads tarballs from builds.dotnet.microsoft.com with SHA512 verification), Microsoft.AITools.BinlogMcp is a standard .NET global tool already published to a signed public NuGet feed. The simplest Dockerfile would just:

dockerfile FROM mcr.microsoft.com/dotnet/aspnet:9.0-azurelinux3.0-distroless RUN dotnet tool install --global Microsoft.AITools.BinlogMcp --prerelease \ --add-source https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json ENV PATH="$PATH:/root/.dotnet/tools" ENTRYPOINT ["binlog-mcp"]

If you prefer the builds.dotnet.microsoft.com tarball + SHA512 pattern for consistency with other dotnet-docker images, we can also set up a release endpoint — please let us know which pattern you'd like.

Offer to contribute

We are happy to author the Dockerfile templates (eng/dockerfile-templates/binlog-mcp/), the manifest.json entry, the mcr-tags-metadata template, and the README templates ourselves under your team's guidance, to minimize the work on the dotnet-docker team. Just let us know the conventions you'd like us to follow.

Additional context

This follows the precedent set by dotnet/monitor and dotnet/yarp — .NET tools packaged as containers for CI/workflow consumption. Existing teams/dotnet/dotnet.yml in microsoft/mcr already declares the dotnet/* namespace, so this should be additive.

[lbussell]

@YuliiaKovalova the tool is closed source? That's a non-starter IMO.

[YuliiaKovalova]

@YuliiaKovalova the tool is closed source? That's a non-starter IMO.

Could you tell me if there a separate process for the cases like this?

[richlander]

Here's a good pattern:

• Team-focused MCPs: Images should be defined at https://github.com/dotnet/dotnet-buildtools-prereqs-docker
• Public-focused MCPs: Images should be defined at https://github.com/dotnet/dotnet-docker
• For dotnet-docker, we should probably make a tools or mcp repo to separate these images. I vote for tools to avoid mcp showing up twice in the name and to allow for new standards to emerge.
• In terms of licensing, the licensing should be clear.

[YuliiaKovalova]

I see @richlander , thanks for the response !