Introducing the ETW MCP: AI-assisted ETL trace analysis, headless and in your terminal

If you’ve ever opened an ETL trace with hundreds of data tables and wondered “where do I even start?” This post is for you. We’re releasing an early preview of the ETW MCP, a Model Context Protocol server that lets GitHub Copilot, or any MCP-aware AI assistant, read, query, and reason over Event Tracing for Windows (ETW) traces the same way an experienced engineer would. No UI required.

This is a companion to the WPA MCP (coming soon), which brings the same AI-assisted experience inside Windows Performance Analyzer. The ETW MCP server is the headless sibling, same data layer, no WPA needed, works anywhere you can run Copilot (or any MCP-aware AI assistant).

A quick acronym cheat sheet

Before we go further, a couple of acronyms you’ll see throughout:

ETW — Event Tracing for Windows, the kernel-level tracing infrastructure built into Windows

ETL — the binary trace file (.etl) that ETW emits

WPA — Windows Performance Analyzer, the UI for exploring ETL traces

WPR / XPerf — the recorders that produce ETL traces

MCP — Model Context Protocol, the open standard that lets AI assistants call into tools like ours. “MCP” is also commonly used to reference an MCP server.

What is server?

The ETW MCP is a local, STDIO-based MCP server that gives an AI assistant structured, read-only access to the data inside an ETL trace. Instead of streaming raw events at the model (which never ends well), it exposes a set of well-defined tools: process a trace, list available data sources, query CPU usage, filter by process or time range, aggregate, compare two traces, walk a critical path, and so on.

Under the hood it’s powered by the same TraceProcessor engine, documented in the .NET TraceProcessing guide on Microsoft Learn, that drives WPA and XPerf, so the data you get from the MCP is the data you’d see in WPA, just shaped for an LLM to consume.

The short version: the MCP does the heavy lifting on the trace, and the LLM does the reasoning on top of the results. That split is what keeps answers grounded in real ETW data instead of hallucinated event names.

Why we built it

Performance analysis on Windows is gated by expert knowledge. If you already know which WPA table answers your question, you move fast. If you don’t, you spend an hour learning the tool before you learn anything about your trace.

The ETW MCP is built to lower that floor. With it you can:

• Start an investigation with a plain-language question instead of a table name
• Triage a folder of traces headlessly and rank them before you open any of them
• Compare a baseline against a trial run and ask for the biggest deltas
• Get module!function-level evidence on hot stacks when symbols are configured

Automate repetitive investigations, the same prompt against many traces, in CI or in a script

And because it’s headless, it composes. You can run it from Windows Terminal, drop it into an agentic workflow, or call it from your own tooling alongside other MCP servers.

Who this is for

• Software engineers chasing a regression or a slow startup
• Driver developers and hardware engineers profiling power, stutter, or driver-side CPU cost
• Performance investigators who already live in WPA and want a faster on-ramp
• Teams running batch performance gates who want trace analysis built into their pipelines
• Anyone who has an .etl on their desk and is not sure where to begin

Capabilities at a glance

The current preview supports:

How to get it

The ETW MCP ships as a NuGet package, Microsoft.Windows.EventTracing.MCP, published to NuGet.org. A one-click listing on the GitHub MCP Registry is coming soon. Until then, the fastest way to get running is to add a small config block to your MCP client’s config file.

Configure it via your MCP config file

Add the ETW server to your client’s MCP config file (VS Code, GitHub Copilot CLI, or any MCP-aware client) and restart:

{
    "servers": {
        "ETW": {
            "type": "stdio",
            "command": "dnx",
            "args": [
                "Microsoft.Windows.EventTracing.MCP",
                "--yes"
            ]
        }
    }
}

NOTE: dnx requires the .NET 10 SDK. If your client launches from a folder whose global.json pins an older SDK, dnx won’t resolve. The easiest fix is to run the MCP from a folder that has no global.json (or one that allows .NET 10).

GitHub MCP Registry: coming soon

We’re onboarding the ETW MCP to the GitHub MCP Registry so installation becomes a single click from any MCP-aware client. A follow-up post will announce that listing. Until then, the config above is the supported path.

Usage examples

The fastest way to understand what the ETW MCP can do is to see real prompts and real output. Every result below was produced by GitHub Copilot calling ETW MCP tools against an actual .etl trace.

Example 1: “What’s in this trace?”

The fundamental workflow, process → explore → query, usually starts with one open-ended question.

“Open <trace>.etl and tell me what processes were running.”

Copilot processes the trace and comes back with the inventory: hundreds of processes, browser instances, service hosts, the platform’s anti-malware engine, shell processes, and the long tail. From there, every follow-up question is one prompt away.

Example 2: “What’s using the most CPU?”

“Show me the top CPU consumers in this trace.”

Total across all processes: ~20,000 samples / ~19.5 s of CPU time. No WPA tables to open, no columns to pick, just a question and an answer with the evidence behind it.

Example 3: A/B comparison, “What changed?”

This is one of the most powerful patterns the MCP enables. Process two traces, ask one question, get a delta.

“Process both <baseline>.etl and <trial>.etl and compare CPU usage for <process>.”

Insight: In the trial run, the target process uses ~57% more CPU time but the system has 36% fewer context switches, suggesting the change improves scheduling efficiency at the cost of higher per-process compute. That’s the kind of two-sentence finding you’d usually spend an hour producing in WPA.

Example 4: The showcase, Regions of Interest + Critical Path Analysis

This is where headless, AI-driven trace analysis really pulls ahead of point-and-click investigation. You can hand the MCP a Regions XML (named time intervals defined by ETW events) and ask it to walk a real end-to-end scenario, then drill into the slowest region with Critical Path Analysis, all in one prompt.

“Process <trace>.etl with <regions>.xml and show me the end-to-end timeline for <scenario>. Then run critical path analysis on the biggest bottleneck.”

Region timeline (end-to-end ~2,500 ms):

The MCP correctly identifies the hardware initialization region (1.28 s) as the single largest contributor and then runs CPA on it:

Key insight: the 1.28 s bottleneck is hardware latency, a device waking from a low-power state. CPA shows zero disk and zero network activity; the thread spends ~2 seconds blocked on device drivers, not running code. That’s not a software optimization opportunity, it’s a hardware wake-up cost. The actual work in the scenario takes only about a second once the hardware is ready.

This is the workflow that used to take a senior performance engineer a half-day of clicking through WPA. With ETW MCP, it’s one prompt.

More patterns

A few other prompts worth keeping in your pocket:

Context switch reasons: “Show me the context switch wait reasons for <process>.” Surfaces WrQueue, WrDispatchInt, WrPreempted distribution and what they imply.

Process lifecycle: “Show me the process lifecycle timeline for <process>.” Start time, end time, and notes on short-lived launchers vs. long-running workers.

• Time-window focus: “Focus on <t0> to <t1> and tell me what dominated CPU and what threads were waiting on.”

Batch ranking: “Open every .etl in <folder>, find <region> in each, and rank them by duration.” Turn a folder of traces into a sortable table without opening any of them.

Customer Testing

We partnered with a small set of customers across Europe, the U.S., and Australia to evaluate boot performance using ETW-based analysis. Those engagements identified practical configuration and application adjustments that helped customers achieve measurable improvements in startup and post-login performance. The work also gave IT teams clearer, evidence-based guidance for prioritizing the changes that deliver the biggest user impact, that traditionally required an engineer onsite or a support ticket.

ETW MCP vs. WPA MCP: which one do I use?

Both use the same data layer, and the analysis they produce is largely the same. The difference is where they run:

• ETW MCP is headless. No WPA window required. Best for terminal-driven workflows, batch analysis, CI pipelines, IDEs like VSCode and anywhere you want to script trace analysis.
• WPA MCP lives inside WPA and reasons over the tables processed. Best when you want the AI’s findings linked to graphs and tables you can see in the UI.

Use the ETW MCP when you’re investigating. Use the WPA MCP when you want to dig into the results with an AI companion. Use both when you want to do one and then the other.

A note on LLM-generated analysis

The MCP acts as a context and data-retrieval layer, grounding responses in real ETW data, but the reasoning on top of that data still comes from a large language model. Responses can vary between runs and can be incomplete or wrong. Treat Copilot’s output as an assistant-generated starting point, not a final diagnosis. Validate against the underlying trace, the tables, the time ranges, the stacks, and ask follow-up questions when the evidence isn’t clean.

The good news: because every claim the model makes is backed by a tool call against the trace, “show me the evidence” is always a valid follow-up prompt.

Found a bug? Have feedback?

This is an early external release and we want to hear from you. File issues, bugs, and feature requests against the microsoft/eventtracing-processing repo on GitHub, the same place that tracks the Microsoft.Windows.EventTracing.* NuGet packages the MCP is built on.

We’re especially interested in:

• Prompts that worked unexpectedly well (or unexpectedly badly)
• Scenarios you wish the MCP understood out of the box
• Trace sizes and shapes that stress the MCP server
• Places where the MCP should expose more supporting evidence

More capabilities, more analysis types, and tighter integrations with the rest of the Performance Toolkit are landing in the coming releases.

Closing

The ETW MCP exists to let you spend less time hunting through trace data and more time understanding what the trace is telling you. Whether you’re a software developer, a hardware engineer, a game developer, or just someone who inherited a slow PC and an .etl file, point at it and start asking questions.

Happy tracing.