bsl-mcp-bridge
A Dockerized MCP server that keeps BSL Language Server running and gives the agent code navigation, diagnostics and refactoring for 1C instead of grep search
- 1 ★ on the repository
- Last commit
- Apache-2.0
Extended access
Why this level
- The rename tool applies a project-wide symbol rename when apply=true
- code_actions can apply automatic fixes to code files
Install
- Works in
- Services
Manual install
docker compose build && docker compose up -dOne project per container, the 1C code path is set in .env.
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- The rename tool applies a project-wide symbol rename when apply=true
- code_actions can apply automatic fixes to code files
This is third-party code. Review the repository files before installing.
What it does
The server runs BSL Language Server on Java 21 inside a Docker container, keeps it warm and tracks indexing of the 1C codebase. The agent gets tools for symbol and text search, go-to-definition, hover with documentation, a call graph, document diagnostics with syntax errors and style issues, quick fixes, and project-wide symbol rename. The agent can pass file paths in any format (relative, container-absolute, file URI, or a host Windows path), and the server normalizes them, falling back to a suffix match when needed.
Who it is for. For 1C developers who want the agent to understand code structure through a language server rather than guessing from grep.
Good fit when
- You need precise BSL symbol navigation and a call graph before refactoring
- You need syntax diagnostics before a commit
- You need a safe project-wide symbol rename
Not a fit when
- You have no Docker and no 8+ GB of memory for BSL Language Server on a large project
- You just need quick text search without indexing
Example request
Find every place that calls the ЗаписатьВЖурнал procedure and show the call graph around itMCP
- Transport
- http, stdio
- Authentication
- not required
Environment variables
MCP_PROJECT_NAMErequired- Project name, part of the container name.
HOST_PROJECTS_ROOTrequired- Path to the 1C code on the host.
WORKSPACE_ROOTrequired- Root directory for BSL LS inside the container.
Limitations
Needs Docker and Docker Compose, an MCP-capable IDE, and enough memory: BSL Language Server is memory-hungry on large projects. The model is one project per container, so multiple configurations need multiple containers. The project builds on the approach from SteelMorgan/mcp-bsl-lsp-bridge, taken as a base.
How to disable. Stop the container with docker compose down and remove the server from your MCP client configuration.
FAQ
Do files need to be opened manually before hover or diagnostics?
No, the bridge calls textDocument/didOpen automatically before such operations and avoids reopening already-tracked documents.
How does call_graph differ from call_hierarchy?
call_hierarchy shows one level of callers and callees, while call_graph builds the full graph using BSL Language Server.
Discussion
No questions or reviews yet.
Related
All 1C:Enterprise toolsMCP bridge to BSL Language Server: navigation, diagnostics and refactoring of 1C and OneScript code for agents
An MCP server for BSL syntax checks on BSL Language Server in Docker: send code, get back JSON errors and warnings with no Java install needed
MCP wrapper for BSL Language Server
BSL MCP Server
A small MCP server that runs BSL Language Server as a JAR file and gives an agent BSL code analysis and formatting as JSON
A script installs BSL Language Server as a Linux systemd service and, with a flag, opens an MCP endpoint for AI agents
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 single-binary Go MCP server: the agent sees 1C metadata, searches code, runs read-only queries and writes accurate BSL
README in short
The README describes an architecture of an MCP bridge, an LSP session manager and BSL Language Server inside one Docker container, tables of tools for search, dependencies, diagnostics and refactoring, path formats, and recent changes like smart URI normalization and forced reindexing after did_change_watched_files. It notes the project builds on SteelMorgan/mcp-bsl-lsp-bridge as a base.