MCP-коннектор за выходные

Поздней осенью появился датасет с практикой ФАС по рекламе. С февраля у датасета появилось лицо с поисковым движком: сервис https://search.delay-rag.ru. А теперь обратный откат в безынтерфейсье для нас... но удобный доступ для ваших агентов! А именно MCP-коннектор (документация здесь). За неделю его существования сервер получил около сотни запросов, и MCP-запросы составляют 40% потока запросов к сервису.

Делать коннектор оказалось абсолютно несложно: чистый вайб-кодинг по стандартной схеме: обсуждение с нейросетью идеи, написание ТЗ, собственно кодинг (я делала в Claude Code CLI), тесты и деплой, что не отменяет того, что это всё равно занимательный опыт. На уровне теории я вроде бы понимала, как это работает (как правило, стараюсь понимать всё, о чём пишу в Базе знаний), но сделать своё — это вам не это!

Поделюсь здесь теми развилками, которые возникли у меня, а также поподробнее расскажу о том, что вообще такое MCP в практическом разрезе. Надеюсь, будет полезно тем, кто захочет сделать свой коннектор, или тем, кто любит понимать, как устроены вещи, которыми они пользуются. В конце, как обычно, какие-то инсайты и зловещие предсказания (ну ладно, в этот раз скорее оптимистические)!

Да кто такой этот ваш MCP

MCP (Model Context Protocol) — открытый стандарт, который Anthropic представили в конце ноября 2024 года. Он описывает, как ИИ-ассистент должен общаться с внешним сервисом, чтобы получить от него инструменты, данные или готовые шаблоны запросов. Под внешним сервисом понимается почти что угодно — от вашей почты и доски в Miro до поисковых движков вроде моего.

MCP любят сравнивать со стандартом USB-C: один провод, который подойдёт ко всем вашим устройствам сразу. Владелец сервиса делает один сервер по стандарту, и любой ИИ-ассистент, поддерживающий MCP, может его подключить. Сейчас это Claude (и чат, и Desktop, и CLI), Chat GPT (включая Codex CLI), Cursor, VS Code, Windsurf... да много их! Фактически это полноценный кросс-индустриальный стандарт, а не протокол одной компании. С декабря 2025 MCP управляет уже не Anthropic единолично, а Agentic AI Foundation под эгидой Linux Foundation (учреждён вместе с Block и OpenAI, при поддержке Google, Microsoft, AWS и Cloudflare). Официальная документация и всякое интересное про стандарт лежит на modelcontextprotocol.io.

На практике это значит, что когда вы делаете MCP-коннектор, вы автоматически получаете аудиторию пользователей всех MCP-совместимых клиентов, так как сам сервер живет на одном и том же URL-адресе, а стандарт предполагает, что не нужны отдельные версии для разных ассистентов.

Пока как-то так складывается, что юристы больше всего из агентских сервисов любят Claude Cowork. И российские, и не только: по данным самой Anthropic, юристы к тому моменту стали самой активной аудиторией Claude Cowork среди всех профессий интеллектуального труда. Это объясняет поворот на legal, который так много обсуждается в западной LegalTech среде, особенно новость о том, что в мае 2026 Anthropic выпустила «Claude for Legal». Это больше 20 официальных MCP-коннекторов к софту, на котором работают западные юрфирмы и инхаусы (DocuSign, Ironclad, iManage, NetDocuments, LexisNexis, Thomson Reuters, Box, Everlaw), плюс 12 плагинов под конкретные практики. Российскому юристу это всё не очень актуально, конечно, но всё перечисленное — это официальные коннекторы, сделанные вместе с вендорами. При этом стандарт MCP открытый, и Claude (и, как мы уже поняли, и любые другие ассистенты) спокойно работает с неофициальными серверами, которые может делать кто угодно — в том числе под российские реалии.

Для пользователей из РФ уже есть следующие коннекторы (я не пользовалась ни одним из них, поручиться ни за какой не могу):

• Russian Law MCP с доступом к федеральным НПА;
• коннекторы atomno-labs для проверки контрагентов через ЕГРЮЛ/ФНС/ФССП;
• MCP «Дадаты»;
• агрегатор ru-mcp с реестрами и хостингом в РФ под 152-ФЗ;
• коннектор ИИ-сервиса по поиску судебной практики Casus Legal.

Большая их часть даёт агентам доступ к каким-то структурированным данным. И это действительно отличный use-case для того, чтобы сделать коннектор.

Когда MCP уместен

На вайб-кодерском уровне его особенно легко собрать, если:

• у вас есть структурированные данные и (или) сервис вокруг каких-то данных. И эти данные ИИ мог бы обрабатывать быстрее и лучше, чем человек вручную;
• уже есть какой-то бэкенд — MCP делается тонкой обёрткой вокруг него. https://search.delay-rag.ru работает на FastAPI, но это может быть и просто любая база данных;
• аудитория активно пользуется ИИ-ассистентами. Как показывают даже мои скромные метрики, юристы вполне понимают, как этим пользоваться.

MCP может оказаться довольно проблематичным в разработке, если:

• сценарий требует жёсткой UX-обвязки — фиксированной последовательности шагов, форм для ввода от пользователя, гарантированного формата вывода. Тогда Telegram-бот или веб-приложение управляют опытом лучше;
• сервис построен вокруг чувствительных данных, и нужно прорабатывать авторизацию пользователей. А это и технические, и организационные, и регуляторные сложности.

Поэтому я не стала делать коннектор к боту. Бот — это очень детерминированный сценарий проверки рекламного креатива, довольно строго спроектированный пайплайн. Там экспертный системный промпт, строго заданный формат ответа, продуманная маршрутизация пользователя. Пользователь получает один тип взаимодействия — но проверенный и работающий стабильно. Коннектор — это источник для вашего совместного творчества с вашим агентом (агентность же состоит в том, что детерминированность его действий сильно ниже, вы ему аутсорсите принятие решений). Поисковик через MCP отдаёт карточки с данными, а агент сам решает, что с ними делать в рамках вашего запроса. То есть контролируемых сценариев вообще нет. Я отлично понимаю, что умная агентная нейронка с коннектором и толковым оператором ЭВМ может отрабатывать намного круче, чем бот. И вообще делать сильно больше вещей, чем может делать бот.

Как собрался мой коннектор

В дополнение к сказанному выше расскажу о нескольких решениях, принятых с установкой «хочу, чтобы пользователь получал ответ быстро, не тратя свои лимиты слишком сильно».

Решение №1. Размер ответа

У контекстного окна агента есть бюджет, и каждый вызов внешнего сервиса этот бюджет тратит — на запрос к сервису и на обработку ответа от него. Если ответ не влезает в лимит токенов, то выдача сохраняется отдельно на диске, агент читает эти файлы десятками read-вызовов, вызывая параллельных субагентов, чтобы как-то справиться (и скорее всего неконтролируемо, быстро наступает компактинг и всё другое, что так неприятно в работе с агентами, о чем я писала в посте про Cowork).

В общем, ответ от сервиса должен быть компактным. У меня вот такие архитектурные ограничители:

• жёсткий потолок на размер ответа до 15 КБ;
• функционал сервиса разделён на два инструмента: search_fas_cases возвращает компактный список карточек дел, подходящих под запрос, а get_case_details отдаёт полную карточку конкретного дела. Агент сам решает, что копать глубже;
• дефолтное количество результатов поиска 5, максимум 15;
• длинные текстовые поля в режиме списка обрезаны до ~200 символов — этого достаточно, чтобы агент принял решение, копать дальше или нет, но контекст не перегружается.

В результате типичный ответ выходит в 6–7 КБ, а агенты отвечают за 5–10 секунд, не прибегая к неконтролируемой оркестрации.

Решение №2. Описание инструмента

Подключаясь по MCP к сервису, агент видит ваш инструмент не глазами, а через текстовое описание, которое при написании коннектора на Python называется docstring. От того, как написан docstring, зависит, поймёт ли агент по вашему промпту, когда звать инстурмент, как сформулировать корректные запросы в сервис, как объяснить пользователю, почему пришли такие результаты.

У Anthropic есть отдельный гайд «Writing effective tools for agents», где прямо показано, что даже небольшие правки описаний дают резкий прирост качества, что поисковые инструменты (search_*) лучше, чем «отдай-всё» (list_*). Хороший docstring экономит агенту вызовы и снижает шанс, что он будет вызывать инструмент не в тему. Примерная оптимальная структура docstring для поисковых движков может быть такой:

КОГДА ИСПОЛЬЗОВАТЬ:
- Конкретные сценарии, для которых инструмент подходит
- Чем он отличается от смежных инструментов

ЧТО ВЕРНЁТ:
- Какие поля в ответе, что они значат, какие могут отсутствовать

ПАРАМЕТРЫ:
- Каждый параметр с примерами значений (определяются структурой ваших данных и кодом поискового движка)
- Особенности: диапазоны, ограничения, частые ошибки

У меня docstring говорит агенту о том, что коннектор нужно использовать, когда задан вопрос по рекламному регулированию, и уместно искать практику ФАС по теме; что вернётся компактный список с реквизитами решения, номерами статей, кратким описанием нарушения, ссылкой на базу ФАС; а за полными текстами аргументов ФАС нужно отдельно вызвать инструмент get_case_details.

Решение №3. Чистота данных

В датасете есть легаси-поле defendant_industry — отрасль рекламодателя. Значения в нём человекочитаемые («розничная торговля», «медицинские услуги», «аптечные товары»), но не нормализованные: 723 уникальных значения, многие — варианты написания одного и того же. Так вышло, потому что при разметке кейсов я не задавала жёстких правил заполнения этого поля (про разметку подробнее здесь).

В веб-интерфейсе я это поле показываю — там оно работает хорошо. Человек видит метки в списке, глазами пробегает список и за секунду понимает, относится ли кейс примерно к его отрасли, даже если написано не унифицированно. Может воспользоваться раскрывающимся фильтром, выбрать несколько вариантов, может проигнорировать фильтр. Интерфейс здесь как бы прощает беспорядок.

Но для MCP я это поле defendant_industry сознательно не выставила. Если делать его параметром-фильтром, агент должен будет передать точную формулировку. На 723 ненормализованных вариантах это ловушка: агент отфильтрует по «медицина», а все дела, заведённые как «медицинские услуги» или «оказание мед. услуг», в выдачу не попадут. В общем, кривой фильтр здесь хуже, чем отсутствие фильтра. Тем более, что отраслевая релевантность вполне может быть закрыта самим принципом семантического поиска, являющегося основой поискового движка (логика поиска, кстати, описана здесь).

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

Решение №4. Слеш-команды

Кроме обычных tools, в MCP можно объявить prompts — шаблоны, которые в Claude появляются как слеш-команды в строке ввода. Пользователь печатает /search-fas алкоголь, и шаблон автоматически разворачивается в правильно сформулированный запрос к модели.

Для вайб-кодера это всего лишь ещё один промпт, а для пользователя — быстрая и заметная польза, не играть в рулетку, поймёт ли правильно агент интент запроса (даже при очень хорошем docstring осечки возможны).

Решение №5. Отказ от авторизации

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

Поэтому я ограничилась небольшим рейт-лимитом по IP: 20 запросов/мин, 300/сутки — так, чисто для красоты. Поиск открытый, данные публичные, и делать порог входа выше я как-то не вижу смысла.

Ещё кое-что практическое

У MCP есть специальный отладочный инструмент, позволяющий протестировать работу коннектора не через ИИ-ассистента — MCP Inspector. Это веб-интерфейс, запускаемый на вашем сервере (напомню, что ваш собственный компьютер умеет создавать локальные мини-серверы), который показывает все инструменты и промпты коннектора. Можно вручную перепроверить работу сервиса с любыми параметрами, увидеть сырой ответ, прикинуть его размер, и на лету что-то поправить, не переподключая каждый раз переписанный коннектор к вашей агентной среде.

И в конце несколько начавших роиться в голове мыслей.

Результаты работы Claude, вооруженного коннектором, меня очень впечатлили, прям очень сильный эмоциональный отклик случился. Я в этом увидела образ будущего справочно-правовых систем (да и вообще разных специализированных поисковых систем, не только юридических). Это сильно логичнее, экономичнее и быстрее, чем надстройки, которые жмут кнопки в UI как бы за пользователя (то, что делал браузер Comet или надстройка Claue в Chrome). Это делает поиск сильно точнее в рамках поставленной задачи, вы можете получить сразу же интерпретацию результатов.

Интересно, что если даже у меня от идеи сделать UI для людей до ощущения необходимости сделать коннектор для агентов прошло буквально несколько месяцев (и то я считаю, что жёстко стормозила) — об этом наверняка не могут не думать вендоры поисковых систем (да и других сервисов: это только в этом посте фокус на поиске, MCP могут быть к чему угодно). Теперь вместе с UI/UX специалистами должны работать ещё и специалисты, проектирующие путь агента в сервисе, которые будут принимать вот такие решения, как я описала выше. Возможно, это вообще подменит собой UI/UX для людей, так как люди будут меньше общаться с миром через интерфейсы, а больше через своих агентов.

И, кажется, главное: кроме «опыта» агента понадобится ещё и забота о качестве и чистоте данных в системе. Где-то здесь будет зарыто конкурентное преимущество: валидные, чистые, верифицированные данные, в которых с максимальной скоростью и эффективностью будут делать навигацию ИИ-агенты. Здесь уже вывода не будет, хотя у меня он есть. Думайте!)