{"id":4478,"date":"2026-06-30T17:12:10","date_gmt":"2026-06-30T17:12:10","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/06\/30\/mcp-beyond-the-chat-window-build-diagnostics-in-ci\/"},"modified":"2026-06-30T17:12:10","modified_gmt":"2026-06-30T17:12:10","slug":"mcp-beyond-the-chat-window-build-diagnostics-in-ci","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/06\/30\/mcp-beyond-the-chat-window-build-diagnostics-in-ci\/","title":{"rendered":"MCP Beyond the Chat Window: Build Diagnostics in CI"},"content":{"rendered":"<p>In a <a href=\"https:\/\/devblogs.microsoft.com\/dotnet\/msbuild-binlog-mcp-server\/\">previous post<\/a><br \/>\nwe introduced the<br \/>\n<strong>Microsoft Binlog MCP Server<\/strong> and showed how an AI assistant can investigate<br \/>\nMSBuild binary logs through natural language. Picture the payoff in CI: a pull<br \/>\nrequest build fails, and instead of a human downloading the binlog and scrolling<br \/>\nthe Structured Log Viewer, an agent opens it, pinpoints the failing target and<br \/>\ntask, and posts the root cause straight back to the PR.<\/p>\n<p>That first post was a great start, but it told only part of the story. It<br \/>\nhighlighted 15 tools \u2013 the server\u2019s surface has since grown well beyond that \u2013<br \/>\nand it focused on the interactive, sit-at-your-keyboard experience. In practice,<br \/>\nthe same <a href=\"https:\/\/modelcontextprotocol.io\/\">Model Context Protocol<\/a><br \/>\n(MCP) tools are doing real work <em>unattended<\/em>, inside a continuous integration<br \/>\npipeline on GitHub Actions.<\/p>\n<p>This post fills in the rest. We\u2019ll:<\/p>\n<ul>\n<li>Watch those tools run unattended inside a <strong>GitHub Actions<\/strong> workflow on the<br \/>\npublic <a href=\"https:\/\/github.com\/microsoft\/testfx\"><code>microsoft\/testfx<\/code><\/a> repository \u2013 a<br \/>\nreal PR build failure, analyzed and explained automatically<\/li>\n<li>Walk through the <strong>23 Binlog MCP tools the first post never mentioned<\/strong><\/li>\n<li>Back the efficiency claims with <strong>evaluation data<\/strong> instead of vibes<\/li>\n<\/ul>\n<p>If you lead a team, here is the outcome that matters: red builds get a<br \/>\nplain-language root cause posted to the PR automatically, so engineers stop<br \/>\nlosing time downloading logs and decoding MSBuild output. That means faster PR<br \/>\nturnaround, fewer interruptions for your build experts, and junior developers<br \/>\nwho can unblock themselves instead of waiting for someone who \u201cknows the build.\u201d<br \/>\nAnd because it runs as advisory automation on infrastructure you already have,<br \/>\nyour team can adopt it without changing how anyone works.<\/p>\n<h2>MCP in a GitHub Actions Workflow<\/h2>\n<p>Start with the payoff. The<br \/>\n<code>microsoft\/testfx<\/code> repository runs MCP-powered agents directly in CI using<br \/>\n<a href=\"https:\/\/github.com\/githubnext\/gh-aw\">GitHub Agentic Workflows<\/a> (<code>gh aw<\/code>), where<br \/>\neach workflow is authored in Markdown and compiled to a <code>.lock.yml<\/code> file. The<br \/>\nworkflows are public, so you can read the exact source:<br \/>\n<a href=\"https:\/\/github.com\/microsoft\/testfx\/blob\/main\/.github\/workflows\/build-failure-analysis.md\"><code>build-failure-analysis.md<\/code><\/a>,<br \/>\nits on-demand companion<br \/>\n<a href=\"https:\/\/github.com\/microsoft\/testfx\/blob\/main\/.github\/workflows\/build-failure-analysis-command.md\"><code>build-failure-analysis-command.md<\/code><\/a>,<br \/>\nand the<br \/>\n<a href=\"https:\/\/github.com\/microsoft\/testfx\/blob\/main\/.github\/agents\/build-failure-analyst.agent.md\"><code>build-failure-analyst<\/code> agent<\/a><br \/>\nthey delegate to. GitHub Agentic Workflows are still evolving, so treat these as<br \/>\na reference implementation to copy from rather than a turnkey feature every<br \/>\nrepository has today.<\/p>\n<h3>Build failure analysis, on every PR<\/h3>\n<p>The <code>build-failure-analysis<\/code> workflow runs the repository build on every pull<br \/>\nrequest, and <strong>only when the build fails<\/strong> wakes up an agent that queries the<br \/>\nbinlog live through the Binlog MCP Server. The MCP server runs as a container,<br \/>\nwith the binlog mounted read-only:<\/p>\n<pre><code class=\"language-yaml\">mcp-servers:\n  binlog-mcp:\n    container: \"mcr.microsoft.com\/dotnet-buildtools\/prereqs:azurelinux-3.0-binlog-mcp-amd64\"\n    mounts:\n      - \"\/tmp\/build.binlog:\/data\/build.binlog:ro\"\n    allowed: [\"*\"]<\/code><\/pre>\n<p>The workflow spells out its own flow: it runs<br \/>\n<code>.\/build.sh --binaryLog<\/code>, and on failure \u201cdelegates to the<br \/>\n<code>build-failure-analyst<\/code> agent (which queries the binlog live via the<br \/>\ncontainerized <code>binlog-mcp<\/code> MCP server) to identify root causes, post a PR<br \/>\ncomment summarizing them, and attach inline <code>suggestion<\/code> blocks tied to the<br \/>\ndiff.\u201d It is explicitly <strong>advisory, not gating<\/strong>: the agent\u2019s comment never<br \/>\ndecides whether the PR passes. The repository\u2019s normal required build workflow<br \/>\nstays the merge gate; this MCP-powered workflow only analyzes failures and<br \/>\ncomments on the PR.<\/p>\n<p>A companion <code>build-failure-analysis-command<\/code> workflow lets a maintainer rerun<br \/>\nthe same analysis on demand by commenting <code>\/analyze-build-failure<\/code>.<\/p>\n<p>Concretely, a single failed-build run might have the agent call<br \/>\n<code>binlog_overview<\/code> to see the build failed, <code>binlog_errors<\/code> to get the failing<br \/>\nerror with its target and task context, and <code>binlog_target_reasons<\/code> or<br \/>\n<code>binlog_task_details<\/code> to explain why that step ran the way it did \u2013 then<br \/>\nsummarize the root cause in a PR comment with an inline suggestion. That whole<br \/>\nchain happens without anyone opening a log viewer.<\/p>\n<p>Here is an actual comment the workflow left on a <code>microsoft\/testfx<\/code> pull<br \/>\nrequest. This is a real CI failure \u2013 not a hand-picked toy example, but a<br \/>\nformatting (<code>IDE0055<\/code>) failure in a full multi-project build \u2013 showing the same<br \/>\ntools at work in a real repository, posting the root<br \/>\ncause, the exact file and line, a ready-to-apply fix, and a build overview<br \/>\npulled straight from the binlog:<\/p>\n<p><img data-opt-id=385051921  fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2026\/06\/demo-real-pr-comment.webp\" alt=\"Real Build Failure Analysis comment posted by the workflow on a microsoft\/testfx pull request\" \/><\/p>\n<p>Look at what is in that comment: the MSBuild version, the 46 projects that built,<br \/>\nthe five errors, the four failing projects, and the precise <code>IDE0055<\/code> location<br \/>\ndown to the column. All of it came from the agent querying the binlog live<br \/>\nthrough the containerized Binlog MCP Server \u2013 nobody downloaded a log or opened<br \/>\na viewer. When the binlog can\u2019t be parsed, the same comment degrades gracefully<br \/>\nto a short status note with a link back to the run, so you always know what<br \/>\nhappened.<\/p>\n<h2>See the Tools in Action<\/h2>\n<p>You just saw those tools deliver a verdict inside CI. Now let\u2019s slow down and<br \/>\nlook at what a few of them actually hand back, up close. Everything below is<br \/>\n<strong>unedited output<\/strong>, captured against a tiny console app built with<br \/>\n<code>dotnet build \/bl<\/code>.<\/p>\n<h3>Diagnosing a failing build<\/h3>\n<p>The app has a one-character typo \u2013 <code>Consolee.WriteLine<\/code> instead of<br \/>\n<code>Console.WriteLine<\/code> \u2013 so <code>dotnet build<\/code> fails with <code>CS0103<\/code>:<\/p>\n<p><img data-opt-id=1753484765  fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2026\/06\/demo-real-build-failure-scaled.webp\" alt=\"Real dotnet build failure showing CS0103: the name 'Consolee' does not exist in the current context\" \/><\/p>\n<p>Because we built with <code>\/bl<\/code>, that same failure also produced a binlog. Point an<br \/>\nassistant at it and it walks the path a human would, only faster:<br \/>\n<code>binlog_overview<\/code> to confirm the build failed and where, then <code>binlog_errors<\/code><br \/>\nfor the exact file, line, target, and task. Here is a real session against the<br \/>\nlive server:<\/p>\n<p><img data-opt-id=1657485165  data-opt-src=\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2026\/06\/demo-real-mcp-output-scaled.webp\"  decoding=\"async\" src=\"data:image/svg+xml,%3Csvg%20viewBox%3D%220%200%20100%%20100%%22%20width%3D%22100%%22%20height%3D%22100%%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Crect%20width%3D%22100%%22%20height%3D%22100%%22%20fill%3D%22transparent%22%2F%3E%3C%2Fsvg%3E\" alt=\"Real Binlog MCP server session: binlog_overview and binlog_errors tool calls against the failing build's binlog\" \/><\/p>\n<p>That structured payload \u2013 <code>code<\/code>, <code>file<\/code>, <code>line<\/code>, <code>targetName<\/code>, <code>taskName<\/code> \u2013 is<br \/>\nexactly what lets an assistant explain the failure and propose a fix without<br \/>\never scrolling a raw log.<\/p>\n<h3>Letting the server take the first pass<\/h3>\n<p>You don\u2019t have to drive the tools one at a time, either. <code>binlog_diagnose<\/code><br \/>\ndoes the first pass for you \u2013 it reads the binlog, groups the errors, picks<br \/>\nout the root cause, and even suggests a fix:<\/p>\n<p><img data-opt-id=468944515  data-opt-src=\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2026\/06\/demo-real-diagnose-scaled.webp\"  decoding=\"async\" src=\"data:image/svg+xml,%3Csvg%20viewBox%3D%220%200%20100%%20100%%22%20width%3D%22100%%22%20height%3D%22100%%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Crect%20width%3D%22100%%22%20height%3D%22100%%22%20fill%3D%22transparent%22%2F%3E%3C%2Fsvg%3E\" alt=\"Real binlog_diagnose output: CS0103 root cause, a suggested fix, and error categories\" \/><\/p>\n<p>For a one-character typo that is overkill. But on a real CI failure with a<br \/>\nwall of cascading errors, having the server name the <em>root cause<\/em> up front \u2013<br \/>\nand point you at the next tool to run \u2013 is the difference between a two-minute<br \/>\nfix and a half-hour log dive.<\/p>\n<h3>Comparing two builds<\/h3>\n<p>Now take two successful builds of the same project that differ only in a<br \/>\nproject setting and an added package, and ask <code>binlog_compare<\/code> to diff them.<br \/>\nThis is the unedited output:<\/p>\n<p><img data-opt-id=1768323685  data-opt-src=\"https:\/\/devblogs.microsoft.com\/dotnet\/wp-content\/uploads\/sites\/10\/2026\/06\/demo-real-compare-scaled.webp\"  decoding=\"async\" src=\"data:image/svg+xml,%3Csvg%20viewBox%3D%220%200%20100%%20100%%22%20width%3D%22100%%22%20height%3D%22100%%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Crect%20width%3D%22100%%22%20height%3D%22100%%22%20fill%3D%22transparent%22%2F%3E%3C%2Fsvg%3E\" alt=\"Real binlog_compare output diffing two builds: LangVersion and a new Newtonsoft.Json reference\" \/><\/p>\n<p>The two changes that matter jump right out: <code>LangVersion<\/code> went from <code>14.0<\/code> to<br \/>\n<code>preview<\/code>, and a <code>Newtonsoft.Json<\/code> 13.0.3 reference appeared. The rest \u2013 the<br \/>\ntelemetry session IDs and the restore session GUID \u2013 is expected per-run<br \/>\nnoise. Surfacing everything in one structured call is exactly what lets an<br \/>\nassistant separate the signal from it, instead of opening two logs and<br \/>\ncomparing them by hand. (<code>binlog_compare<\/code> was one of the original 15 tools from<br \/>\nthe first post, so you won\u2019t see it in the catalog tables below \u2013 those list<br \/>\nonly the 23 the first post didn\u2019t cover.)<\/p>\n<h2>The Tools the First Post Didn\u2019t Cover<\/h2>\n<p>You have now seen a handful of these tools at work, both interactively and in<br \/>\nCI. Here is the full set the first post skipped. The first post highlighted 15<br \/>\ntools for interactive investigation. As of this<br \/>\nwriting the server source tree exposes *<em>38 `binlog_<\/em><code>tools** in total - so the tables below list the **23 tools the first post didn't mention**, grouped by what you use them for. (The exact set evolves, and the published container image can lag the source tree, so treat this as the current snapshot rather than a frozen contract -<\/code>binlog_capabilities` always reports what your installed server<br \/>\nactually supports.)<\/p>\n<h3>Targets and tasks<\/h3>\n<p>When a build does something you didn\u2019t expect \u2013 a target fires that shouldn\u2019t,<br \/>\nor one you need gets skipped \u2013 these walk the execution tree for you, no<br \/>\n<code>\/v:diag<\/code> log-diving required.<\/p>\n<table>\n<thead>\n<tr>\n<th>Tool<\/th>\n<th>What it does<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><code>binlog_project_targets<\/code><\/td>\n<td>List the targets executed in a specific project<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_search_targets<\/code><\/td>\n<td>Search targets by name across all projects<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_target_reasons<\/code><\/td>\n<td>Explain why a target ran or was skipped \u2013 the usual answer to \u201cwhy does this rebuild every time?\u201d<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_tasks_in_target<\/code><\/td>\n<td>List the tasks within a target<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_task_details<\/code><\/td>\n<td>Details for a specific task execution<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_explore_node<\/code><\/td>\n<td>Explore an arbitrary node in the build tree<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_diagnose<\/code><\/td>\n<td>Automated, high-level build diagnosis \u2013 a good first stop that points at the likely culprit<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Properties and evaluation<\/h3>\n<p>MSBuild evaluation is where most \u201cworks on my machine\u201d mysteries hide. These<br \/>\nexpose the exact properties \u2013 and global properties \u2013 each project was<br \/>\nevaluated with, so you can compare a CI agent against your laptop.<\/p>\n<table>\n<thead>\n<tr>\n<th>Tool<\/th>\n<th>What it does<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><code>binlog_compare_property<\/code><\/td>\n<td>Compare a single property across two binlogs \u2013 pinpoint the one setting that drifted<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_preprocess<\/code><\/td>\n<td>Preprocessed project view (the <code>msbuild \/pp<\/code> equivalent) \u2013 the fully expanded project after every import<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_evaluations<\/code><\/td>\n<td>List project evaluations<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_evaluation_properties<\/code><\/td>\n<td>Properties for a specific evaluation<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_evaluation_global_properties<\/code><\/td>\n<td>Global properties for a specific evaluation<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Performance analysis<\/h3>\n<p>Reach for these when the build <em>works<\/em> but is slow. They turn a binlog into a<br \/>\nranked list of where the time actually went.<\/p>\n<table>\n<thead>\n<tr>\n<th>Tool<\/th>\n<th>What it does<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><code>binlog_expensive_analyzers<\/code><\/td>\n<td>Slowest Roslyn analyzers and source generators \u2013 the usual suspects behind slow compiles<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_analyzer_summary<\/code><\/td>\n<td>Analyzer execution summary<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_project_target_times<\/code><\/td>\n<td>Target-level timing breakdown for a specific project<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_incremental_analysis<\/code><\/td>\n<td>Which targets were skipped vs rebuilt \u2013 how you catch a broken incremental build<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Graph, dependencies, and toolchain<\/h3>\n<p>These answer the \u201chow is everything wired together?\u201d questions \u2013 build order,<br \/>\nrestore, and the assemblies that actually made it onto the compiler command<br \/>\nline.<\/p>\n<table>\n<thead>\n<tr>\n<th>Tool<\/th>\n<th>What it does<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><code>binlog_build_graph<\/code><\/td>\n<td>Project dependency graph and critical path \u2013 what\u2019s really gating your build time<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_target_graph<\/code><\/td>\n<td>Executed-target timeline for one evaluation<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_nuget<\/code><\/td>\n<td>Restore info: versions, sources, duration<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_assembly_conflicts<\/code><\/td>\n<td>Assembly version conflict \/ RAR analysis<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_compiler<\/code><\/td>\n<td>Compiler command-line invocations<\/td>\n<\/tr>\n<tr>\n<td><code>binlog_double_writes<\/code><\/td>\n<td>Files written by more than one task or target \u2013 a classic source of flaky, nondeterministic builds<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Contract<\/h3>\n<p>One housekeeping tool that keeps the others honest across server versions.<\/p>\n<table>\n<thead>\n<tr>\n<th>Tool<\/th>\n<th>What it does<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><code>binlog_capabilities<\/code><\/td>\n<td>Report the server\u2019s contract version and tool envelope<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>That is a lot of heavy diagnostic lifting the first post never touched \u2013 whole<br \/>\nnew capabilities like automated diagnosis (<code>binlog_diagnose<\/code>), per-evaluation<br \/>\ninspection for multi-targeted builds, dependency and critical-path graphs,<br \/>\nNuGet restore analysis, assembly-conflict detection, and incremental-build<br \/>\nintrospection.<\/p>\n\n<div class=\"alert alert-success\">\n<p class=\"alert-divider\"><i class=\"fabric-icon fabric-icon--Lightbulb\"><\/i><strong>Tip<\/strong><\/p>\n<p>To generate a binary log, add <code>\/bl<\/code> to any<br \/>\n<code>dotnet build<\/code>, <code>dotnet test<\/code>, or <code>dotnet pack<\/code> command \u2013 for example<br \/>\n<code>dotnet build \/bl<\/code>.<\/p><\/div>\n<h2>Does It Actually Help? The Evaluation Data<\/h2>\n<p>Adding tools to an AI assistant is only worthwhile if it makes the assistant<br \/>\n<em>better<\/em> and <em>cheaper<\/em>, not just busier. To measure that, the team runs a public<br \/>\nevaluation harness that scores different configurations on the same set of<br \/>\nreal-world MSBuild diagnosis scenarios \u2013 identifying a build failure, tracing a<br \/>\nproperty, doing a full autonomous root-cause investigation \u2013 on a 0-5 quality<br \/>\nscale, while recording wall-clock time, tool calls, and token usage. The results<br \/>\nare published at the<br \/>\n<a href=\"https:\/\/jankrivanek.github.io\/binlog-evals-results\/\">binlog evals dashboard<\/a>.<\/p>\n<p>Across the 102 runs available at the time of writing, the picture is consistent.<br \/>\nThe dashboard includes several experimental and alternative configurations; the<br \/>\ntable below selects the no-tools baseline plus the two configurations this post<br \/>\nis about. Input tokens roughly track compute cost, so on that column lower is<br \/>\ncheaper. Results vary by run and scenario, so check the dashboard for the full<br \/>\ncomparison.<\/p>\n<table>\n<thead>\n<tr>\n<th>Configuration<\/th>\n<th>Avg score (0-5)<\/th>\n<th>Avg wall time<\/th>\n<th>Avg input tokens<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><code>plain<\/code> (no tools)<\/td>\n<td>3.25<\/td>\n<td>349.8 s<\/td>\n<td>1,268,501<\/td>\n<\/tr>\n<tr>\n<td><code>binlog-mcp<\/code> (Binlog MCP Server)<\/td>\n<td>3.68<\/td>\n<td>196.1 s<\/td>\n<td>1,141,426<\/td>\n<\/tr>\n<tr>\n<td><code>skill-mcp<\/code> (skills + MCP)<\/td>\n<td>3.60<\/td>\n<td>166.7 s<\/td>\n<td>879,205<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>In other words, against the no-tools baseline the Binlog MCP Server raised the<br \/>\naverage score from <strong>3.25 to 3.68<\/strong> while finishing roughly <strong>44% faster<\/strong><br \/>\n(196 s vs 350 s). The skills-plus-MCP configuration was the fastest and cheapest<br \/>\nof the three \u2013 about <strong>52% faster<\/strong> and roughly <strong>30% fewer input tokens<\/strong> than<br \/>\nbaseline \u2013 while scoring <strong>3.60<\/strong>, just below Binlog MCP alone but still well<br \/>\nabove the no-tools baseline. One likely reason both tool-based configurations<br \/>\ncome out ahead is that purpose-built tools let the model query structured binlog<br \/>\ndata directly instead of reconstructing it from raw text logs, so it spends<br \/>\nfewer turns and tokens to reach the same answer.<\/p>\n\n<div class=\"alert alert-primary\">\n<p class=\"alert-divider\"><i class=\"fabric-icon fabric-icon--Info\"><\/i><strong>About the numbers<\/strong><\/p>\n<p>These figures come from a preview<br \/>\nevaluation harness over a small, evolving set of scenarios; the dashboard flags<br \/>\nruns with incomplete data. Treat them as directional evidence of the efficiency<br \/>\ntrend, not as a benchmark guarantee. Re-check the live dashboard for the latest<br \/>\nresults.<\/p><\/div>\n<h2>Try It Yourself<\/h2>\n<p>Everything above is built on the same foundation you can adopt today:<\/p>\n<ol>\n<li>Install the <code>dotnet-msbuild<\/code> plugin from the<br \/>\n<a href=\"https:\/\/github.com\/dotnet\/skills\">dotnet\/skills<\/a> marketplace in Visual<br \/>\nStudio, VS Code, or the Copilot CLI. (That is the build-diagnostics plugin<br \/>\nthis post uses; the marketplace has others for different jobs.)<\/li>\n<li>Build with <code>\/bl<\/code> to capture a binlog, then ask your assistant to investigate<br \/>\nit \u2013 now with the full toolset, not just the original 15.<\/li>\n<li>To take it into CI, follow the <code>microsoft\/testfx<\/code> pattern: wire the<br \/>\ncontainerized Binlog MCP Server into a GitHub Agentic Workflow so build<br \/>\nfailures get analyzed automatically. (These agentic workflows are still<br \/>\nevolving; the testfx workflows are the public reference to copy from.)<\/li>\n<\/ol>\n<p>The Model Context Protocol turns out to be far more than a chat convenience. It<br \/>\nis a portable contract that lets the same diagnostic tools<br \/>\nrun wherever your code does \u2013 in your editor, in your terminal, and in your<br \/>\npipelines. We\u2019d love your feedback; file issues in the<br \/>\n<a href=\"https:\/\/github.com\/dotnet\/skills\/issues\">dotnet\/skills<\/a> repository.<\/p>\n<p>The post <a href=\"https:\/\/devblogs.microsoft.com\/dotnet\/mcp-build-diagnostics-workflows\/\">MCP Beyond the Chat Window: Build Diagnostics in CI<\/a> appeared first on <a href=\"https:\/\/devblogs.microsoft.com\/dotnet\">.NET Blog<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"<p>In a previous post we introduced the Microsoft Binlog MCP Server and showed how an AI assistant can investigate MSBuild [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4479,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[7],"tags":[],"class_list":["post-4478","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dotnet"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4478","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=4478"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4478\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media\/4479"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=4478"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=4478"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=4478"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}