1C Debug MCP Server
An MCP debug server for 1C over the HTTP Debug Protocol: breakpoints, step execution, variables and call stack
- 2 ★ on the repository
- Last commit
- MIT
Extended access
Why this level
- Gives access to variables and code execution inside a debug session on a live or test database
- Breakpoints can pause work for users on the connected database
A similar tool with a larger community: 1C Debug MCP Server, 21 ★ on the repository
Install
- Works in
- Services
Manual install
cd 1c-debug-mcp/go
go build -o dist/1c-debug-mcp.exe ./cmd/1c-debug-mcp/Builds the Go-based version 2.0; needs Go 1.23+ and Windows to run dbgs.exe.
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- Gives access to variables and code execution inside a debug session on a live or test database
- Breakpoints can pause work for users on the connected database
This is third-party code. Review the repository files before installing.
What it does
The server connects to the 1C:Enterprise dbgs.exe debug server and lets the agent drive debugging: set breakpoints in configuration, extension and external processing modules, step through code, pause execution, read local variables, evaluate BSL expressions at a breakpoint, and inspect the call stack. Module objectID is auto-resolved from metadata by module name, and metadata is cached for a fast start on large configurations. Version 2.0 is rewritten in Go as a single dependency-free binary; the earlier TypeScript version is still in the repository.
Who it is for. For 1C developers who want an agent to set breakpoints and dig into failures itself instead of manual work in the debugger.
Good fit when
- You want the agent to reproduce a 1C bug through step debugging, not just code reading
- You work in Kiro or another client with stdio MCP support on Windows
- You need fast attach on large configurations thanks to metadata caching
Not a fit when
- The dbgs.exe debug server is unavailable or debugging is against policy on this database
- You need cross-platform config without Windows-specific paths
- The agent must not be allowed to read variable values from a live session
Example request
Set a breakpoint in the Order document posting module and show the variable values when it stopsMCP
- Transport
- stdio
- Authentication
- not required
Environment variables
ONEC_DEBUG_URLrequired- 1C dbgs.exe debug server URL
ONEC_INFOBASE_ALIASrequired- Infobase alias for the debug connection
ONEC_DEBUG_PASSWORDsecret- Debug server password, if one is set
ONEC_CF_PATH- Path to the exported configuration for module mapping
Limitations
It needs a running 1C debug server (dbgs.exe) and 1C:Enterprise 8.3. Building from source needs Go 1.23+, and the example configs use Windows-style paths. Global and local env blocks in Kiro config do not merge, so parameters must be duplicated in the local file.
How to disable. Disable the 1c-debug server in the client's MCP Servers panel, or remove its block from .kiro/settings/mcp.json.
FAQ
Do I need Node.js for version 2.0?
No, version 2.0 is rewritten in Go and builds into a single dependency-free binary.
What if I hit an ibInDebug error or a stuck session?
Call the force_detach tool, which forcibly stops the ping loop and clears the session.
Discussion
No questions or reviews yet.
Related
All 1C:Enterprise toolsA Go MCP server for debugging 1C over the HTTP Debug Protocol: breakpoints, step execution and variable inspection
A single-binary Go MCP server: the agent sees 1C metadata, searches code, runs read-only queries and writes accurate BSL
Ten MCP servers for 1C development: platform reference, targeted object dump and load, COM, storage, file search and BSL Language Server
An MCP server that exposes the cloud 1C:Napparnik (1C.ai) assistant and a local BSL Language Server to agents in Cursor and other IDEs
A 1C:EDT plugin that gives agents projects, errors, BSL analysis, form screenshots, metadata refactoring and infobase launch over MCP
A 1C extension that runs an MCP server inside the 1C:Enterprise client and lets you write your own tools in BSL
README in short
The Russian README describes the Go-based version 2.0: connecting to dbgs.exe, breakpoints, objectID auto-resolution, metadata caching, step execution and expression evaluation. It gives a table of ONEC_* config parameters for .kiro/settings/mcp.json and lists tools such as attach, detach, force_detach, get_targets and set_breakpoints with example parameters and responses. It also points to separate ARCHITECTURE, CACHE, PERFORMANCE and FAQ documents.