Build & Unit Tests, E2E, and MCP Conformance all run on stock GitHub-hosted runners (cloud CI) — no docker image, no self-hosted runner. E2E and Conformance run against EDT 2026.2 (build 2026.2, Eclipse 4.38 / Java 25): the setup step installs a headless EDT of that version on the runner via p2 director. E2E additionally imports the test fixtures into an empty workspace via the plugin's headless bootstrap (EDT_MCP_IMPORT_PROJECTS) and skips the live-infobase tools, so no 1C platform is needed. Each badge reflects its latest run.

EDT MCP Server

MCP (Model Context Protocol) server plugin for 1C:EDT, enabling AI assistants (Claude, GitHub Copilot, Cursor, etc.) to interact with EDT workspace.

[!TIP] Contributing / making changes? Read CLAUDE.md first — it's the code-conduct "minefield map": hard don'ts and the stop-and-think-twice zones for this codebase (BM transactions, the bilingual ru/en model, cascading rename, etc.). Detailed how-to lives in the skills under .claude/skills/.

[!IMPORTANT] EDT version compatibility: Supports 1C:EDT 2026.1 and 2026.2 (Ruby) from a single build. The plugin is COMPILED against the 2026.1 target platform (the oldest supported EDT — Eclipse 4.30 / Java 17) so one artifact resolves on both, and the e2e + protocol-conformance gates run it on 2026.2 (Eclipse 4.38 / Java 25), the newest.

Features

• 🔧 MCP Protocol 2025-11-25 - Streamable HTTP transport with SSE support
• 📊 Project Information - List workspace projects and configuration properties
• 🔴 Error Reporting - Get errors, warnings, problem summaries with filters
• 📝 Check Descriptions - Get check documentation from markdown files
• 🔄 Project Revalidation - Trigger revalidation when validation gets stuck
• 🔖 Bookmarks & Tasks - Access bookmarks and TODO/FIXME markers
• 💡 Content Assist - Get type info, method hints and platform documentation at any code position
• 🧪 Query Validation - Validate 1C query text in project context (syntax + semantic errors, optional DCS mode)
• 🧩 BSL Code Analysis - Browse modules, inspect structure, read/write methods, search code, and analyze call hierarchy
• 🖼️ Form Inspection - Get PNG screenshots and YAML layout snapshots from the form WYSIWYG editor
• 🚀 Application Management - Get applications, update database, launch in debug mode, terminate EDT-launched 1С clients
• 🎯 Status Bar - Real-time server status with tool name, execution time, and interactive controls
• ⚡ Interruptible Operations - Cancel long-running operations and send signals to AI agent
• 🏷️ Metadata Tags - Organize objects with custom tags, filter Navigator, keyboard shortcuts (Ctrl+Alt+1-0), multiselect support
• 📁 Metadata Groups - Create custom folder hierarchy in Navigator tree per metadata collection, with a toolbar toggle to hide groups temporarily
• ✏️ Metadata Refactoring - Create top-level objects with EDT default content; rename/delete metadata objects, their members and managed-form elements with full cascading updates across BSL code, forms and metadata; add new attributes to existing objects
• 🛠️ Tool Management - Enable/disable tools by group, presets (Analysis Only, Code Review, Development), per-tool parameter defaults

Installation

From Update Site

1. In EDT: Help → Install New Software...
2. Add update site URL: https://ditrixnew.github.io/EDT-MCP/
3. Select EDT MCP Server Feature
4. Restart EDT

From Windows command line - "one shot" very fast install

Close your EDT (!) and run:

rem Here  "%VER_EDT% = 2025.2.3+30"  just for example - please, set YOUR actual version !
set VER_EDT=2025.2.3+30

"\your\path\to\EDT\components\1c-edt-%VER_EDT%-x86_64\1cedt.exe" -nosplash ^
    -application org.eclipse.equinox.p2.director ^
    -repository https://ditrixnew.github.io/EDT-MCP/ ^
	-installIU com.ditrix.edt.mcp.server.feature.feature.group ^
	-profileProperties org.eclipse.update.reconcile=true

Installation Result

After that, EDT will automatically monitor the update site and install available updates when detected.

As well, we can also manually check via Help → About → Installation Details → Select MCP → Update

Required JVM flag for form screenshots

The get_form_screenshot and get_form_layout_snapshot tools need EDT to be launched with the following JVM flag:

-DnativeFormBufferedLayoutRender=true

Without it, both tools return blank output (gray PNG / empty elements list).

Why: EDT's NativeRenderService reads nativeFormBufferedLayoutRender once at class-load time. If it was unset at JVM startup, the singleton HippoLayoutService is constructed without its offscreen buffer handler, the C++ form renderer never writes captureable pixels back to Java, and the screenshot helper falls through to an SWT Control.print() of the native window — which on Windows produces a gray rectangle. Setting the flag at runtime via reflection does not help because the singleton has already been built.

How to add it (persistent, recommended):

1. Close EDT.

2. Open 1cedt.ini (next to 1cedt.exe, e.g. C:\Program Files\1C\1CE\components\1c-edt-2025.2.6+4-x86_64\1cedt.ini).

3. After the -vmargs line, add:

   -DnativeFormBufferedLayoutRender=true
   

4. Start EDT.

How to add it (one-shot, no install changes):

"<path-to-EDT>\1cedt.exe" -data "<workspace>" -vmargs -DnativeFormBufferedLayoutRender=true

The same flag is also recommended for production EDT use — it enables the buffered native renderer that EDT itself benefits from.

If your screenshots still come back blank after adding the flag, verify with -vmargs actually appears before it in 1cedt.ini (Eclipse stops parsing -vmargs block once it hits a non--D line) and that EDT was fully restarted.

Configuration

Go to Window → Preferences → MCP Server. The settings page has two tabs:

[!NOTE] Display language. The settings page and the tag dialogs are bilingual (Russian / English) and follow the Eclipse/EDT display language — the same -nl launch argument (or OS locale) that localizes the rest of EDT. Launch EDT with -nl ru for Russian or -nl en for English; any other locale falls back to English. The MCP tool surface itself (tool names, descriptions and errors) stays English regardless, as it is the AI wire contract.

General Tab

• Server Port: HTTP port (default: 8765)
• Check descriptions folder: Path to check description markdown files
• Auto-start: Start server on EDT launch
• Plain text mode (Cursor compatibility): Returns results as plain text instead of embedded resources (for AI clients that don't support MCP resources)
• Show tags in Navigator: Display tags as decorations in the Navigator tree
• Tag decoration style: How tags are displayed — all tags as suffix, first tag only, or tag count
• Server control: Start, stop, and restart the MCP server directly from preferences

Tools Tab

Manage which tools are available to AI assistants. Tools are organized into groups that can be enabled or disabled together. See Tool Management for details.

Status Bar Controls

The MCP server status bar shows real-time execution status with interactive controls.

Status Indicator:

• 🟢 Green - Server running, idle
• 🟡 Yellow blinking - Tool is executing
• ⚪ Grey - Server stopped

During Tool Execution:

• Shows tool name (e.g., MCP: update_database)
• Shows elapsed time in MM:SS format
• Click to access control menu

When a tool is executing, you can send signals to the AI agent to interrupt the MCP call:

How it works:

1. When you click a button, a dialog appears showing the message that will be sent to the agent
2. You can edit the message before sending
3. The MCP call is immediately interrupted and returns control to the agent
4. The EDT operation continues running in the background
5. Agent receives a response like:

USER SIGNAL: Your message here

Signal Type: CANCEL
Tool: update_database
Elapsed: 20s

Note: The EDT operation may still be running in background.

Use cases:

• Long-running operations (full database update, project validation) blocking the agent
• Need to give the agent additional instructions
• EDT showed an error dialog and you want agent to retry
• Want to switch agent's focus to a different task

Tool Management

Control which MCP tools are exposed to AI assistants. This lets you reduce context window usage and restrict AI to read-only operations when needed.

Tool Groups

All tools are organized into 10 semantic groups:

Enable or disable entire groups or individual tools from the Tools tab in Window → Preferences → MCP Server. Disabled tools are filtered out of tools/list responses. If a client calls a disabled tool directly through tools/call, the server returns a message explaining that the tool is disabled.

Presets

Quickly switch between common tool configurations using presets:

Select a preset from the dropdown in the Tools tab. The preset auto-detects based on the current enabled/disabled state and shows "Custom" when the configuration doesn't match any built-in preset.

Per-Tool Parameter Defaults

Some tools have configurable default values for parameters like result limits. These defaults are used when the AI client doesn't specify the parameter explicitly:

Configure these in the Tools tab by selecting a tool that has configurable parameters — the parameter editors appear in the details panel below the tool tree.

Progressive Tool Disclosure (dynamic toolsets)

For clients that work better with a small initial tool surface, the server can expose only a core toolset up front and reveal the rest on demand — shrinking the always-loaded tools/list. This is off by default (the full list is exposed, unchanged); turn it on with the Progressive disclosure preference (or the EDT_MCP_PROGRESSIVE_DISCLOSURE=true environment variable for headless/CI runs).

When on, only the core toolset (navigation, source read, metadata discovery, and the two management tools) appears in tools/list. To use more tools:

1. Call list_toolsets to see the groups (core, metadata, code, debug, testing, profiling, forms, tags, translation, project, git) and their tools.
2. Call enable_toolset with toolsets=[ids] (e.g. ["code","debug"]).
3. Re-request tools/list — the revealed tools now appear.

This server does not push notifications/tools/list_changed, so the client must re-list after enabling (the enable_toolset response says so). A hidden tool is only hidden from tools/list; it remains callable by name. These progressive-disclosure toolsets are distinct from the Tool Groups above (which the Tools tab uses to enable/disable tools persistently).

Connecting AI Assistants

VS Code / GitHub Copilot

Create .vscode/mcp.json:

{
  "servers": {
    "EDT MCP Server": {
      "type": "sse",
      "url": "http://localhost:8765/mcp"
    }
  }
}

Cursor IDE

Note: Cursor doesn't support MCP embedded resources. Enable "Plain text mode (Cursor compatibility)" in EDT preferences: Window → Preferences → MCP Server.

Create .cursor/mcp.json:

{
  "mcpServers": {
    "EDT MCP Server": {
      "url": "http://localhost:8765/mcp"
    }
  }
}

Claude Code

Note: By editing the file .claude.json can be added to the MCP either to a specific project or to any project (at the root). If there is no mcpServers section, add it.

Add to .claude.json (in Windows %USERPROFILE%\.claude.json):

"mcpServers": {
  "EDT MCP Server": {
    "type": "http",
    "url": "http://localhost:8765/mcp"
  }
}

Claude Desktop

claude_desktop_config.json accepts only stdio servers (a command), not a direct url, so bridge the HTTP endpoint with mcp-remote (requires Node.js):

{
  "mcpServers": {
    "EDT MCP Server": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://localhost:8765/mcp"]
    }
  }
}

The Settings → Connectors ("custom connector") route needs an HTTPS server reachable from Anthropic's cloud, so a plain-HTTP localhost endpoint must go through the mcp-remote stdio bridge above. You could expose it over an HTTPS tunnel (ngrok / Cloudflare Tunnel) to use a connector — but this server can write code into your configuration and start a debugger, so putting it on the public internet is a serious security risk and is not recommended.

Cline - extension for VSCode.

{
  "mcpServers": {
    "EDTMCPServer": {
      "type": "streamableHttp",
      "url": "http://localhost:8765/mcp"
    }
  }
}

Antigravity

{
    "mcpServers": {
        "EDTMCPServer": {
            "serverUrl": "http://localhost:8765/mcp"
        }
    }
}

1C:Workmate in-process bridge

When 1C:Workmate (com.e1c.edt.ai* 1.0.5) runs in the same EDT JVM, integration works in both directions:

• ask_workmate starts Workmate's full conversation/tool loop in a bounded background job and returns a pollable jobId, so the MCP transport request does not stay open for the full cloud round-trip. Poll that id with the shared get_job_status tool; cancel_job first previews and only acts with confirm=true, and it never claims that a request already handed to Workmate was cancelled. The Workmate bundles remain optional and are loaded only at runtime through OSGi/reflection; they are not part of this project's target platform. The tool ships disabled — it sends the question to an external cloud service and Workmate may change the configuration with its own tools — so enable it under Preferences → EDT MCP Server → Tools first.
• The OSGi service com.ditrix.edt.mcp.server.bridge.IEdtMcpBridge lets Workmate/JShell list and call EDT-MCP tools without importing EDT-MCP packages. callTool goes through the same dispatcher as MCP tools/call and returns its JSON-RPC response.

Two details decide whether this actually works, both measured against Workmate 1.0.5:

• The skill. ConversationFacade defaults to raw, under which the cloud answers from the model alone — one assistant message, no tool call, no look at the project. ask_workmate therefore sends custom (the skill Workmate's own autopilot uses), which runs the full tool loop. Override with skillName only if you know the name is accepted; the cloud refuses most others outright.
• The question carries the bridge. Workmate's chat reads a project's .workmate rules, but this Java path does not, so ask_workmate prefixes the question with the bridge instructions and the list of tool NAMES (full descriptions stay behind get_tool_guide, which it calls when it needs one). Pass shareMcpTools=false to send the question verbatim instead.

The same instance is published under the JDK types BiFunction<String,String,String> (callTool) and Supplier<String> (listTools), both carrying the service property edt.mcp.bridge=v1. Prefer that alias: it needs no reflection and no access to the bridge package, which matters for callers whose rules forbid unproven Java API - such as Workmate's JShell tool.

// Take the context from an ALWAYS-ACTIVE bundle, not from EDT-MCP's own: this bundle
// uses lazy activation, so `Platform.getBundle("com.ditrix.edt.mcp.server")
// .getBundleContext()` can hand back null and the next line then fails with
// "because ctx is null". OSGi services are global, so any live context finds this one.
var bundleContext = org.osgi.framework.FrameworkUtil
    .getBundle(org.eclipse.core.runtime.Platform.class).getBundleContext();
var references = bundleContext.getServiceReferences(
    java.util.function.BiFunction.class, "(edt.mcp.bridge=v1)");
if (references.isEmpty()) {
    throw new IllegalStateException("EDT-MCP bridge service is not registered");
}
var mcp = bundleContext.getService(references.iterator().next());
System.out.println(mcp.apply("get_edt_version", "{}"));

A consumer that prefers the named contract can still resolve it by string name and invoke it reflectively:

var serviceReference = bundleContext.getServiceReference(
    "com.ditrix.edt.mcp.server.bridge.IEdtMcpBridge");
var bridgeService = bundleContext.getService(serviceReference);
try {
    var callTool = bridgeService.getClass().getMethod(
        "callTool", String.class, String.class);
    System.out.println((String) callTool.invoke(
        bridgeService, "get_edt_version", "{}"));
} finally {
    bundleContext.ungetService(serviceReference);
}

Letting Workmate's chat use the bridge

Workmate's agentic chat holds its JShell tool but not JShellSession, and JShell rejects every call whose repl_session_id it cannot resolve. The chat can therefore execute code but cannot obtain the one value executing code requires.

EDT-MCP breaks that deadlock: shortly after startup it registers a JShell session under the constant id edt-mcp (retried in the background while Workmate comes up, and again if Workmate ever evicts it). Together with jshell_edt_canonical_imports — a fixed entry in Workmate's own scenario catalogue — both values JShell demands are constants, so a project's rules can name them literally and nothing has to be passed around at runtime:

repl_session_id = "edt-mcp"
manual_ids      = ["jshell_edt_canonical_imports"]

tests/TestConfiguration/.workmate/WORKMATE.md is a working example of such a rules file; copy it into <project>/.workmate/ to give the chat the same access in your own configuration. Note that the chat cannot reach the HTTP endpoint at all — java.net.URL, java.net.Socket and ProcessBuilder are on Workmate's restricted-types list — so the in-process bridge is its only route.

Multi-EDT Proxy

Running more than one EDT instance at once? edt-mcp-proxy is a standalone router that exposes a single, stable MCP endpoint on :8764 and forwards each call to the right EDT-MCP instance by projectName, discovering live instances in the background. It ships as edt-mcp-proxy-<version>.jar alongside the plugin archive in every release. See proxy/README.md for setup, CLI options and configuration.

Available Tools

The full per-tool reference lives in docs/tools/ — one page per tool (what it does, every parameter, and how it works), generated from the live MCP server (get_tool_guide) so it never drifts from the code. Index below; re-generate with python docs/generate_tool_docs.py.

89 tools, grouped by toolset. Full per-tool pages under docs/tools/.

Core

Always-on essentials: project/module navigation, source read, metadata discovery, and the toolset-management tools (list_toolsets / enable_toolset).

Metadata

Metadata objects: discovery, create/modify/delete/rename/adopt, subsystems, configuration.

Code

BSL code: write/read methods, call hierarchy, go-to-definition, references, content assist, queries.

Debug

Runtime debugging: launch/attach, breakpoints, step/resume, variables, expression evaluation.

Testing

YAXUnit unit testing, 1C:Workmate assistance, and shared background-job polling.