EDT-MCP工具

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
   

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.

Installation

From Windows command line</strong> - "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

<details> Once the installation has been completed successfully, we will see the following:

</details>

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

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: Optional override for the check descriptions that ship with the plugin. Leave it empty to use the bundled ones; point it at a folder to replace or translate individual checks (a file found there wins, per check)
• 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)
• Enhance Navigator: Controls this plugin’s contributions to the Navigator tree (groups and their filter). Turn it off to resolve conflicts with another plugin that patches the same panel
• 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. The endpoint line shows the real URL for the port the server is actually serving, with Copy URL and Copy config (type/url) buttons — the latter puts a ready mcpServers JSON entry on the clipboard for agents that are configured only by editing a file. That entry is the type/url form (Cursor, VS Code, Claude Code); Cline, Antigravity and OpenCode need the different shapes shown in their sections below. If an auth token is saved, the entry carries it as an Authorization header (it would get a 401 otherwise), so treat the copied text as a secret

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.

Cline - extension for VSCode.

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

XDTO Packages

1C XDTO packages (XDTOPackage) can be authored end-to-end through MCP, down to their package-local structure, without hand-editing XML:

- create_metadata / modify_metadata / delete_metadata address XDTO package members by FQN, layered on top of the existing top-level XDTOPackage.<Name> create/delete: - XDTOPackage.<Package>.ObjectType.<Type> — an ObjectType in the package (optional flags: open, abstract, mixed, ordered, sequenced). - XDTOPackage.<Package>.Property.<Name> — a package-global Property. - XDTOPackage.<Package>.ObjectType.<Type>.Property.<Name> — a Property nested in an ObjectType.

A Property's type accepts a built-in XSD type name (e.g. string), the exact name of another ObjectType already in the same package (a same-package reference), or an explicit {nsUri, name} pair; optional lowerBound/upperBound, nillable, fixed+default round out the vocabulary. See get_tool_guide('create_metadata') for the full parameter list. - validate_xdto_package runs EDT's own configuration validation scoped to one package and returns a one-line verdict — valid, problems found, or undecided when nothing matched but a marker's location could not be resolved — plus any problems found (e.g. a Property left referencing an ObjectType that was since deleted) — a thin, read-only wrapper over get_project_errors, handy right after authoring or editing package members.

VS Code / GitHub Copilot

Create .vscode/mcp.json:

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

<details> <summary><strong>Other AI Assistants</strong> - Cursor, Claude Code, Claude Desktop</summary>

Comparison

Read a three-way configuration comparison: start one against two git revisions, expand a node's differences, and read or author the merge-rules file EDT re-applies. Nothing is ever merged - running a merge stays a human action in EDT's comparison window.

Three-way configuration comparison

A configuration can be compared against two git revisions and read node by node through MCP. The family is read-only about your project: it never merges and never writes the project — the plugin holds no merge starter at all, so running a merge stays a human action in EDT's comparison window.

- compare_configurations starts the comparison and returns a jobId; poll it with get_job_status. The sides are main — the project's WORKING TREE as EDT currently has it, uncommitted edits included — other (otherRevision) and ancestor (ancestorRevision), each anything git resolves in that repository: a branch, a tag, HEAD~1, a commit id. Beyond projectName / otherRevision / ancestorRevision it takes scope (qualified names such as Catalog.Products, Russian type tokens accepted; omitting it compares the WHOLE configuration), mergeRulesFile (decisions applied BEFORE the comparison starts — the file is read, never written), waitSeconds (0 to 25, default 5 — how long THIS call waits for its job snapshot, never the job's own budget), limit (how many top objects the report lists; the counters above the table always describe the whole comparison) and changedOnly (default true; a node that has not been compared yet is listed anyway, because "not answered yet" is not "equal"). - get_comparison_node expands ONE node of that comparison: a three-way property table, the per-side form structure, the module section list, the vendor-support state, the child outline and the engine's POTENTIAL problems. Address the node by objectFqn (Russian or English type tokens both work) or by nodeId from the report, never both; side (main by default, other, ancestor) says which side the FQN is written in; depth (1 to 5), limit (1 to 500) and waitSeconds (0 to 25) size the answer. The comparison tree is built lazily, so a subtree the engine has not reached is reported as unfinished — never as "no differences". - merge_rules reads and authors the sparse XML merge-rules file the comparison saves and re-applies when it is launched with it. mode is read or write; filePath is absolute, and for a WRITE its extension must be spelled in LOWER CASE, because EDT's own reader compares it case-sensitively — mode: "read" and basedOn are lenient about case, since those files are opened by this server and never by the platform (read takes the .xml or the .zip a comparison saves; write takes .zip, which every supported EDT reads, or .xml, which EDT 2026.1 reads and EDT 2026.2 refuses outright; a .zip carries ONE entry, named by the exact string <main>_<other>_<ancestor> over the three project names, so a later comparison over the same three projects re-applies it even with other revisions — and since _ is legal inside a project name that string is not unique to one triple, so a comparison finds nothing here only when its OWN three names spell something else; and an existing file is replaced only when basedOn names that SAME file — any other write over an existing file is refused); basedOn carries an existing file's decisions forward; decisions is [{path, rule}], where path is the key chain below the root ([] = the whole configuration, ["commonModules"] = a collection, and ["commonModules","Alpha:Beta:Gamma"] = one object, keyed by its main:other:ancestor names with NONE for a side that has no such object) and rule is one of GetFromOther, DoNotMerge, MergePrioritizingMain, MergePrioritizingOther; comparisonId and limit complete the list. Authoring the DOCUMENT needs no running comparison; naming a .zip's entry does, so a .zip is refused without one. The report names the container it wrote and which EDT reads it, and it says which of THREE validation outcomes happened: a comparison whose tree has FINISHED checks every rule against what its own node allows; a comparison that answers while its tree cannot be read names the zip's entry but checks nothing — reported NOT VALIDATED, or refused outright if you passed comparisonId; with no comparison at all the file is authored from names and also reported NOT VALIDATED.

One comparison at a time, and it stays open when it finishes. EDT runs exactly one comparison per workbench, so a second compare_configurations while one is live is refused naming the live comparison — it is never queued, and a refusal means nothing was started. A comparison that has FINISHED still holds that single slot, because its session is what get_comparison_node reads. cancel_job cannot end it then: once the comparison finishes its background job is terminal, and a terminal job is answered without this tool's cancellation handler ever running. Give the slot back by calling compare_configurations with releaseComparisonId alone; cancel_job is the right call only while the comparison is still RUNNING. A comparison nobody comes back to is reclaimed by an idle TTL of 30 minutes as part of answering the next launch, so a forgotten one delays the next comparison rather than blocking it until EDT restarts.