/installmcp

description: Download the 1C MCP server distribution from vibecoding1c.ru and install all servers from it
userOnly: true

/installmcp — install MCP servers from the vibecoding1c.ru distribution

This command performs the first-time installation of 1C MCP servers. It downloads the distribution from `https://vibecoding1c.ru/mcpserver` via the (undocumented but stable) Tilda Members API — `POST /api/login/` → `POST /api/getpage/` → extract the Yandex Disk public link from the rendered HTML → fetch via the Yandex Disk Public API — all in pure PowerShell (~3 seconds, no browser). Falls back to a browser-automation MCP only if the Tilda API path fails (captcha, login_blocked, API change). The unpacked archive is then installed step by step per the bundled instructions.

The unpacked distribution layout is the canonical `MCP_Distr` layout (typical local example: `C:\Work\MCP_Distr`):

MCP_Distr/
├── INSTALL.md                          ← Main instruction (read in full)
├── config.env                          ← All settings (license keys, paths, API keys)
├── servers/
│   ├── 01_HelpSearchServer.md          ← 1C platform help
│   ├── 02_GraphMetadataSearch.md       ← Graph-based metadata search
│   ├── 03_CodeMetadataSearchServer.md  ← Metadata + code search
│   ├── 04_SSLSearchServer.md           ← SSL/БСП search
│   ├── 05_TemplatesSearchServer.md     ← 1C code templates
│   ├── 06_SyntaxCheckServer.md         ← BSL syntax check
│   └── 07_1CCodeChecker.md             ← 1С:Напарник code review
└── Graph_metadata_search/
    ├── docker-compose.yml              ← Compose for GraphMetadata + Neo4j
    └── .env                            ← Graph parameters (filled from config.env)

Use `/setupmcp` (`content/commands/setupmcp.md`) to connect already installed servers and available memory to a new repository by their actual addresses. Use `/checkmcp` to inspect those connections. Use `/updatemcp` to update an already installed set (and to re-fetch a newer distribution + new license keys).

Before selecting a target or running Docker, load `content/rules/mcp-deployment.md`. Local installation is the ordinary path; an optional shared Debian/Ubuntu Docker Engine host is equally valid. Resolve the target in the initial installation question, before downloading/unpacking; distinguish a local download staging directory from the installation root on the Docker host. Adapt shell/path syntax to the selected OS; the PowerShell download flow can run on a Windows client without making that client the Docker host. On a host without PowerShell use the documented browser/manual download fallback, not a Docker Desktop requirement. Existing endpoints route to `/setupmcp` without a download.

Image variant (`IMAGE_VARIANT` / `IMAGE_TAG`)

**This section is the canon for image tags.** `/updatemcp`, `/checkmcp` and `/installtools` point here instead of repeating it.

Since 27.09.2026 the images have one channel — stable. Every 1C MCP server image is published under variant tags; the variant is **only the docker tag** — same repository, same container names, same ports, same `config.env`:

| Variant | Tag | Pick it when | |---|---|---| | full (default) | `latest` | обычная установка на x86-64 хосте | | slim | `light` | нужен облегчённый образ; что именно из него исключено — только по `servers\NN_*.md` дистрибутива, не по догадке | | ARM | `arm64` | хост на ARM64 (Apple Silicon, ARM-сервер) |

The variant lives in `<TARGET>\config.env`: `IMAGE_VARIANT` (`latest` / `light` / `arm64`), with an optional `IMAGE_TAG` that, when non-empty, overrides it verbatim (normally empty). The effective tag is `IMAGE_TAG` if set, else `IMAGE_VARIANT`. An older `config.env` with only `IMAGE_TAG` keeps working through that key. Never hardcode a tag into the `docker run` lines.

Tags with a `-beta` suffix (`latest-beta`, `light-beta`, `arm64-beta`) are **no longer published or supported**: the former beta images became the tags above. Never write such a tag; a `config.env` or container that still carries one is migrated by `/updatemcp` to the same variant without the suffix.

**External installs (`INSTALL.md` mode 3).** When the servers are managed outside this project (`BASESAI_MCP_GLOBAL_ROOT` / `MCP_GLOBAL_ROOT` + `install.manifest.json`), the keys live in the distribution's **global** `config.env` (`artifacts.global_config` of the manifest, default `<GLOBAL_ROOT>\config.env`) and the containers belong to that installer. Change the variant there, through the distribution's own `INSTALL.md` — do not recreate its containers from this command.

Which tags exist

Verified on Docker Hub on **2026-09-29**; treat as a snapshot, not as a contract — always verify before pulling:

| Image | Tags | |---|---| | `comol/1c_help_mcp` | `latest`, `light`, `arm64` | | `comol/1c_code_metadata_mcp` | `latest`, `light`, `arm64` | | `comol/1c_graph_metadata` | `latest`, `light`, `arm64` | | `comol/mcp_ssl_server` | `latest`, `light`, `arm64` | | `comol/template-search-mcp` | `latest`, `light`, `arm64` | | `comol/1c-code-checker` | `latest`, `light`, `arm64` | | `comol/1c_syntaxcheck_mcp` | `latest`, `arm64` |

SyntaxCheckServer has no `light`: with `IMAGE_VARIANT=light` use `latest` for it on x86-64 (`arm64` on ARM). Other archival tags on Docker Hub (dated or build tags) are not install targets. **Image names come from `<TARGET>\servers\NN_*.md`, not from this table** — the table only says which tags that image publishes. When a per-server file pins the tag literally (`comol/1c_help_mcp:latest`), substitute **only the tag part** with the effective tag and leave the repository name exactly as the distribution wrote it.

Verify the tag before pulling

A missing tag fails the pull with `manifest unknown` after the user already confirmed a multi-GB download. Check first:

function Get-McpImageTags {
    param([string]$Repo)                      # e.g. 'comol/1c_help_mcp'
    try {
        (Invoke-RestMethod "https://hub