Repository navigation
Releases
Debugging via MCP 0.7.0
0.7.0 — Watch list, long values and concurrency (preview)
Added
- Watch list:
watch_add,watch_list,watch_remove. The agent follows expressions across stops: every answer that reports
a stop (debug_wait, the steps,debug_status...) carries their values and whether each changed since the previous stop. At most
10 entries; values are masked and shortened like those ofvars. The list belongs to the agent's connection, lives in memory and is
dropped when the agent lets go or disconnects; your Watch windows and your solution are not touched. These are Read tools: with Read
set to Ask, reading the values at a stop asks nothing more. Needs the extension and thedebugviamcpserver of the same
release (protocol 2.9); an older extension answers that it must be updated. evalwithoffsetandlengthreads a long value in pages (up to 16384 characters per page, up to 2,000,000 per value). The
value is read once, masked as a whole before it is cut (a secret split by a page boundary stays hidden) and the next pages come
from that saved read. Not allowed together withallowSideEffects.- A concurrency lab for testing (
samples/ConcurrencyLab: a data race, a deadlock and a crash on a worker thread) with end-to-end
scenarios intests/e2e/concurrency-lab.cs.
Fixed
- A stop with several threads no longer fails as a whole when a frame has no source line.
threadsand the call stack answered
E_FAILand an empty snapshot; such frames are now listed without a file and line. eval,varsand drill-down on a thread that is blocked (waiting on a lock) answereval_failedwith a pointer tostack
instead of an unclear error.- The failure text of a paged read is masked and cut like every other value.
debug_waitafter a stop no longer asks again for consent just to read the watch values when Read is Ask.
Changed
- Reading a long value page by page and keeping a watch's prepared expression are faster; a connection that never added a watch no
longer switches to Visual Studio's UI thread when it is released.
Debugging via MCP 0.6.0
0.6.0 — Settings on Visual Studio 2022 (preview)
Added
- An Options page for Visual Studio 2022 (17.14). Visual Studio 2022 does not show the extension's page in All Settings, so
there was no way to change the permission tiers, the consent timeout, masking, the limits or the log level there. They are now in
Tools → Options → Debugging via MCP → General and take effect when you press OK. In Visual Studio 2026 the settings stay in
Tools → Options → All Settings → Debugging → Debugging via MCP, and the new page is not used there.
Fixed
- Visual Studio 2022: calls failed with
busyfor a dialog that was not there. The extension read Visual Studio's main window once
and kept it; when that window was gone, every call that moves the program reported a dialog. The window is now taken from Visual
Studio's own automation object and looked up again when it is no longer valid. exception_setwith an empty name innamesis refused before anything is written.- When
exception_setstopped halfway and putting back what it had written failed too, that change was forgotten. It now stays
recorded, soexception_resetand the release when the agent disconnects can still undo it.
Changed
- The file attached to a GitHub Release carries the version:
DebugViaMcp-<version>.vsix.
Debugging via MCP 0.5.0
0.5.0 — Exception settings (preview)
Added
-
Exception settings:
exception_list,exception_set,exception_reset. The agent can see which exceptions Visual Studio stops
on when they are thrown (Debug → Windows → Exception Settings) and turn Break When Thrown on or off for named exceptions,
so a debugging session stops where the exception is thrown instead of where it is caught. A call checks every name first and
changes nothing when one is unknown (it offers close names).exception_resetputs back only what the agent changed, and Visual Studio puts it back by itself when the agent lets go or disconnects. These are
Control tools: they ask like the other Control tools when you set that in Options. Needs the extension and thedebugviamcp
server of the same release (protocol 2.8); an older extension answers that it must be updated. -
Mask sensitive values (Tools → Options → All Settings → Debugging → Debugging via MCP, on by default): values that look
like secrets (strings under names such aspasswordortoken, JWTs,Bearertokens, PEM private keys, GitHub and AWS keys,
Password=in connection strings, passwords in URLs) are replaced by[masked]before they reach the agent, invars,eval,
the arguments of a break, exception texts andoutput_read. The result carriesmasked: true. Turning it off asks you to confirm.
A tracepoint that would print such a value is refused while it is on. A heuristic against accidental leaks, not a security boundary (seedocs/security.md). -
varsopens several levels in one call.depth(1-4, default 1) puts the members of each object underchildren;
expandnames more paths to open in the same call (listed underexpanded). Each object shows at most 20 members
(childrenTruncatedsays there are more) and the answer stays small: what does not fit stays closed, andhasChildren
still says it can be opened withpath. -
debug_statuswithdetail. Stopped at a break,detail: truealso returns the top 10 frames of the Call Stack, the
first 30 Locals and the exception (when the break is about one): where you are and what is going on in one call. A part
Visual Studio cannot read is named undernotesand the rest still comes. -
process_listlists your processes thatdebug_attachcan attach to (pid and name), with an optionalfilteron part of
the name, so the agent can pick a pid when several processes share a name. -
symbol_statussays why a breakpoint may not bind: the debugger options that decide whether symbols load (Require source
files to exactly match, Just My Code, Source Server, Suppress JIT optimization), the breakpoints that are not bound, and what
can be behind it. It does not say which modules have symbols loaded; Visual Studio's automation does not offer the symbol path. -
bp_setwithtemporary. A one-shot breakpoint: it removes itself after the break it causes, andbp_listshows it
(temporary: true) until then. A breakpoint that already existed is left as it is, and a tracepoint cannot be temporary. -
A dialog Visual Studio waits on is named, not waited for. When a modal dialog is open (for example the Hot Reload
"changes not supported" question),debug_statusreturns its title underdialog, and every call that would move the
program, build or change a value fails at once withbusyand says which dialog to answer. Reads keep working. The check
asks Windows about the main window only, so it costs no pause on Visual Studio's UI thread, and each held-back call is
logged with its call id.
Changed
debug_startbuilds first. A failed build comes back to the agent (read the diagnostics witherrors_list) instead of
leaving Visual Studio's "run the last successful build?" dialog open on screen.- The Output panes are named by what they hold: Debugging via MCP Log (the technical log, formerly Debugging via MCP)
and Debugging via MCP Audit (what the agent did, formerly Debugging via MCP Activity). The menu entry Show Activity
is now Show Audit. The agent still cannot read either pane.
Debugging via MCP 0.4.1
0.4.1 — First pipeline build (preview)
Changed
- No change in behaviour. This is the first version built and tagged by the release pipeline: the VSIX on the Marketplace is
the one attached to the GitHub Release, with the same SHA-256. - The Marketplace page's release-notes link, tags and author name are fixed in the package.
- The NuGet tool package is gone; the MCP server travels inside the extension only.
Debugging via MCP 0.4.0
0.4.0 — Several Visual Studios (preview)
Added
- Several Visual Studios, one agent each. The MCP server picks the Visual Studio whose solution folder relates to the
folder the agent runs in (the agent in the repository root, the solution insrc\, works too);vs_selectstill
overrides. - An agent whose folder is not the solution's must be approved once by the Visual Studio owner (info bar), per
connection. - One agent at a time per Visual Studio: the first state-changing command (breakpoint, build, start, attach, ...) takes
it, a second agent getsin_use.vs_release, a closed connection or Disconnect AI frees it. The status bar and
vs_instancesshow who holds it. - The extension carries the MCP server. When Visual Studio starts it copies the server to
%LOCALAPPDATA%\DebugViaMcp\bin\<build>and writes a launcher,%LOCALAPPDATA%\DebugViaMcp\debugviamcp.cmd, whose path
never changes. There is no separate tool to install (the server needs the .NET 10 runtime), updates do not touch a
server an agent is still running, and uninstalling the extension is never blocked by a running agent. - Extensions → Debugging via MCP → Set Up AI Agent… opens a window: it checks the .NET runtime and the installed
server, lists AI clients (Claude Code, Codex, Cursor, another MCP client) and, for the one you pick, shows the command or
configuration to copy. It runs nothing and changes no client's settings. The separate Copy MCP Setup Command is gone. - Visual Studio only: Visual Studio Code is not supported, and the documentation says so.
scripts\reinstall-vsix.ps1stops a stuck VSIXInstaller after-InstallerTimeoutSeconds(default 180) instead of
hanging, and refuses to start while another VSIXInstaller runs.- The Log retention (days) option now also applies to the MCP server's own log files (
mcp-*.log), not only to the
extension's logs and the audit trail. debug_start(project)starts the named project and leaves the solution's startup project as it was.debug_start,debug_attachandbp_setreturnwarningswhen the build is older than the sources; Visual Studio
offers an optional Build bar (hidden while debugging, gone once the project is up to date).
Fixed
- The out-of-date check no longer compares
deps.json/runtimeconfig.json(incremental builds do not rewrite them) with the
sources: only the assembly and the symbols count. Found in a real Visual Studio run. - A refused connection approval or a disconnected AI ends the call instead of being asked twice; a read that waited for an
answer is refused if another agent took the Visual Studio meanwhile. debug_statusbrings the agent's session state in step with Visual Studio after a period in which another agent held it.debug_start(project)keeps a "Multiple startup projects" setting intact.- The Visual Studio taskbar button flashes when a consent question appears while Visual Studio is in the background; the status
bar shows plain text when Visual Studio 2026 hides its custom status bar panel. - A timed-out
evalexplains the 5-second limit and what to do instead. - Set Up AI Agent never tries to update a running tool (it would fail halfway); it names the running agent sessions.
Changed
- The out-of-date bar says "Debugging via MCP: … is out of date: the built program does not match the sources. Build it now?" and its
button runs a normal incremental Build of that project (it used to clean and rebuild, which a stale output does not need). - The consent question bar also starts with "Debugging via MCP:", so both bars show which extension is asking.
- No out-of-date warning and no Build bar while nothing is running and Visual Studio builds by itself as debugging starts (its option
On Run, when projects are out of date = Always build, the default): it would be a false alarm. They stay when a program is running
(it keeps its old binary) or when that option is Never build / Prompt to build. - The product is now called Debugging via MCP. The MCP server (command
debugviamcp) travels inside the extension, which
shows as "Debugging via MCP", and the data folder is%LOCALAPPDATA%\DebugViaMcp. - The settings moved to Visual Studio's settings experience: Tools → Options → All Settings → Debugging → Debugging via
MCP. The setup window stays in Extensions → Debugging via MCP (Set Up AI Agent…). - Settings apply as soon as they change. A stored Mutate = Allow counts only after you confirm it in a dialog (also at
startup); until then Visual Studio keeps asking, so a value written to the settings file never silently lets the agent
change program state. - Two new settings cap how long an agent may keep Visual Studio waiting: Longest wait for a break (
debug_start,debug_continue,
debug_step,debug_run_to,debug_wait; 5–600 s, default 120) and Longest wait for a build (vs_build; 30–1800 s, default 600).
The agent may ask for less, never for more; a longer build keeps running and the agent can ask again. Together with the existing
Consent timeout they are in the settings page of Visual Studio. - Wire protocol 2.3 (additive): the handshake carries the two limits. Older extensions or servers keep the built-in 120 s / 600 s.
- Wire protocol 2.2 (additive). A 2.1 extension keeps working with the 0.4 tool; the new tools then report
unsupported. - Break and mode events go only to the agent that holds the Visual Studio.
vs_instanceslists availability (free/in_use), the holder and whether the folder matches.