/installtools

description: Detect and optionally install the supported 1C development tools through one guided menu
userOnly: true

/installtools — guided tool installation

Use this command after installing the rules, and again after an update announces new tool installers. It detects the supported tools, explains what each one is for, asks one compact selection question, and then runs the corresponding standalone installer procedures.

This command is an orchestrator. Do not duplicate installation steps here and do not silently install anything.

Tool catalog and order

Always show tools in this order. The 1C MCP bundle is always first.

| # | Tool | Purpose | Recommend when | Standalone command | |---|---|---|---|---| | 1 | 1C MCP server bundle | Documentation, metadata and code search, syntax checks, templates/project memory, BSP search, graph analysis and code review | Recommended for every 1C project; this is the primary ruleset tool bundle and requires a purchased distribution | `/installmcp` | | 2 | Cognee memory MCP | Persistent agent memory; primary write destination whenever connected | Recommended when the user wants general cross-session memory; optional to install | `/install-cognee` | | 3 | OpenViking memory MCP | Persistent agent memory and context retrieval; searched alongside Cognee and other connected memory providers | Recommended when the user wants OpenViking context retrieval or a primary memory store without Cognee | `/install-openviking` | | 4 | EDT-MCP | Live access to the EDT workspace, errors, native refactoring, metadata/forms, launches and debugging | Recommended only when the user develops in a locally installed 1C:EDT | `/install-edt-mcp` | | 5 | agent-browser | Token-efficient browser automation based on accessibility snapshots | Recommended for automated tests of a published 1C web client | `/install-agent-browser` | | 6 | Windows-MCP | Windows desktop, mouse and keyboard automation | Last resort for thick-client or other non-web UI flows | `/install-windows-mcp` | | 7 | rtk | Third-party, user-global shell-output compression proxy — fewer tokens on every shell call (git, docker, platform commands) | Optional; only on explicit selection — also offered by `/economymode` | `/install-rtk` | | 8 | Atlassian MCP | Access to Jira issues and Confluence pages in Cloud or Server/Data Center | Optional for projects using Jira or Confluence | `/install-atlassian-mcp` | | 9 | OfficeCLI | Create, read and edit Word, Excel and PowerPoint files without Microsoft Office | Optional; recommended when the workflow includes `.docx`, `.xlsx` or `.pptx` documents | `/install-officecli` |

Do not list an optional tool as required merely because its installer exists.

Memory routing follows `content/rules/project-memory.md`, after `TOOL_*` policy (`content/rules/mcp-policy.md → Tool availability`). Installation, policy and runtime capability are separate: installing a provider neither enables it nor proves its tools callable.

Steps

1. Read-only detection

Inspect the active client and host without changing state. Classify each tool as `installed`, `not installed`, or `uncertain`; show its `auto / off / required` policy and session capability separately. Explicit status/install requests allow read-only detection even for `off`; never recommend/preselect those tools or rewrite policy as a side effect. The MCP bundle has separate provider keys, so preserve mixed settings.

Read `USE_EDT` from the project `.dev.env` before evaluating EDT tools. It is a project preference, not an installation probe:

• `true` — the project uses EDT; mark EDT-MCP as recommended.
• `false` — the project does not use EDT; keep EDT-MCP visible but do not recommend or preselect it.
• missing, empty or invalid — in the normal interactive command, ask once whether the project uses EDT and persist `USE_EDT=true|false` without changing any other `.dev.env` key. In `/installtools status`, report `USE_EDT: unknown` and do not ask or write.

• **1C MCP bundle:** check the current tool schema for known 1C MCP tools; then check client MCP configuration, `BASESAI_MCP_GLOBAL_ROOT` / `MCP_GLOBAL_ROOT` plus `install.manifest.json`, and relevant Docker containers. A ruleset-generated MCP config alone does not prove the purchased servers are installed or running.
• **Cognee:** check for exposed Cognee memory tools, a `cognee` / `cognee-memory` MCP entry, a `cognee-mcp` container, and the configured health endpoint (the standalone command defaults to `http://127.0.0.1:8010/health`).
• **OpenViking:** check for exposed OpenViking memory tools and an `openviking` MCP entry; inspect the configured installation manifest, `openviking-server --version` when already installed, and the configured health endpoint (default `http://127.0.0.1:1933/health`). For Docker inspect the existing container; for a remote endpoint do not require a local package/container. A healthy HTTP process alone does not verify model access or MCP memory operations. Do not install packages or start the service during detection.
• **EDT-MCP:** check for an `edt-mcp` / `EDT MCP Server` client entry and `http://127.0.0.1:8765/health`. A stopped EDT makes health inconclusive; do not report the plugin missing solely because EDT is closed.
• **agent-browser:** check `agent-browser --version` and the client MCP entry.
• **Windows-MCP:** on Windows, inspect the client MCP entry and exposed tools; do not use `uvx windows-mcp --help` for detection because it may install/run the package. On non-Windows, mark it `not applicable`.
• **rtk:** check `rtk --version` and `rtk init --show` (user-global; nothing in the project or in `.dev.env`).
• **Atlassian MCP:** inspect the active client's configuration for `mcp-atlassian` or another entry running the same server, and exposed Jira / Confluence tools. Check the configured local executable or Docker image without starting it; remote connections do not require a local package. Configuration alone does not prove s