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 per EDT version (2025.2 and 2026.1, each its own badge): 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. (New CI badges render once these workflows land on the default branch.)

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

• 🔧 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 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

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

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

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

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.

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

• 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

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.

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

USER SIGNAL: Your message here

Signal Type: CANCEL
Tool: update_database
Elapsed: 20s

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

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.

All 65 tools are organized into 9 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.

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.

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.

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) 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).

Create .vscode/mcp.json:

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

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

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

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

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

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

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.

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

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

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

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

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

YAXUnit unit testing: run and debug test suites.

Performance profiling: start/stop a measurement and read the results.

Managed-form rendering: layout snapshot and screenshot.

Tag-based organization: list tags and find objects by tag.

Configuration translation via LanguageTool: extract, translate, project info.

Project operations: clean/revalidate, update DB, export/import XML, problems and markers, docs.

Each tool declares a response type (IMcpTool.getResponseType()). The default — and the most common type — is Markdown: any tool that does not override getResponseType() returns Markdown as an EmbeddedResource with mimeType: text/markdown. The non-default types are enumerated exhaustively below; everything not listed here is Markdown.

structuredContent/JSON exists for clients to consume, not for the agent to read: it is justified only by verbatim round-trip of identifiers, machine-structured positions, a declared outputSchema, or UI-rendered data. Markdown is the default because it is more token-efficient and directly readable.

A tool returns JSON only when its result carries at least one of:

• (a) round-trip IDs another tool consumes (e.g. a created object's FQN, a launch/application ID, a breakpoint ID);
• (b) machine-structured positions (e.g. an error line/column);
• (c) a declared outputSchema;
• (d) UI-rendered data.

An action/confirmation/status result with none of these returns Markdown. write_module_source is the reference Markdown action tool; revalidate_objects, export_configuration_to_xml, and import_configuration_from_xml follow it (status + paths/counts, no round-trip data).

Which tool families stay JSON, and why:

• metadata-writes (create_metadata, modify_metadata, delete_metadata, via AbstractMetadataWriteTool) — return the edited object's round-trip FQN (a);
• debug / profiling tools — return launch / application / breakpoint IDs and live session state consumed by follow-up calls (a);
• validate_query — returns the error line/column (b);
• list_configurations — returns config identities consumed by other tools (a);
• clean_project / update_database — return a destructive status whose JSON shape is asserted by e2e (d-like contract).

Errors are reported the same way regardless of a tool's normal format — see the Error contract below.

• Markdown tools (the default): every tool that is not listed under another type below, returned as an EmbeddedResource with mimeType: text/markdown. This includes all read/list/search/navigation tools that emit human-readable reports — for example list_projects, list_modules, list_subsystems, list_configurations, get_project_errors, get_markers, get_problem_summary, get_check_description, get_metadata_objects, get_metadata_details, get_module_structure, get_subsystem_content, get_symbol_info, get_method_call_hierarchy, get_objects_by_tags, get_tags, get_platform_documentation, find_references, go_to_definition, search_in_code, read_module_source, read_method_source, write_module_source, rename_metadata_object, run_yaxunit_tests, terminate_launch, revalidate_objects, export_configuration_to_xml, import_configuration_from_xml, and all three LanguageTool tools (generate_translation_strings, translate_configuration, get_translation_project_info). (list_configurations is the exception among the list_* tools — it returns JSON; see below.)
• YAML tools: get_configuration_properties — returns a human-readable YAML body as an EmbeddedResource (resource named *.yaml, mimeType: text/yaml).
• JSON tools (return JSON with structuredContent): get_server_status, get_applications, create_infobase, delete_infobase, get_content_assist, get_variables, get_profiling_results, list_configurations, list_breakpoints, set_breakpoint, remove_breakpoint, step, resume, wait_for_break, debug_launch, debug_status, debug_yaxunit_tests, evaluate_expression, start_profiling, stop_profiling, validate_query, clean_project, update_database, delete_project, plus the metadata-write tools that inherit JSON from AbstractMetadataWriteTool (create_metadata, modify_metadata, delete_metadata).
• Text tools (plain text): get_edt_version, get_form_layout_snapshot.
• Image tools: get_form_screenshot — returns the rendered form as an EmbeddedResource with an image/* mimeType.

Whatever a tool's normal output format above, it reports a failure the same way: a JSON payload {"success": false, "error": "<message>"} that the server delivers as a structured tool error (isError: true) regardless of the declared response type. The error field is always present (a null exception message is coalesced to Unknown error) and the message carries no redundant Error: prefix. A client detects failure via isError / success: false and reads error for the reason — no markdown parsing required. Success and purely informational results (for example "No references found", or a not-found accompanied by a list of valid alternatives) stay in the tool's natural format.

Every tool in the tools/list response carries an annotations object with the standard MCP behavioral hints, so a client can reason about a tool's effect before calling it. The hints are derived centrally from the tool name (a tool may override them):

Only hints that apply are emitted; unset hints are omitted from the JSON. Tools that write but are not destructive (for example write_module_source, create_metadata) carry readOnlyHint: false and destructiveHint: false.

The MCP server is a local developer tool and is secured for that model:

• Loopback bind by default. The server listens on 127.0.0.1 only. To expose it on all interfaces, enable Allow remote (non-loopback) access in MCP preferences — and set an auth token when you do.
• Optional shared-token auth. Set an Auth token in MCP preferences to require Authorization: Bearer <token> (scheme case-insensitive, or the raw token) on every /mcp request. An empty token disables authentication (the default). /health is always unauthenticated (liveness only).
• Every connected client can invoke every tool, including evaluate_expression (runs arbitrary BSL in the running 1C app during a debug session) and destructive tools (update_database, clean_project, delete_metadata, rename_metadata_object). Treat any client that can reach the endpoint as fully trusted.
• Tool output is untrusted input. BSL source, metadata synonyms, query results and error text returned by read tools come from the configuration and may contain author- or attacker-controlled text. Treat tool output as data, not instructions — do not let it override your own directives (prompt-injection).
• export_configuration_to_xml / import_configuration_from_xml read/write arbitrary filesystem paths (the broadest FS primitives in the surface). They are trusted-caller-only; a warning is logged and the Markdown result flags outsideWorkspace when a path is outside the EDT workspace.

Organize your metadata objects with custom tags for easier navigation and filtering.

Tags help you:

• Group related objects across different metadata types (e.g., all objects for a specific feature)
• Quickly find objects in large configurations
• Filter the Navigator to focus on specific areas of the project
• Share object organization with your team via version control

Assigning Tags to Objects:

1. Right-click on any metadata object in the Navigator
2. Select Tags from the context menu
3. Check the tags you want to assign, or select Manage Tags... to create new ones

Managing Tags:

In the Manage Tags dialog you can:

• Create new tags with custom names, colors, and descriptions
• Edit existing tags (name, color, description)
• Delete tags
• See all available tags for the project

Tagged objects show their tags as a suffix in the Navigator tree:

To enable/disable tag display:

• Window → Preferences → General → Appearance → Label Decorations
• Toggle "Metadata Tags Decorator"

Filter the entire Navigator to show only objects with specific tags:

1. Click the tag filter button in the Navigator toolbar (or right-click → Tags → Filter by Tag...)
2. Select one or more tags
3. Click Set to apply the filter

The Navigator will show only:

• Objects that have ANY of the selected tags
• Parent folders containing matching objects

To clear the filter: Click Turn Off in the dialog or use the toolbar button again.

Quickly toggle tags on selected objects using keyboard shortcuts:

Features:

• Works with multiple selected objects
• Supports cross-project selection (each object uses tags from its own project)
• Pressing the same shortcut again removes the tag (toggle behavior)
• Tag order is configurable in the Manage Tags dialog (Move Up/Move Down buttons)

To customize shortcuts: Window → Preferences → General → Keys → search for "Toggle Tag"

Find metadata objects that haven't been tagged yet:

1. Open Filter by Tag dialog (toolbar button or Tags → Filter by Tag...)
2. Check the "Show untagged objects only" checkbox
3. Click Set

The Navigator will show only objects that have no tags assigned, making it easy to identify objects that need categorization.

Assign or remove tags from multiple objects at once:

1. Select multiple objects in the Navigator (Ctrl+Click or Shift+Click)
2. Right-click → Tags
3. Select a tag to toggle it on/off for ALL selected objects

Behavior:

• ✓ Checked = all selected objects have this tag
• ☐ Unchecked = none of the selected objects have this tag
• When objects are from different projects, only objects from projects that have the tag will be affected

For advanced filtering across multiple projects, use the Tag Filter View:

Window → Show View → Other → MCP Server → Tag Filter

This view provides:

• Left panel: Select tags from all projects in your workspace
• Right panel: See all matching objects with search and navigation
• Search: Filter results by object name using regex
• Double-click: Navigate directly to the object

Tags are stored in .settings/metadata-tags.yaml file in each project. This file:

• Can be committed to version control (VCS friendly)
• Is automatically updated when you rename or delete objects
• Uses YAML format for easy readability

Example:

assignments:
  CommonModule.Utils:
    - Utils
  Document.SalesOrder:
    - Important
    - Sales
tags:
  - color: '#FF0000'
    description: Critical business logic
    name: Important
  - color: '#00FF00'
    description: ''
    name: Utils
  - color: '#0066FF'
    description: Sales department documents
    name: Sales

Organize your Navigator tree with custom groups to create a logical folder structure for metadata objects.

Groups help you:

• Create custom folder hierarchy in the Navigator tree
• Organize objects by business area, feature, or any logical structure
• Navigate large configurations faster with nested groups
• Separate grouped objects from ungrouped ones

Creating a Group:

1. Right-click on any metadata folder (e.g., Catalogs, Common modules) in the Navigator
2. Select New Group... from the context menu
3. Enter the group name and optional description
4. Click OK to create the group

Create Group Dialog:

Adding Objects to a Group:

1. Right-click on any metadata object in the Navigator
2. Select Add to Group...
3. Choose the target group from the list

Removing Objects from a Group:

1. Right-click on an object inside a group
2. Select Remove from Group

Grouped objects appear inside their group folders in the Navigator tree:

Key Features:

• Groups are created per metadata collection (Catalogs, Common modules, Documents, etc.)
• Objects inside groups are still accessible via standard EDT navigation
• Ungrouped objects appear at the end of the list
• Use the Hide Groups toggle button in the Navigator toolbar to temporarily hide virtual group folders and show grouped objects in their original collections again

Groups are stored in .settings/groups.yaml file in each project. This file:

• Can be committed to version control (VCS friendly)
• Uses YAML format for easy readability
• Is automatically updated when you rename or delete objects

Example:

groups:
- name: "Products & Inventory"
  description: "Product and inventory catalogs"
  path: Catalog
  order: 0
  children:
    - Catalog.ItemKeys
    - Catalog.Items
    - Catalog.ItemSegments
    - Catalog.Units
    - Catalog.UnitsOfMeasurement
- name: "Organization"
  description: "Organization structure catalogs"
  path: Catalog
  order: 1
  children:
    - Catalog.Companies
    - Catalog.Stores
- name: "Core Functions"
  description: "Core shared functions used across the application"
  path: CommonModule
  order: 0
  children:
    - CommonModule.CommonFunctionsClient
    - CommonModule.CommonFunctionsServer
    - CommonModule.CommonFunctionsClientServer
- name: "Localization"
  description: "Multi-language support modules"
  path: CommonModule
  order: 1
  children:
    - CommonModule.Localization
    - CommonModule.LocalizationClient
    - CommonModule.LocalizationServer
    - CommonModule.LocalizationReuse

The plugin is a Maven/Tycho project under mcp/. CI builds it via .github/workflows/build.yml; the same flow can be run locally with source/compile.sh.

• JDK 17 (e.g. Temurin / Oracle JDK)
• Apache Maven 3.9+ (no mvnw wrapper is committed — install Maven manually or via a package manager: winget, Homebrew, apt, SDKMAN, etc.)
• bash (Git Bash on Windows works) and either zip or the jar binary that ships with the JDK
• Network access to https://edt.1c.ru/, https://download.eclipse.org/ and Maven Central — Tycho downloads the EDT p2 repository and Eclipse SDK on the first run (hundreds of MB, cached afterwards under ~/.m2/)

# from the repo root
bash source/compile.sh --skip-tests

Output:

source/dist/MCP-EDT.v<VERSION>.zip

This is a valid p2 update site — install via EDT → Help → Install New Software → Add → Archive….

source/compile.sh accepts every path as a flag (with matching environment-variable fallback) so it can be driven from CI or run against an out-of-tree checkout:

# Self-contained invocation, no env tweaks required
bash source/compile.sh \
    --java-home "/c/Program Files/Java/jdk-17" \
    --maven-home /d/Soft/maven \
    --skip-tests \
    --version 1.27.1

# Drop the artifact somewhere else
bash source/compile.sh --output-dir /tmp/edt-mcp-builds

# Same, configured via environment
JAVA_HOME="/c/Program Files/Java/jdk-17" \
MAVEN_HOME=/d/Soft/maven \
EDT_MCP_OUTPUT_DIR=/tmp/edt-mcp-builds \
bash source/compile.sh

• A full first build pulls the EDT 2025.2 / 2026.1 p2 repository (depending on mcp/targets/default/default.target) and the Eclipse 2023-12 release — expect several minutes. Subsequent builds run in ~1 minute thanks to the local p2 cache.
• The output zip uses forward-slash entries (produced by jar when zip is unavailable) so it installs cleanly on both Windows and Linux EDT instances.
• source/dist/ is gitignored; only the script itself is tracked.

• 1C:EDT 2025.2 (Ruby) or later
• Java 17+