Summary
Add a new MCP tool called get_loaded_scripts that returns all scripts currently loaded in the active debug session.
Problem
When an AI agent wants to set a breakpoint, it currently has no way to know which files are actually loaded by the runtime. This forces the agent to guess file paths, which is a leading cause of breakpoints silently failing to bind (see #18). VS Code's Loaded Scripts explorer (visible in the Run & Debug sidebar) already shows this information — it just isn't surfaced through DebugMCP.
Proposed Solution
Add a get_loaded_scripts tool that uses the Debug Adapter Protocol loadedSources request via vscode.debug.activeDebugSession.customRequest('loadedSources', {}) to return the list of all sources loaded by the runtime.
Requirements:
- No parameters required
- Must work on a running debug session — does not require the session to be paused or stopped at a breakpoint
- Should return a clear error if no debug session is active
- Should return a graceful error if the debug adapter does not support
loadedSources (it is an optional DAP capability — supported by Node.js, Electron, and Chrome-based adapters)
Summary
Add a new MCP tool called
get_loaded_scriptsthat returns all scripts currently loaded in the active debug session.Problem
When an AI agent wants to set a breakpoint, it currently has no way to know which files are actually loaded by the runtime. This forces the agent to guess file paths, which is a leading cause of breakpoints silently failing to bind (see #18). VS Code's Loaded Scripts explorer (visible in the Run & Debug sidebar) already shows this information — it just isn't surfaced through DebugMCP.
Proposed Solution
Add a
get_loaded_scriptstool that uses the Debug Adapter ProtocolloadedSourcesrequest viavscode.debug.activeDebugSession.customRequest('loadedSources', {})to return the list of all sources loaded by the runtime.Requirements:
loadedSources(it is an optional DAP capability — supported by Node.js, Electron, and Chrome-based adapters)