1C Debug MCP
# 1C Debug MCP
Standalone MCP server for debugging an already running 1C:Enterprise infobase through the platform HTTP RDBG server.
The server does not launch or stop 1C, `dbgs`, Designer, or external commands. It connects to an existing RDBG endpoint, attaches current and future debug targets, manages breakpoints, reads call stacks and local variables, evaluates expressions, and continues or steps execution.
## Requirements
- Node.js 20 or newer for a source build.
- 1C:Enterprise HTTP debug server reachable from the machine running this MCP.
- A 1C client started in HTTP debug mode, for example:
```text
/DEBUG -http -attach /DEBUGGERURL"http://debug-host:1550"
```
- An XML export of the matching configuration when resolving local `.bsl` paths for breakpoints.
## Run from source
```powershell
npm ci
npm test
npm start
```
The MCP transport is stdio. MCP Control Center can publish it through its existing worker and HTTP Gate.
## Release branch
The `release` branch is the portable runtime branch. It contains the bundled `server.cjs`, `mcp.json`, this README, and the license. The bundle does not require `npm install`; only Node.js 20+ is required.
## Typical tool sequence
1. `check_debug_server`
2. `connect_debugger`
3. `set_breakpoints`
4. Trigger the required action in 1C.
5. `poll_debug_events`
6. `get_call_stack`, `get_local_variables`, optionally `evaluate_expression`
7. `continue_or_step`
8. `disconnect_debugger`
Always continue or disconnect a stopped target so the 1C session is not left suspended.
## Attribution
The RDBG protocol implementation was extracted and adapted from the MIT-licensed [DevTool1C](https://github.com/asweetand-a11y/DevTool1C) project.
TDQS
Scored across 15 tools
Each tool targets a distinct phase of the 1C debugging workflow: connection, target management, execution control, inspection, and source mapping. Even similar actions like check_debug_server vs connect_debugger are clearly separated by whether a debugger UI is registered.
All tool names follow a consistent snake_case verb_noun pattern, such as list_debug_targets, attach_targets, set_breakpoints, and continue_or_step. This makes the toolset highly predictable and easy to navigate.
15 tools is at the upper boundary of the well-scoped range, but every tool earns its place in a debugger lifecycle: connect, list, attach, breakpoint, poll, inspect, evaluate, step, suspend, detach. The count matches the complexity of the domain without redundancy.
The toolset covers the full debugging workflow from connecting to a debug server and resolving source modules, through attaching targets, setting breakpoints, polling events, inspecting state, controlling execution, and detaching. There are no obvious dead ends or missing critical debugger operations.