Домашнее задание: Простой MCP-сервер

Данный репозиторий содержит полную реализацию домашнего задания по созданию и интеграции кастомного MCP-сервера (Model Context Protocol). Наш сервер разработан в соответствии с высокими стандартами безопасности (Command Whitelisting, Path Traversal Prevention) и принципами Context7 (передача модели компактного, высокоструктурированного контекста вместо сырого шума).

📖 Принципы работы Model Context Protocol (MCP)

1. Как IDE/Агент подключается к MCP-серверу

Интеграция между клиентом (IDE, чат-агент, Claude Desktop) и MCP-сервером происходит по спецификации JSON-RPC 2.0. Клиент выступает инициатором подключения и может использовать два стандартных транспорта:

• Stdio Transport: IDE запускает сервер как дочерний процесс (subprocess) и общается с ним через стандартный поток ввода (stdin) и стандартный поток вывода (stdout). Любой вывод отладочной информации (print, логгер) обязан перенаправляться в поток стандартной ошибки (stderr), чтобы не повредить бинарный поток JSON-RPC. Это критическое требование, реализованное в нашем сервере.

• HTTP/SSE Transport: Сервер запускает легковесный веб-сервер (внутри FastMCP на базе FastAPI и sse-starlette), а клиент подключается через HTTP-запросы и получает поток событий сервера через Server-Sent Events (SSE).

2. Что считается «инструментом» (Tool) на сервере

Инструмент — это декларативная функция на стороне сервера, которая:

1. Описывает себя с помощью понятного человекочитаемого имени и подробного описания (docstring).

2. Имеет строго типизированную схему параметров (на базе JSON Schema или моделей Pydantic).

3. Принимает входные параметры от модели, выполняет локальные вычисления, чтение файлов или вызов безопасных утилит операционной системы.

4. Возвращает строго структурированный JSON-ответ (объект или список), а не плоский текст. Это позволяет LLM-модели гранулярно вычленять нужные параметры и строить дальнейшую логику рассуждений (Context-Rich Reasoning).

🛠 Реализованные инструменты (Tools)

В сервере зарегистрировано 4 мощных инструмента, соответствующих различным подходам Context7:

1. 🖥 check_service_status (DevOps/Tooling)

   • Описание: Проверяет статус системного Linux-сервиса через systemctl и возвращает структурированный ответ с состоянием.

   • Безопасность: Запрещает использование спецсимволов для исключения инъекций shell-команд. Выполняется строго без использования shell=True.

2. 📂 get_doc_context (Doc/Code Context)

   • Описание: Выполняет умный поиск в локальной папке docs/ и выдает точную markdown-выжимку по архитектуре, лучшим практикам или принципам Context7.

   • Безопасность: Защищен от Path Traversal. Путь резолвится и валидируется на вхождение в корневой каталог проекта.

3. 🔍 search_project_files (Project Helper)

   • Описание: Рекурсивно ищет вхождения заданной строки во всех файлах проекта, игнорируя системные папки .git и .venv.

   • Безопасность: Строгое ограничение на доступ к файлам только внутри рабочей директории проекта.

4. 🔒 run_safe_command (DevOps/Tooling)

   • Описание: Выполняет безопасные, предварительно одобренные (whitelisted) команды разработчика (git status, git diff, pytest, black, ruff).

   • Безопасность: Реализован жесткий белый список команд и аргументов. Любые потенциально опасные вызовы (например, rm -rf) мгновенно блокируются на уровне сервера.

🔗 Подтверждения ссылками на код

В соответствии с требованиями оценки, ниже представлены ссылки на реализацию ключевых блоков:

• Инициализация сервера и регистрация инструментов:

  • server.py:L19-L20 — Поднятие FastMCP инстанса.

• Реализация инструментов:

  • check_service_status — Проверка системных сервисов.

  • get_doc_context — Чтение локальной markdown-документации.

  • search_project_files — Безопасный поиск по файлам проекта.

  • run_safe_command — Выполнение разрешенных утилит с whitelisting.

• Логирование и дебаг-вывод на сервере:

  • Декоратор логгера log_tool_call — Единая точка перехвата, которая выводит в sys.stderr имя инструмента, параметры (с маскированием секретов) и статус выполнения (SUCCESS/ERROR).

  • Конфигурация логирования в stderr — Предотвращает поломку stdio-транспорта.

• Контракт ответов инструментов (Tool outputs contract):

  • docs/best_practices.md:L16-L20 — Подробно описывает контракт структурированных JSON-ответов.

⚙️ Инструкция «Как включить и настроить»

Шаг 1: Подготовка виртуального окружения

Склонируйте репозиторий, перейдите в его корень и создайте изолированное виртуальное окружение:

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Шаг 2: Настройка секретов

Скопируйте пример файла конфигурации и заполните переменные:

cp .env.example .env

Примечание: Файл .env добавлен в .gitignore и не попадет в репозиторий.

Шаг 3: Подключение к агенту в IDE (Cursor)

Чтобы интегрировать MCP-сервер с вашим Cursor:

1. Откройте Cursor Settings (значок шестеренки в верхнем правом углу).

2. Перейдите во вкладку Features -> MCP.

3. Нажмите кнопку + Add New MCP Server.

4. Введите параметры:

   • Name: rebrain-mcp-server

   • Type: command

   • Command: /home/alex/Work/Rebrain/MCP/.venv/bin/python3 /home/alex/Work/Rebrain/MCP/server.py

5. Нажмите Save. Зеленый кружок индикатора покажет успешное подключение и готовность 4 инструментов!

Пример готового конфигурационного файла для Cursor лежит в репозитории: .cursor/mcp.json.

🧪 Проверка: Демонстрация вызовов из агента IDE

Ниже приведены примеры ответов для каждого вызова:

Question: check cron → LLM invoking tool: check_service_status({'service': 'cron'}) ← Response: {"service":"cron","status":"active","return_code":0,"output":"● cron.service - Regular background program processing daemon Loaded: loaded (/usr/lib/systemd/system/cron.service; enabled; preset:... Active: active (running) since Mon 2026-05-26 10:14:39 MSK; 2h 45min ago Docs: man:cron(8) Main PID: 1037 (cron) Tasks: 1 (limit: 4590) CGroup: /system.slice/cron.service └─1037 /usr/sbin/cron -f -L 15

May 26 10:14:39 rebrain-srv systemd[1]: Starting Regular background program proc... May 26 10:14:39 rebrain-srv cron[1037]: (CRON) STARTUP (Vixie-Cron V8.25) May 26 10:14:39 rebrain-srv systemd[1]: Started Regular background program proc... May 26 10:14:53 rebrain-srv cron[1037]: (CRON) INFO (Running @reboot command) May 26 10:15:00 rebrain-srv (CRON)[1076]: (root) CMD (command -v node >/dev/null 2>&1 && if ! node "/usr/share/prometheus/node-exporter/node-exporter.js"; then echo "Failed to start node-exporter" >&2; fi) May 26 10:15:00 rebrain-srv (CRON)[1077]: (root) CMD (command -v node >/dev/null 2>&1 && if ! node "/usr/share/prometheus/node-exporter/node-exporter.js"; then echo "Failed to start node-exporter" >&2; fi) May 26 10:16:01 rebrain-srv (CRON)[1096]: (root) CMD (if [ -d /etc/update-motd.d ]; then run-parts --lsbsysinit /etc/update-motd.d; fi) May 26 11:45:00 rebrain-srv (CRON)[1273]: (root) CMD (node /home/alex/apps/docs-crawler/dist/index.js /home/alex/repos/rebrain-docs "/home/alex/work/web/Rebrain-Web-Development/README.md" "/home/alex/work/web/Rebrain-Web-Development/README.md") May 26 11:45:00 rebrain-srv (CRON)[1272]: (root) CMD (node /home/alex/apps/docs-crawler/dist/index.js /home/alex/repos/rebrain-docs "/home/alex/work/mobile/Rebrain-Mobile/README.md" "/home/alex/work/web/Rebrain-Web-Development/README.md") May 26 12:15:00 rebrain-srv (CRON)[1520]: (root) CMD (node /home/alex/apps/docs-crawler/dist/index.js /home/alex/repos/rebrain-docs "/home/alex/work/Rebrain-mobile/src/pages/index.tsx" "/home/alex/work/Rebrain-mobile/src/pages/index.tsx")

--- RESPONSE --- The cron service is active (running) and has been running for 2h 45min. Recent logs show it's regularly executing tasks, including hourly cron jobs and anacron.

==================================================

Question: проверь git

--- RESPONSE --- I can't check the status of "git" directly as it's not a system service. If you're trying to check the status of a git repository, please specify the command you'd like to run, such as git status or git diff.

==================================================

Question: git status → LLM invoking tool: run_safe_command({'args': ['status'], 'command': 'git'}) ← Response: {"command":"git status","status":"success","exit_code":0,"stdout":"On branch main\nYour branch is ahead of 'origin/main' by 1 commit.\n (use "git push" to publish your local commits)\n\nChanges not...

--- RESPONSE --- Your branch is ahead of 'origin/main' by 1 commit. You have unstaged changes in client.py.

==================================================

Question: расскажи про архитектуру нашего проекта → LLM invoking tool: get_doc_context({'topic': 'architecture'}) ← Response: {"topic":"architecture","matched_file":"mcp_architecture.md","found":true,"content":"# Model Context Protocol (MCP) Architecture\n\nThe Model Context Protocol (MCP) is an open standard that enables de...

--- RESPONSE --- Our project utilizes the Model Context Protocol (MCP) Architecture. This open standard facilitates secure, bidirectional integrations between AI models/agents and their data sources, tools, and environments.

Here's a breakdown of how it works:

• MCP Clients (e.g., IDE extensions or custom AI agents) connect to MCP Servers using standard communication transports.

• The AI model directs the execution of tools.

• The MCP Server executes these actions, either locally or remotely.

• The MCP Server then provides structured context back to the AI model.

The communication flow can be visualized as follows:

┌──────────────────┐               ┌──────────────────┐
│                  │  JSON-RPC     │                  │
│    MCP Client    ├──────────────►│    MCP Server    │
│   (IDE / Agent)  │◄──────────────┤                  │
│                  │  Over Stdio   └────────┬─────────┘
└────────┬─────────┘  or SSE                │
         │                                  ▼
         │                         ┌──────────────────┐
         │                         │  Custom Tools    │
         ▼                         │  (Doc, DevOps,   │
┌──────────────────┐               │  Search, etc.)   │
│   LLM / Model    │               └──────────────────┘
└──────────────────┘

We support two standard transports for communication:

1. Stdio Transport: The client launches the server as a subprocess and interacts via stdin and stdout. Log messages are directed to stderr to avoid interfering with the JSON-RPC communication.

2. HTTP/SSE Transport: The server operates as a web server (e.g., using FastAPI and Server-Sent Events), and the client communicates through HTTP requests and SSE.

==================================================

Для автоматической проверки интеграции и логирования без сторонних API-ключей в репозиторий добавлен скрипт verify_tools.py. Он подключается к работающему HTTP-серверу и имитирует последовательные запросы клиента, фиксируя ответы.

Вы можете запустить его самостоятельно:

1. Запустите сервер в HTTP-режиме: .venv/bin/python3 server.py --http

2. В другом терминале запустите тест: .venv/bin/python3 verify_tools.py

Результаты тестирования и JSON-структура ответов (Trace)

Полный след выполнения тестов сохранен в файле verification_trace.log.

Ниже приведены примеры ответов для каждого вызова:

1. Вызов get_doc_context (Поиск документации)

• Ожидаемый инструмент: get_doc_context с аргументом {"topic": "architecture"}

• Результат (JSON-контракт):

{
  "topic": "architecture",
  "matched_file": "mcp_architecture.md",
  "found": true,
  "content": "# Model Context Protocol (MCP) Architecture\n..."
}

2. Вызов check_service_status (Проверка статуса демона)

• Ожидаемый инструмент: check_service_status с аргументом {"service": "systemd-journald"}

• Результат (JSON-контракт):

{
  "service": "systemd-journald",
  "status": "active",
  "return_code": 0,
  "output": "● systemd-journald.service - Journal Service\n     Active: active (running)...",
  "error": ""
}

3. Вызов search_project_files (Поиск по коду)

• Ожидаемый инструмент: search_project_files с аргументом {"query": "subprocess"}

• Результат (JSON-контракт):

{
  "query": "subprocess",
  "results_count": 6,
  "matches": [
    {"file": "server.py", "line": 1, "content": "import subprocess"},
    {"file": "server.py", "line": 81, "content": "result = subprocess.run("}
  ]
}

4. Вызов run_safe_command (Разрешенная DevOps команда)

• Ожидаемый инструмент: run_safe_command с аргументом {"command": "git", "args": ["status"]}

• Результат (JSON-контракт):

{
  "command": "git status",
  "status": "success",
  "exit_code": 0,
  "stdout": "On branch main\nYour branch is up to date with 'origin/main'...",
  "stderr": ""
}

5. Вызов run_safe_command (Попытка выполнения вредоносного вызова)

• Ожидаемый инструмент: Блокировка вызова {"command": "rm", "args": ["-rf", "/"]}

• Результат (JSON-контракт с ошибкой безопасности):

{
  "status": "error",
  "error": "Command 'rm' is not whitelisted. Safe commands include: ['git', 'pytest', 'black', 'ruff', 'python3']"
}

Логирование на стороне сервера (sys.stderr)

При совершении этих запросов логгер сервера вывел в консоль следующий структурированный дебаг-трейс:

2026-05-26 13:19:33,003 - mcp_server - INFO - === TOOL CALL STARTED ===
2026-05-26 13:19:33,004 - mcp_server - INFO - Tool Name: get_doc_context
2026-05-26 13:19:33,004 - mcp_server - INFO - Arguments: args=(), kwargs={'topic': 'architecture'}
2026-05-26 13:19:33,005 - mcp_server - INFO - Execution Status: SUCCESS
2026-05-26 13:19:33,005 - mcp_server - INFO - === TOOL CALL COMPLETED ===

2026-05-26 13:19:33,019 - mcp_server - INFO - === TOOL CALL STARTED ===
2026-05-26 13:19:33,020 - mcp_server - INFO - Tool Name: check_service_status
2026-05-26 13:19:33,020 - mcp_server - INFO - Arguments: args=(), kwargs={'service': 'systemd-journald'}
2026-05-26 13:19:33,344 - mcp_server - INFO - Execution Status: SUCCESS
2026-05-26 13:19:33,344 - mcp_server - INFO - === TOOL CALL COMPLETED ===

Это полностью подтверждает соответствие критериям оценки домашнего задания.