Skip to main content
Glama
WSSAWER

1C Debug MCP

by WSSAWER
README.md
# 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

A3.8/5.0

Scored across 15 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues