edt-bridge-mcp

English · Русский

stdio MCP front-end for the edt-bridge 1C:EDT plugin.

The Java plugin serves MCP as plain JSON-RPC over HTTP on 127.0.0.1:8770 – which means an MCP client configured with that URL loses the server whenever EDT is not running. This wrapper is what the client talks to instead:

• EDT open (GUI or headless) → every request is forwarded to the live bridge;
• EDT closed → it auto-starts a headless EDT (1cedtcli with a keepalive pipe, the same recipe as scripts/run-headless.ps1) and forwards once the model is ready;
• plugin jar missing → it delivers the jar itself from the latest GitHub release (checksum-verified) into EDT's dropins/ before starting – a bare pipx install edt-bridge-mcp is enough to get a working bridge;
• a client session never hangs on startup: while the backend is starting, tools/list returns an empty list and a notifications/tools/list_changed follows when ready.

Install

pipx install edt-bridge-mcp        # or: pipx install ./python  from a checkout

Register in an MCP client

claude mcp add edt-bridge -- edt-bridge-mcp --workspace "D:\\path\\to\\edt-workspace"

From a shell

The default mode speaks JSON-RPC over stdin/stdout, for an MCP client to drive. To reach the same bridge by hand or from a script, use the sub-commands – same port scan, same token, same headless auto-start:

edt-bridge-mcp tools                    # what the running bridge serves
edt-bridge-mcp call edt_projects        # call a tool, print what it returned
edt-bridge-mcp call edt_metadata_details --json '{"projectName": "SM", "fqn": "CommonModule.Foo"}'
edt-bridge-mcp call edt_create_extension --json-file args.json   # arguments from a UTF-8 file
edt-bridge-mcp status                   # is a bridge up? (never starts one)

--raw prints the JSON result instead of the text a tool returned. Arguments come from --json, --json-file or --stdin; a file is the dependable route for non-ASCII arguments on Windows.

Exit codes: 0 fine, 1 the call could not be made (no bridge, bad usage, transport error), 2 the bridge ran the tool and the tool reported an error – so a script can tell "it failed" from "it never ran".

Self-update

edt-bridge-mcp self-update             # refresh the plugin jar (GitHub Releases) + the wrapper (PyPI)
edt-bridge-mcp self-update --jar-only  # only the jar
edt-bridge-mcp self-update --pip-only  # only the wrapper
edt-bridge-mcp self-update --pip-only --from <repo>/python   # from a checkout

A running EDT (GUI or headless) keeps the old jar loaded until it restarts; the wrapper restarts its own headless instance on the next auto-start.

--from installs the wrapper from a local checkout instead of PyPI – for trying a build that is not released yet, without a full pipx install --force (which rebuilds the venv and replaces the exe the running client holds).

The exit code separates the bridge from its add-ons: 0 when every step asked for succeeded, 1 when the bridge itself did not update (the jar or the wrapper) or nothing did, and 2 when the bridge is current and only a wrapper plugin is not – a plugin installs from its own source, and that source being unreachable is not the bridge failing to update.

The wrapper updates itself by unpacking, not through an installer: it downloads the wheel from PyPI (or copies the package out of the checkout given to --from) and replaces the package inside site-packages using the standard library alone. No pip, no pipx, no build backend – which matters, because pipx 1.15 builds its venvs through uv and a uv-built venv contains no pip at all.

Plugins

External packages installed into the wrapper's environment can add MCP tools of their own – the home for what a public repository cannot carry (reference material under somebody's license, tools wired to an internal service). The wrapper discovers them through the edt_bridge.tools entry-point group, lists their tools next to the bridge's and dispatches them itself, so they answer even while no EDT is running.

pipx inject edt-bridge-mcp <package>   # install a plugin
edt-bridge-mcp plugins                 # what is plugged in, or why a plugin refused to load

EDT_BRIDGE_NO_PLUGINS=1 turns the discovery off. The declaration contract for plugin authors is on the installation page.

The exes in Scripts are never touched: they are what a running client holds open, Windows will not let them be replaced, and they do not need to be – the stub launches whatever code is in site-packages the next time it starts. pipx_metadata.json is corrected so pipx list does not go on reporting the old version. An editable install is refused rather than overwritten.

Configuration

CLI flags override the environment.

The rarely-touched ones (EDT_BRIDGE_PORT_SCAN, EDT_BRIDGE_WINDOW_WAIT, EDT_BRIDGE_LANG) and the plugin's own variables are in Environment variables.

Safety

• If a GUI EDT is running but the bridge port is dead (plugin missing there), the wrapper refuses to start a headless instance – the GUI holds the workspace lock. It still delivers the jar into dropins/ when missing, so restarting that EDT activates the bridge.
• If a headless 1cedtcli is already starting, the wrapper waits for it instead of spawning a second one.