Add binlog-mcp container image (team-focused MCP per dotnet-docker#7211 discussion)

[YuliiaKovalova]

Summary

Request to publish a containerized binlog MCP server image to mcr.microsoft.com/dotnet-buildtools/prereqs, for use by the .NET engineering team's AI-driven CI workflows (gh-aw / agentic build-failure analysis on dotnet/sdk, dotnet/msbuild, dotnet/runtime, microsoft/testfx, and similar repos).

This image hosts the Microsoft.AITools.BinlogMcp .NET tool (an MCP server that exposes ~29 binlog inspection/diagnosis tools — binlog_overview, binlog_errors, binlog_warnings, binlog_diagnose, binlog_search, binlog_task_details, etc.).

Why this repo (and not dotnet/dotnet-docker)

Per @richlander's guidance on dotnet/dotnet-docker#7211:

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

binlog-mcp is squarely team-focused — it is consumed by .NET-team CI workflows that analyze MSBuild binlogs produced by ./build.sh -bl. End users would not docker pull it for their own projects.

Why a container image is required

The downstream consumer is the gh-aw MCP Gateway, whose specification (v1.0.0, §3.2.1) mandates that stdio MCP servers be containerized:

"Stdio-based MCP servers MUST be containerized. The gateway SHALL NOT support direct command execution without containerization (stdio+command)."

So command: dnx ... Microsoft.AITools.BinlogMcp is rejected at gateway runtime; only a container: field is accepted. (We do already wire the tool via dnx in the in-process arcade-skills surface — see dotnet/arcade-skills#37 and #38, both merged — which validates the package as a working public artifact on the dnceng-public/dotnet-tools NuGet feed. That path does not require a container; only the gh-aw consumer does.)

Proposed image

Field	Value
Tag pattern	mcr.microsoft.com/dotnet-buildtools/prereqs:azurelinux-3.0-binlog-mcp-amd64 (and -arm64v8)
Tag pattern (alt, if a tool variant is preferred)	…:binlog-mcp-<package-version>-azurelinux-3.0-amd64
Base	mcr.microsoft.com/dotnet/runtime:9.0-azurelinux3.0 (distroless preferred if available)
Source location	src/azurelinux/3.0/binlog-mcp/amd64/Dockerfile (follows existing layout under src/<distro>/<version>/<variant>/<arch>/)
Package	Microsoft.AITools.BinlogMcp (preview today, GA shortly)
Feed	https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json (anonymous public)

Sample Dockerfile (~10 lines)

ARG REPO=mcr.microsoft.com/dotnet/runtime
FROM ${REPO}:9.0-azurelinux3.0

ENV DOTNET_TOOLS_FEED=https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json
ENV BINLOG_MCP_VERSION=1.0.0-preview.26275.1

RUN dotnet tool install --tool-path /usr/local/bin \
        Microsoft.AITools.BinlogMcp \
        --version ${BINLOG_MCP_VERSION} \
        --add-source ${DOTNET_TOOLS_FEED}

ENTRYPOINT ["binlog-mcp"]

Licensing & source ownership

• Microsoft.AITools.BinlogMcp is a Microsoft-owned tool, published under standard Microsoft proprietary terms via the public dnceng feed.
• Source lives in a Microsoft-internal repo (dotnet-microsoft/ai-tools). Per Rich's guidance, "the licensing should be clear" — happy to add a LICENSE reference / image readme spelling this out explicitly, similar to how other prereqs images document their bundled software.
• Anonymous, unauthenticated pull from dnceng-public/dotnet-tools is already validated (we ship the same package via this feed to arcade-skills today).

Consumers (planned)

Consumer	Status
dotnet/arcade-skills (in-process via dnx)	✅ Live (PRs #37/#38 merged)
microsoft/testfx gh-aw workflow	Today: DumpBinlog/ JSON-shim workaround. After this image: mcp-servers: { container: mcr.microsoft.com/dotnet-buildtools/prereqs:…-binlog-mcp-… }
dotnet/msbuild gh-aw workflow	Same as above
dotnet/sdk gh-aw workflow	Same as above
dotnet/runtime (or dotnet/dotnet) gh-aw workflow	Same as above

Eliminating DumpBinlog/ across these 4 repos is the immediate win.

Offer to contribute

Happy to author the Dockerfile, manifest.json entry, and any required tests/templates ourselves (modelled on existing src/azurelinux/3.0/<variant>/ directories) and submit as a PR. Just needs:

1. ✅/❌ from @dotnet/dotnet-docker-reviewers that this repo + variant naming is the right shape
2. Confirmation on preferred base image (azurelinux-distroless? runtime vs runtime-deps?)
3. Confirmation on multi-arch scope (amd64 only initially, or amd64 + arm64v8 from day one?)

CC: @richlander @lbussell (continuation of dotnet/dotnet-docker#7211), @JanKrivanek (binlog-mcp tool owner)

[mthalman]

This is largely a self-service repo so if there's a new Dockerfile you want, you're free to contribute it.

1. ✅/❌ from @dotnet/dotnet-docker-reviewers that this repo + variant naming is the right shape

Yes, this would be the correct repo for this use case.

2. Confirmation on preferred base image (azurelinux-distroless? runtime vs runtime-deps?)

If you can get it working with using runtime:9.0-azurelinux3.0-distroless, that would be preferred. Minimizes the attack surface. Otherwise, runtime:9.0-azurelinux3.0 is fine.

3. Confirmation on multi-arch scope (amd64 only initially, or amd64 + arm64v8 from day one?)

That depends on what your consumers needs are. At a minimum you'll want amd64. If this is meant to be used from dev machines, arm64 is a real possibility. If just for CI machines, then amd64 alone should be fine.

[YuliiaKovalova]

This is largely a self-service repo so if there's a new Dockerfile you want, you're free to contribute it.

1. ✅/❌ from @dotnet/dotnet-docker-reviewers that this repo + variant naming is the right shape

Yes, this would be the correct repo for this use case.

2. Confirmation on preferred base image (azurelinux-distroless? runtime vs runtime-deps?)

If you can get it working with using runtime:9.0-azurelinux3.0-distroless, that would be preferred. Minimizes the attack surface. Otherwise, runtime:9.0-azurelinux3.0 is fine.

3. Confirmation on multi-arch scope (amd64 only initially, or amd64 + arm64v8 from day one?)

That depends on what your consumers needs are. At a minimum you'll want amd64. If this is meant to be used from dev machines, arm64 is a real possibility. If just for CI machines, then amd64 alone should be fine.

thank you for giving the error - it's an issue on our side, I am fixing it, thanks for the quick feedback!