# MCP сервер что это и как запустить: 8 правил безопасной команды

> MCP-сервер связывает AI-клиент с локальной командой. Разбираю минимальную безопасную конструкцию, JSON-конфигурацию, запуск через stdio и причины типичных поломок.

Источник: https://vibeceh.ru/guides/mcp-svoj-server-bez-zavisimostej-dlya-bezopasnoj-lokalnoj-komandy
Автор: Сергей Мазур · опубликовано 2026-08-17

Коротко: MCP-сервер, или ответ на вопрос «mcp сервер что это», это локальная программа, которой AI-клиент разрешает вызвать конкретную команду. AI-клиент запускает MCP-клиент, тот держит соединение с сервером, а модель получает список доступных tools. Вызов ограничен интерфейсом и схемой инструмента, но контекст может включать другие данные MCP. Для первого эксперимента я не подключаю интернет: беру одну функцию, один исполняемый файл и транспорт `stdio`. Не передавай секреты в аргументы tool без необходимости: права процесса определяются окружением и разрешениями ОС.

> [!tip] Хочешь собрать свои локальные инструменты без лишнего runtime? В практикуме по вайб-кодингу для предпринимателей есть отдельный маршрут от идеи до рабочего инструмента.

## Что такое MCP-сервер и зачем он нужен?

[MCP](/concepts/mcp) сервер связывает AI-приложение с внешними инструментами и данными через отдельный процесс. Если нужно сначала разобраться в базовом термине, открой [объяснение MCP](/concepts/mcp). Host, например Claude или другое AI-приложение, создаёт отдельный MCP-клиент для каждого сервера. Клиент запускает сервер, поддерживает соединение и передаёт модели доступные tools. Локальный режим работает через `stdio`, без сетевого порта.

Представь связку из трёх частей:

- **Host** - AI-приложение, в котором ты работаешь.
- **MCP-клиент** - часть host, которая подключается к конкретному серверу.
- **MCP-сервер** - отдельная программа с инструментами и данными.

Модель не запускает программу напрямую: она видит описание инструмента и предлагает его вызвать, после чего Host показывает запрос, MCP-клиент передаёт вызов серверу, а сервер возвращает результат.

Официальная документация описывает MCP так:

MCP - это открытый стандарт для подключения AI-приложений к внешним системам, перевод автора.

В локальном сценарии сервер не обязан быть сайтом, API или постоянно работающим фоновым процессом. Клиент сам запускает отдельный процесс и общается с ним через стандартные потоки. Сеть и отдельный порт не нужны.

Например, ты просишь агента проверить статус проекта. Вместо свободного доступа к терминалу клиент передаёт модели одну команду `project_status`. Сервер получает разрешённый путь, выполняет заранее заданное действие и возвращает результат.

Именно здесь MCP полезнее обычной инструкции в чате. Команда становится доступной модели в понятной форме. При этом границу задаёт сама программа.

> [!tip] Если хочешь пройти этот сценарий с поддержкой, практикум по вайб-кодингу для предпринимателей поможет собрать рабочий локальный инструмент и проверить его по шагам.

Не подключай сразу файловый сервер, Git, память и внешние API. Одна команда проще для проверки и оставляет меньше полномочий у локального процесса.

Если после этого захочешь расширить сценарий, [проверь MCP до подключения](/guides/mcp-proverit-instrument-agenta-do-vydachi-dostupa) по отдельному чек-листу безопасности.

## Можно ли запустить MCP локально без лишних зависимостей?

да, если под «без зависимостей» ты имеешь в виду один статический бинарник без внешнего Node.js или Python runtime. Библиотеки внутри сборки при этом могут быть. Python- и TypeScript-примеры обычно требуют SDK, пакеты и подходящее окружение, поэтому их нельзя называть полностью автономными в том же смысле.

Если ищешь примеры по запросу «разработка mcp», то чаще всего увидишь Python или TypeScript. Это нормальный путь, но он не равен zero-dependency:

- Python-сервер использует Python и пакет `mcp`.
- TypeScript-сервер использует Node.js, SDK и дополнительные пакеты.
- готовый статический бинарник запускается напрямую, без установки этих runtime.

В README `mcp-stama` формулировка звучит так:

“Blazingly fast, zero-dependency, single static Rust binary built for Cursor, Claude Desktop, and Windsurf.”

Перевод автора: «Молниеносный MCP-сервер без внешних runtime-зависимостей, собранный в один статический бинарник Rust для Cursor, Claude Desktop и Windsurf».

Но внутри проекта всё равно есть Rust-зависимости, включая `ignore`, `gix`, `bollard` и `sysinfo`. Они попадают в сборку. Точнее сказать так: бинарнику не нужен внешний runtime, потому что библиотеки уже входят в сборку.

У этого различия практическое последствие. Если ты скачал готовый бинарник, для запуска достаточно дать клиенту путь к файлу. Если ты собираешь сервер из исходников, понадобятся язык, сборщик и зависимости проекта.

Проверенного официального примера ручной реализации MCP на чистом стандартном runtime без SDK в фактуре нет. Поэтому я не буду выдавать короткий самодельный JSON-RPC-файл за готовое универсальное решение. Для первой проверки подойдёт SDK-пример на Python. Для автономного запуска нужен уже собранный бинарник.

## Что должна делать одна безопасная команда?

одна безопасная команда принимает узкий набор аргументов, выполняет заранее известное действие и возвращает результат без произвольного shell-ввода. Её доступ к файлам и сети ограничен заранее. Для первого сервера я бы оставил одну read-only tool-функцию, запуск через `stdio`, проверку входа и логи только в `stderr`.

![Кот удивлённо смотрит на карточки с правилами одной безопасной команды.](https://s3.regru.cloud/crossmark/statejnik/images/guides/mcp-svoj-server-bez-zavisimostej-dlya-bezopasnoj-lokalnoj-komandy/kadr-1.webp)

Минимальная конструкция выглядит так:

1. Один локальный MCP-сервер.
2. Одна tool-функция.
3. Узкая схема входных данных.
4. Заранее определённое действие.
5. Ограниченный доступ к конкретной директории.
6. Запрет строк вроде `bash -c`, `sh -c` и `cmd /c`.
7. Логи в `stderr`.

Я закладываю запрет лишнего уже в схему входа, а потом повторяю проверку внутри функции. Если команде нужен путь к проекту, не принимай любую строку без проверки. Сравни путь с разрешённой директорией. Если нужен режим работы, перечисли допустимые значения вместо свободного текста.

Есть неприятная деталь: описание JSON Schema само по себе не гарантирует, что обработчик получит правильные данные. Модель может передать `null`, пустой массив или неподходящую форму. Поэтому проверяй аргументы внутри самой функции.

MCP-спецификация формулирует риск прямо:

“Tools represent arbitrary code execution and must be treated with appropriate caution.”

Перевод автора: «Инструменты представляют произвольное выполнение кода, поэтому с ними нужно обращаться осторожно».

Не передавай в tool команду целиком. Опасный вариант выглядит так:

```text
run_shell("проверь статус и потом удали временные файлы")
```

Здесь модель фактически получает возможность сформировать действие. Безопаснее зарегистрировать конкретную функцию:

```text
project_status(repo_path)
```

Внутри неё нет выбора программы. Нет shell. Нет удаления. Есть только проверка пути и заранее написанная логика чтения статуса.

Я бы не брал первым примером полноценный filesystem-сервер. В официальном [filesystem-сервере](https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem) есть чтение, запись, поиск, перемещение и другие операции. Он умеет ограничивать каталоги, но поверхность действий всё равно большая. Для первого подключения лучше взять одну read-only команду.

## Как выглядит простой MCP-сервер для локального запуска?

минимальный пример можно свести к tool `add`. Функция получает два числовых аргумента, складывает их и возвращает результат. Такой сервер удобен для проверки объявления инструмента, запуска процесса и вызова через клиент. Но он не показывает работу с файлами, каталогами, правами и ограничением доступа к проекту.

В официальном [Python SDK](https://github.com/modelcontextprotocol/python-sdk) пример выглядит так:

```python
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("Demo", json_response=True)

@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b
```

Логика здесь прозрачная:

- `add` - имя tool;
- `a` и `b` - два входных аргумента;
- тип `int` задаёт ожидаемый формат;
- результатом становится сумма.

Такой пример быстро ловит базовые ошибки при разработке MCP. Клиент должен увидеть сервер, получить список tools, показать `add` и вернуть результат вызова. Если вместо этого происходит disconnect, проблема, скорее всего, в запуске, окружении или протоколе, а не в бизнес-логике.

Это хороший первый шаг для проверки MCP. Доступа к файлам пример не даёт: у функции нет пути, каталога и операции чтения. Она не доказывает, что сервер умеет безопасно работать с файловой системой.

Потом можно заменить тело на конкретное локальное действие. Но я бы не расширял интерфейс сразу. Сначала проверь `2 + 3 = 5`. Затем добавь одну операцию чтения. После каждого изменения снова проверь список tools и один вызов.

## Настройка MCP: где лежит JSON-конфигурация и что в ней проверить?

JSON-конфигурация описывает сервер внутри объекта `mcpServers`. Для каждого имени указываются `command` и `args`. В `command` лежит запускаемая программа, в `args` - её аргументы. Абсолютный путь снижает зависимость от текущей папки и окружения клиента. Файл конфигурации зависит от host и его scope.

Когда я настраиваю MCP, сначала проверяю несколько конкретных полей. Если ты пришёл по запросу «mcp настройка», начни с той же проверки:

```json
{
  "mcpServers": {
    "safe-command": {
      "command": "/absolute/path/to/safe-command",
      "args": []
    }
  }
}
```

`safe-command` - имя, под которым сервер появится в клиенте. Оно не обязано совпадать с именем бинарника.

`command` - программа, которую запускает клиент. Для собственного бинарника укажи полный путь. Не рассчитывай, что приложение найдёт файл через `PATH`.

`args` - аргументы запуска. Если серверу нужна фиксированная папка, её можно передать здесь, но сама программа всё равно должна проверить значение.

В Windows путь записывай одним из двух способов:

```json
{
  "command": "C:/Users/me/mcp/safe-command.exe",
  "args": []
}
```

или:

```json
{
  "command": "C:\\Users\\me\\mcp\\safe-command.exe",
  "args": []
}
```

Строка с одиночными обратными слешами может сломать JSON из-за escape-последовательностей.

Конфигурация приложения и конфигурация проекта не одно и то же. В quickstart user guide для Claude Desktop указаны такие расположения: [quickstart user guide](https://github.com/modelcontextprotocol/docs/blob/main/quickstart/user.mdx)

```text
macOS:
~/Library/Application Support/Claude/claude_desktop_config.json

Windows:
%APPDATA%\Claude\claude_desktop_config.json
```

Claude Code использует scopes, как описано в [документации подключения Claude Code к MCP](https://docs.anthropic.com/en/docs/claude-code/mcp). Пользовательский scope доступен между проектами. Проектный сохраняется в `.mcp.json` конкретного проекта. Если сервер добавлен внутри одной папки, в другой он может не появиться.

Сначала определи, какой host запускает сервер: Claude Desktop, Claude Code или другой клиент. У каждого приложения своё окружение и способ хранения конфигурации.

В конфиг не клади секреты, если локальной команде они не нужны. Для первого сервера без внешних сервисов достаточно `command` и пустого `args`.

Практический промпт для проверки конфигурации:

Если клиент не видит сервер, не переписывай tool. Сначала проверь этот JSON и путь к программе.

## Сколько ресурсов может потреблять локальный MCP-бинарник?

README `mcp-stama` заявляет менее 10 MB RAM и cold start быстрее 2 ms. Для стандартных Node.js или Python-инструментов там же заявлены 200 MB и более RAM и 1-3 секунды запуска. Это авторские показатели без описанной методики и независимой проверки, поэтому я использую их как заявления проекта, а не как универсальный benchmark.

| Показатель | Заявление README, не независимый benchmark |
|---|---:|
| RAM `mcp-stama` | менее 10 MB |
| RAM стандартных Node.js или Python-инструментов | 200 MB и более |
| Cold start `mcp-stama` | менее 2 ms |
| Пробуждение стандартных инструментов | 1-3 секунды |
| Пакеты в legacy-вариантах | 100 и более |
| Cold start legacy MCP-серверов в таблице | 1 500-3 000 ms |

В README сравнение подано как преимущество одного статического Rust-бинарника. Это может быть полезной инженерной целью: не тянуть внешний runtime ради одной небольшой команды.

Но цифры нельзя переносить на любой Rust-сервер. На расход влияют сборка, операционная система, набор библиотек и конкретное действие tool. В самой фактуре нет конфигурации машины, методики измерений или независимого повторения.

Поэтому вывод остаётся практическим. Если задача узкая, один бинарник убирает отдельный слой окружения. Это упрощает запуск и диагностику. Но слово «быстрее» не заменяет проверку handshake, списка tools и реального вызова.

## Как запустить сервер и подключить его к AI-клиенту?

подготовь локальный исполняемый файл, проверь его абсолютный путь, добавь сервер в Claude Code через `claude mcp add --transport stdio`, полностью перезапусти клиент и проверь сначала список tools, затем один вызов. Такой порядок отделяет ошибку файла и окружения от ошибки самой tool-функции.

![Сиба-ину одобряет схему подключения MCP-сервера из трёх шагов.](https://s3.regru.cloud/crossmark/statejnik/images/guides/mcp-svoj-server-bez-zavisimostej-dlya-bezopasnoj-lokalnoj-komandy/kadr-2.webp)

Собери сервер или возьми готовый бинарник, который запускается напрямую. Для Python- и TypeScript-примеров зафиксируй runtime и путь к файлу, потому что графический клиент может не видеть окружение терминала.

Проверь запуск из терминала:

   ```bash
   /absolute/path/to/safe-command
   ```

Сервер может ждать сообщения и ничего не печатать в обычный вывод. Это не доказывает поломку. Для `stdio` такой процесс ждёт JSON-RPC от клиента.

Укажи полный путь к бинарнику или к программе с явным runtime. Не оставляй только `safe-command`, если клиент запускается из другого окружения.

Для Windows используй прямые слеши или экранированные обратные:

   ```text
   C:/Users/me/mcp/safe-command.exe
   ```

   ```text
   C:\\Users\\me\\mcp\\safe-command.exe
   ```

В Claude Code команда для локального stdio-сервера выглядит так:

   ```bash
   claude mcp add --transport stdio safe-command -- /absolute/path/to/safe-command
   ```

`--` отделяет параметры Claude Code от команды и её аргументов. Если серверу нужна фиксированная директория, передай её после разделителя:

   ```bash
   claude mcp add --transport stdio safe-command -- /absolute/path/to/safe-command /absolute/path/to/project
   ```

Для одного проекта используй проектный scope. Если сервер нужен в разных проектах, добавь пользовательский scope:

   ```bash
   claude mcp add --transport stdio --scope user safe-command -- /absolute/path/to/safe-command
   ```

   ```bash
   claude mcp add --transport stdio --scope project safe-command -- /absolute/path/to/safe-command
   ```

Не смешивай эти варианты во время первой проверки. Иначе сервер может быть подключён, но не в той папке, где запущен клиент.

Для Claude Desktop обычно требуется полный перезапуск: закрой клиент, включая процесс в трее, если он там остался, затем открой его заново. Для другого host проверь его инструкцию по перечитыванию MCP-конфигурации.

Выполни команду списка MCP-серверов или открой список подключённых tools в клиенте. На этом шаге проверяется запуск процесса и handshake. Если сервер не появился, не переходи к отладке результата команды.

Вызови одну зарегистрированную tool с простым допустимым аргументом. У калькулятора это `2` и `3`. Read-only команда должна получить заранее разрешённую директорию. Сверь фактический результат, а не сообщение «подключено».

Проверь журналы клиента и сервера. Диагностика должна идти в `stderr`, поэтому не добавляй отладочный текст в `stdout` ради удобства.

> [!warning] Inspector не равен клиенту
> Считай проверку в Inspector диагностической эвристикой: он запускает процесс в условиях текущего терминала, а Claude Desktop или другой графический клиент может использовать другое окружение. Поэтому Inspector не доказывает работу сервера в конкретном host. Проверка в Inspector не доказывает, что тот же путь и runtime доступны host.

Теперь добавь одну read-only tool, проверь `tools/list` и сделай один `tools/call`. Если соединение падает, первым делом убери вывод из `stdout`.

## Почему локальный MCP-сервер всё равно опасен?

защиту MCP я начинаю с проверки полномочий локального процесса. Если ты ищешь «mcp защита», смысл именно в этом: MCP-сервер запускается на той же машине, что и MCP-клиент, поэтому локальный режим сам по себе безопасность не гарантирует. Перед запуском проверь точную команду, оставь минимальные права, ограничь каталоги и сеть, убери секреты и выбирай `stdio` для локального сценария.

Официальная рекомендация описывает модель угроз без смягчений:

“Local MCP servers are binaries that are downloaded and executed on the same machine as the MCP client.”

Перевод автора: «Локальные MCP-серверы являются бинарными файлами, которые скачиваются и выполняются на той же машине, что и MCP-клиент».

Проверь риск по порядку:

1. Убедись, что сервер получает только нужные файлы.
2. Проверь, какие действия доступны с правами текущего пользователя.
3. Отдели текст из README, issue или сообщения от разрешенных инструкций.
4. Убедись, что строка не передается в shell как дополнительная команда.
5. Удали секреты из конфигурации и логов.

Для первой версии я бы зафиксировал такие ограничения:

1. Команда только read-only.
2. Путь только внутри заранее разрешённой директории.
3. Нет `bash -c`, `sh -c`, `cmd /c` и конкатенации shell-строк.
4. Нет токенов и паролей в конфигурации.
5. Нет сетевого доступа без отдельной причины.
6. Минимальные права процесса.
7. Явное подтверждение запуска и вызова.

`stdio` подходит для локального процесса, потому что клиент и сервер общаются напрямую через стандартные потоки. Перед выдачей доступа полезно сверить права с [чек-листом безопасной проверки MCP](/guides/mcp-proverit-instrument-agenta-do-vydachi-dostupa). HTTP добавляет сетевую поверхность и требует отдельной защиты, включая авторизацию или ограниченный IPC-механизм.

Размер tool сам по себе не делает её безопасной. Безопасность задают пределы действия. `add` почти нечего менять. Функция, которая принимает путь и вызывает shell, может сделать намного больше, даже если её код занимает несколько строк.

## Что ломается, если писать что-то в stdout?

в stdio-режиме `stdout` занят сообщениями JSON-RPC. Обычный `print`, `console.log`, стартовый текст или предупреждение зависимости попадает в тот же поток и портит его. Клиент ждёт JSON, получает обычную строку и может завершить соединение. Все диагностические сообщения отправляй в `stderr`.

![Мужчина закрывает лицо рядом со схемой потоков stdout, JSON-RPC и stderr.](https://s3.regru.cloud/crossmark/statejnik/images/guides/mcp-svoj-server-bez-zavisimostej-dlya-bezopasnoj-lokalnoj-komandy/kadr-3.webp)

Нельзя делать так:

```python
print("server started")
```

И так:

```javascript
console.log("server started");
```

Для логов используй другой поток:

```python
import sys

print("server started", file=sys.stderr)
```

```javascript
console.error("server started");
```

Официальная документация формулирует правило прямо:

“Never write to stdout. Writing to stdout will corrupt the JSON-RPC messages and break your server.”

Перевод автора: «Никогда не пиши в stdout. Запись в stdout испортит сообщения JSON-RPC и сломает сервер».

Проблема может быть не в твоём коде. Текст иногда печатает зависимость, драйвер или startup-обвязка. Поэтому сервер способен работать на одной машине и отключаться на другой, где отличается окружение или версия пакета.

Ожидаемый поток выглядит иначе:

```text
stdin  -> сообщения от MCP-клиента серверу
stdout -> сообщения JSON-RPC от сервера клиенту
stderr -> логи и диагностика
```

Не используй `stdout` для баннера, версии, предупреждения или отладочного значения. Если нужно понять, где сервер остановился, поставь запись в `stderr` перед проверкой входа и после завершения действия.

Для новичка симптом обычно выглядит обманчиво. Процесс стартует, сервер даже может появиться в списке, но handshake или первый вызов заканчивается disconnect. В таком случае первым делом убери весь посторонний вывод.

## Что делать, если клиент не видит сервер?

проверяй проблему от запуска к вызову. Начни с абсолютного пути и синтаксиса JSON, затем сравни окружение конкретного клиента, scope конфигурации и ручной запуск той же команды. После этого смотри журналы и полностью перезапускай приложение. Inspector может работать, потому что запускается из другой папки и с другим `PATH`. В [инструкции по безопасному допуску Claude Code к проекту](/guides/claude-code-bezopasnyy-dopusk-agenta-k-proektu) этот порядок дополнен проверкой границ доступа.

Иди по этому порядку:

1. Проверь абсолютный путь к бинарнику или runtime.
2. Убедись, что файл существует и имеет право на запуск.
3. Проверь JSON: `mcpServers`, `command`, `args`, слеши в Windows.
4. Определи, где лежит конфигурация именно этого host.
5. Проверь scope в Claude Code.
6. Запусти ту же команду вручную.
7. Посмотри журналы клиента и сервера.
8. Полностью перезапусти приложение.

Если `npx` работает в терминале, это ещё не значит, что его найдёт Claude Desktop. Графическое приложение не обязано наследовать настройки NVM, `asdf` или изменения `.zshrc` и `.bashrc`. Для такого случая используй абсолютный путь к `node` и файлу сервера либо готовый бинарник.

Если сервер подключён только в одной папке, проверь scope. Проектная конфигурация не обязана появляться в другом каталоге. Пользовательская доступна между проектами.

Если Inspector показывает tool, а Claude Desktop нет, сравни условия запуска и окружение:

- текущую директорию;
- `PATH`;
- виртуальное окружение;
- runtime;
- путь к конфигу;
- права на файл.

После изменения JSON перезапусти приложение целиком. Закрытие окна может оставить процесс активным, и старый конфиг продолжит использоваться.

Не начинай с переписывания сервера. Сначала докажи, что клиент запускает ту же команду, проходит `initialize`, получает `tools/list` и отправляет один `tools/call`. Если процесс не стартует, проблема не в описании tool. Если список tools приходит, но вызов ломается, переходи к аргументам, `stdout` и обработчику.

## Вопросы и ответы

локальный MCP-сценарий проще проверять по одной цепочке: исполняемый файл, конфигурация, запуск через `stdio`, список tools и один вызов. Большинство первых сбоев связано не с самой идеей MCP, а с неправильным scope, путём, окружением клиента, перезапуском или посторонним текстом в `stdout`.

В Claude Code добавь локальный процесс командой `claude mcp add --transport stdio safe-command -- /absolute/path/to/safe-command`. Это локальное подключение к процессу через `stdio`, а не через SSH. Если ты сравниваешь варианты по запросу «mcp ssh», SSH здесь не нужен. После добавления проверь scope, полностью перезапусти клиент и посмотри список tools. Разделитель `--` отделяет параметры Claude Code от команды и её аргументов.

Оставь одну read-only tool, ограничь каталог и набор аргументов, не передавай строки в shell, не храни секреты в конфиге и запускай процесс с минимальными правами. Для локального подключения используй `stdio`, а перед подтверждением проверь точную команду, которую клиент собирается выполнить. Затем вызови одну безопасную tool и проверь фактический результат, а не только статус подключения.

Передай серверу конкретную разрешённую директорию и проверяй путь внутри обработчика. Не выдавай доступ ко всему диску и не добавляй операции записи без необходимости. Универсальной portable-реализации allowlist для всех ОС и языков в фактуре нет, поэтому границы придётся задать в конкретной программе.

В приведённых источниках подтверждён локальный запуск через `stdio`: клиент сам запускает процесс и поддерживает соединение. Это не то же самое, что постоянно работающая служба `systemd` или Windows Service. Подтверждённого сценария для фонового сервиса здесь нет, поэтому первый эксперимент я бы оставил обычным: сначала проверь запуск и полный цикл подключения из клиента, а уже потом оценивай службу.

Самый короткий учебный пример, который я использую, это tool `add` на Python SDK. Она получает два числа и возвращает сумму, поэтому результат легко проверить как `2 + 3 = 5`. Внешний сервис не нужен, но нужны Python и пакет `mcp`. Пример удобен для проверки MCP, запуска процесса и первого вызова, но не показывает работу с файлами и ограничение доступа к каталогам.

У Claude Desktop путь зависит от системы: `~/Library/Application Support/Claude/claude_desktop_config.json` на macOS и `%APPDATA%\Claude\claude_desktop_config.json` на Windows. Claude Code использует свои scopes, то есть области действия настройки, и проектный `.mcp.json`. Другие клиенты могут хранить настройки иначе, поэтому сначала выбери конкретный host, затем проверь его путь и scope до перезапуска.

Подготовь исполняемый файл, укажи абсолютный путь в `command`, добавь аргументы в `args`, подключи процесс через `stdio`, перезапусти клиент и проверь `tools/list`, затем один `tools/call`. Проверка в Inspector отдельно не доказывает работу в графическом клиенте.

Для готового статического бинарника установка MCP не требует отдельного Node.js или Python runtime. Если ты ищешь «установка mcp», сначала проверь совместимость файла с системой и права на запуск, затем укажи абсолютный путь в конфигурации и проверь handshake, то есть первый обмен сообщениями клиента и сервера. Если сервер написан на Python или TypeScript, понадобятся соответствующие runtime, SDK и пакеты.

- [mcp-stama](https://github.com/StamManif/mcp-stama)
- [What is the Model Context Protocol?](https://docs.anthropic.com/en/docs/mcp)
- [Architecture overview](https://modelcontextprotocol.io/docs/learn/architecture)
- [Build an MCP server](https://modelcontextprotocol.io/docs/develop/build-server)
- [Connect Claude Code to tools via MCP](https://docs.anthropic.com/en/docs/claude-code/mcp)
- [Security Best Practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices)
- [MCP Specification](https://modelcontextprotocol.io/specification/2024-11-05/index)
- [MCP production gotchas](https://www.albinogeek.com/posts/mcp-5-production-gotchas)
- [Timeout Coordination](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1539)
- [MCP Servers Don't Work with NVM](https://github.com/modelcontextprotocol/servers/issues/64)
- [Claude Code MCP documentation](https://docs.anthropic.com/id/docs/claude-code/mcp)
- [MCP quickstart user guide](https://github.com/modelcontextprotocol/docs/blob/main/quickstart/user.mdx)