Как развивался CodeAlive MCP: от трёх инструментов до исследовательского интерфейса

Первая рабочая версия CodeAlive MCP появилась 27 апреля 2025 года. Это был один Python-файл с тремя инструментами: get_data_sources, search_code и chat_completions.

Она работала, но шероховатости проявились быстро. Один поиск мог принести в контекст слишком много кода. Ответы тратили токены на оформление, а ошибки иногда выглядели как успешные результаты инструментов.

Мы меняли интерфейс по частям. Правило повторялось из версии в версию: поиск должен оставаться коротким, а исходники и подсказки по восстановлению нужны только на следующем шаге.

2025: от локального адаптера к удалённому MCP

Изначально search_code принимал естественный язык или паттерны кода и мог сразу вернуть полное содержимое файлов. chat_completions хранил состояние диалога через conversation_id. Ответы были рассчитаны на человека: вводный текст, JSON с отступами, подписи и инструкции.

В июне мы добавили публикацию Docker-образов. В июле перешли на FastMCP 2, добавили HTTP-транспорт с Bearer-аутентификацией и анонсировали удалённый эндпоинт https://mcp.codealive.io/api/. Реализация существовала с апреля; публичный удалённый эндпоинт появился позже.

К осени инструменты назывались codebase_search и codebase_consultant. Поиск и чат начали принимать имена репозиториев и рабочих пространств вместо непрозрачных идентификаторов. Модели стало проще переиспользовать результат get_data_sources.

Формат поиска сменился с текста и вложенных данных на компактный XML. В ответе остались поля, нужные для следующего шага: путь, идентификатор, диапазон строк, тип и короткое описание.

Март 2026: сначала поиск, потом исходники

В v0.5 появился fetch_artifacts, а возможность вкладывать полный исходный код прямо в результаты поиска исчезла.

Процесс стал двухшаговым:

1. Поиск возвращал небольшие записи для отбора.
2. fetch_artifacts загружал код только для выбранных идентификаторов.

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

fetch_artifacts оборачивал исходники в XML, чтобы границы артефактов оставались явными. Сам поиск при этом оставался коротким даже для большого репозитория.

Апрель 2026: один поиск разделился на два

В апреле мы добавили get_artifact_relationships, а затем разделили codebase_search на:

• semantic_search для концепций и поведения, когда точное имя неизвестно;
• grep_search для идентификаторов, литералов, имён файлов и регулярных выражений.

Тогда же появилось короткое имя chat. Новые инструменты попали в продакшен 8 и 9 апреля, а формальный тег v2.0.0 вышел 14 апреля.

Форматы стали намеренно разными. Поиск, источники данных и связи перешли на компактный JSON, а fetch_artifacts сохранил XML вокруг исходников. Вскоре FastMCP начал возвращать результаты поиска как нативные структурированные данные, а не JSON-строку. У этих ответов разные задачи, поэтому общий формат им не нужен.

Одновременно изменилась обработка ошибок. Ранние версии возвращали строки вида Error: .... В v2 ошибки стали нативными результатами ToolError с isError: true, и клиент мог отличить сбой от данных. Пустой поиск подсказывал следующий вызов. Ошибка валидации показывала проблемное поле и, если он был доступен, идентификатор запроса.

Июль 2026: MCP стал тонким клиентом Tool API

CodeAlive MCP 3.0 перешёл на тот же Tool API, которым пользуются остальные наши интеграции. Каждый MCP-инструмент вызывает POST /api/tools/{name} с аргументами в snake_case и запрашивает output_format: "agentic".

Сейчас сервер предоставляет 11 инструментов только для чтения:

• get_data_sources
• semantic_search и grep_search
• get_repository_ontology, get_file_tree и read_file
• fetch_artifacts и get_artifact_relationships
• get_artifact_query_schema и query_artifact_metadata
• chat

Устаревшие алиасы codebase_search и codebase_consultant удалены. chat тоже стал stateless: вместо conversation_id вызывающая сторона передаёт нужные находки и ограничения вместе с вопросом.

V3 перенёс рендеринг в бэкенд. Каждая операция Tool API определяет структурированную форму obj и форму rendered для агента. MCP просто пересылает rendered. Сейчас поиск использует компактный XML, онтология использует Markdown, несколько инструментов извлечения возвращают лаконичный JSON, а чат возвращает обычный текст.

Исправимые ошибки аргументов содержат code, message, retry и try, а также отрендеренный блок <tool_error>. Ошибки аутентификации, квот, транспорта и неожиданные сбои сервера остаются HTTP-ошибками.

Базовый процесс не изменился. Агент находит источник данных, выполняет поиск, получает нужный код и запрашивает синтез только при необходимости. В v3 каждый вызов решает более узкую задачу, поэтому в контекст попадает меньше лишнего.

Подключить CodeAlive MCP можно по руководству по интеграции, а те же операции доступны через Tool API.