feat(tools): add Visual Studio terminal tools

[CalvinAllen]

Resolves #103

Adds six MCP tools over the Visual Studio integrated terminal.

Tool	Behavior
terminal_run	Run a command in a new terminal, inside the VS developer environment
terminal_create	Open an empty terminal using the user's default profile
terminal_list	List open terminal identifiers
terminal_show	Bring a terminal into view
terminal_close	Close one terminal
terminal_close_all	Close every terminal

Assembly access turned out better than expected

My comment on #103 assumed the whole brokered-service stack would need reflection. It doesn't. IBrokeredServiceContainer, IServiceBroker, ServiceRpcDescriptor and ServiceActivationOptions all come from Microsoft.ServiceHub.Framework, a real NuGet package the VSIX already pulls in transitively. I verified with a compile probe before designing.

Only three types need reflection — ITerminalService, ProfileConfig and TerminalServiceDescriptors, from Microsoft.VisualStudio.Terminal.dll, which is subject to the same constraint documented on TestExplorerInterop: VS-install-only, absent from NuGet and the SDK metapackage, and $(DevEnvDir) undefined under dotnet build.

The assembly is loaded by strong name at 17.0.0.0. Both VS 2022 and VS 2026 ship a binding redirect covering 0.0.0.0 through the installed version plus a codeBase entry pointing at CommonExtensions\Microsoft\Terminal, so one version number resolves on both. An already-loaded copy is preferred when present, which avoids depending on binding policy at all once the terminal window has been used.

Design notes

Commands run via ProfileConfig, not a PTY stream. ProfileConfig exposes Location and Arguments, so a command can be launched by creating a terminal configured to run it — no duplex-stream plumbing, no AttachTerminalStreamAsync. Much less machinery than the issue anticipated.

Developer environment by default. When VsDevCmd.bat can be located from VSAPPIDDIR, it's chained in ahead of the command, so msbuild, vstest.console and dotnet-coverage are on PATH. Plain cmd.exe would not have them — and the OpenCover-style use case in #95 is exactly why that matters. Falls back cleanly when the script isn't found, and reports which happened via DeveloperEnvironment.

Working directory defaults to the solution directory, not devenv's own current directory, which points into the Visual Studio install.

Output is deliberately not captured. The terminal is a raw PTY: no exit code, no command boundaries. Rather than return text an agent might misread as success, the tool descriptions state the limitation and point at redirecting to a file and reading it back with document_read. This is the limitation I flagged on #95 and it is inherent to the API, not to this implementation.

Testing

dotnet build -c Release clean, 0 warnings. 50/50 tests pass (14 added).

TerminalInterop takes an assembly resolver so tests can supply the test assembly, whose stand-ins are declared in the genuine Microsoft.VisualStudio.Terminal namespace. That runs the real path end to end: type resolution, descriptor retrieval, the generic GetProxyAsync<T> invocation including its ValueTask unwrapping, overload selection, and profile construction.

The overload selection is worth calling out — CreateTerminalAsync has four overloads, and the three-argument one would silently drop the working directory. The stand-in throws if that overload is picked, so the test fails loudly rather than quietly passing with a wrong working directory.

Not covered automatically: an actual VS terminal opening, which needs a live instance.

Security note

terminal_run executes commands on the machine. The README now flags that under Settings, next to the Binding Address option, since combining it with a non-localhost binding exposes command execution to the network.