RAG MCP позволяет дать ИИ-агенту ограниченный инструмент поиска по документам: клиент вызывает его через MCP, а сервер возвращает фрагменты с источниками после проверки прав. Перед подключением к рабочему корпусу задайте формат запроса, идентификаторы источников и понятный ответ для пустой выдачи. Такая схема пригодна там, где владелец данных может определить разрешённые коллекции и проверить каждое обращение на сервере.
Поиск как инструмент
В MCP сервер объявляет инструмент через tools/list, а клиент вызывает его через tools/call. Для RAG здесь нужен отдельный поиск с ограниченным входом и ссылками на найденные источники.
Практическая граница проходит между текстом модели и сервером поиска. Агент формулирует вопрос и может запросить инструмент, но перечень доступных документов, право на чтение и версия корпуса определяются вне модели. Сервер принимает запрос от пользователя, чья личность установлена доверенным способом, сверяет область доступа с источником и возвращает только разрешённые фрагменты. Любой ответ модели поверх них остаётся черновым выводом: спорные утверждения подтверждает сотрудник по исходному документу. Если у пользователя несколько ролей, тестируйте ту, с которой он действительно работает: полномочия сервер устанавливает независимо от роли, указанной в тексте вопроса.
На вход проекта нужны владелец корпуса, список коллекций, способ установления пользователя, версия загруженных документов и правило выдачи ссылки на источник. Для первого испытания возьмите небольшой обезличенный набор с двумя типами доступа: общий документ и закрытый документ. Это даёт проверяемые сценарии для положительного поиска и отказа без подключения производственных файлов. Запросы для испытания фиксируйте заранее, чтобы разница между результатами объяснялась изменением данных или прав, без влияния новой формулировки вопроса.
Здесь речь идёт о контракте одного поискового инструмента. Общий цикл получения ответа уже разобран в статье про RAG-агента и цитирование, а устройство базы документов — в разборе RAG-базы знаний. Для теста MCP важнее увидеть конкретный вызов, параметры, возвращённые фрагменты и решение сервера по правам.
Контракт поиска
Согласно спецификации MCP, сервер с инструментами объявляет capability tools. Клиент запрашивает tools/list и получает имя инструмента, описание и inputSchema. Поисковый инструмент можно назвать search_documents; это проектное имя инструмента, выбранное командой. В описании укажите, что вызов только читает разрешённый корпус, какие вопросы подходят и какой смысл имеют пустая выдача и отказ. В интерфейсе клиента показывайте доступные модели инструменты и факт вызова: это рекомендация спецификации MCP для безопасного взаимодействия.
| Поле контракта | Проектное значение | Зачем нужно |
|---|---|---|
query | Текст вопроса без секрета | Определяет предмет поиска. |
collection | Разрешённый идентификатор корпуса | Ограничивает источник до запроса. |
limit | Верхняя граница выдачи | Сдерживает объём фрагментов. |
document_id | Идентификатор документа в результате | Позволяет сверить цитату с оригиналом. |
corpus_version | Версия набора в результате | Показывает, по какой редакции шёл поиск. |
Первые три строки относятся к предлагаемому inputSchema, последние две — к предлагаемому ответу. Протокол допускает outputSchema и structuredContent; их удобно применить, когда клиенту нужны поля результата для проверок и отображения. Конкретные имена полей выберите вместе с владельцем корпуса и зафиксируйте в схеме. Само наличие JSON Schema описывает форму данных, но сервер всё равно обязан проверять значения, допустимые коллекции и права пользователя. Выходную схему полезно держать рядом с тестами клиента: при переименовании поля сразу станет видно, какие проверки и элементы интерфейса требуют правки.
Текст фрагмента, заголовок, устойчивый идентификатор и ссылка на исходник должны относиться к одной версии документа. Если документ заменён, сервер сообщает фактическую версию выдачи, а клиент показывает её рядом с цитатой. Так редактор сможет открыть исходник и понять, насколько свежа опора для ответа. Базовые свойства MCP-сервера и размещение инструментов подробно описаны в материале о собственном MCP-сервере; здесь важен узкий контракт поиска.
Маршрут вызова
Проверку начните со стороны клиента. После согласованного подключения он получает список инструментов через tools/list. Убедитесь, что объявлен ровно нужный поисковый инструмент, описание соответствует области чтения, а схема входа требует вопрос. Затем отправьте tools/call с именем search_documents и аргументами из тестового набора. Название и поля здесь служат примером проектного контракта; их придётся согласовать с фактической реализацией.
- Создайте тестовую учётную запись с доступом к общему документу и отдельную запись без доступа к закрытому документу. Сохраните их роли в протоколе приёмки без секретов.
- Запросите список инструментов и сравните имя, описание и входную схему с утверждённым контрактом. Лишний инструмент передайте на разбор владельцу сервера.
- Вызовите поиск по известной фразе общего документа. Сверьте текст фрагмента, идентификатор, ссылку и версию корпуса с открытым оригиналом.
- Повторите запрос под ограниченной ролью к закрытому документу и к несуществующей фразе. Зафиксируйте различие между отказом в доступе и пустой выдачей.
Спецификация MCP разделяет ошибки протокола и ошибки выполнения инструмента. Неизвестное имя или неверные аргументы могут вернуться как ошибка JSON-RPC, а сбой поиска — как результат с isError. В проектном договоре зафиксируйте собственные коды для отказа по правам и пустой выдачи. Пустой результат говорит лишь об отсутствии совпадений в разрешённой версии корпуса; общий вывод об отсутствии информации из него делать нельзя.
Агент получает фрагменты как данные инструмента. Инструкция внутри найденного документа может быть враждебной; её следует показывать как содержание источника, без придания ей роли команды. Для рабочего ответа человек открывает документ по идентификатору и проверяет смысл цитаты. Такой контроль особенно важен, когда похожие редакции документа содержат разные условия.
Права и исключения
Нельзя полагаться на параметр collection как на доказательство допуска. Клиент способен передать другое значение, а модель может ошибиться при выборе корпуса. Сервер устанавливает личность вызывающего по доверенному каналу, сверяет её с политикой источника и применяет фильтр до выдачи текста. Фильтр после генерации ответа уже поздно защищает закрытый фрагмент. На уровне поискового хранилища полезно повторить проверку по идентификатору каждого найденного документа.
Для отказа задайте одинаково понятное поведение на всех клиентах: инструмент сообщает о запрете без содержания закрытого документа и без подсказок о его названии. Для отсутствующего совпадения возвращается пустой список разрешённых результатов с версией корпуса. Для недоступного индекса нужен отдельный статус ошибки, чтобы человек видел сбой сервиса, без ошибочного вывода об отсутствии данных. Логи сохраняют идентификатор пользователя, время вызова, имя инструмента, коллекцию и исход проверки; секреты и полный текст закрытых документов в них исключаются.
Отдельный риск связан с устаревшим корпусом. Укажите владельца загрузки, правило смены версии и способ сверки с оригиналом. Если результат ссылается на старую редакцию, интерфейс должен показать эту версию и передать решение ответственному сотруднику. Инструмент поиска подбирает кандидатов, а итоговое толкование условий, договоров или регламентов остаётся за человеком. Для глубокой проверки границ доступа используйте маршрут поиска по документам с правами и источниками. В протоколе приёмки укажите, кто имеет право менять состав корпуса и кто подтверждает удаление устаревших редакций из индекса.
Какой корпус и какие роли нужны вашему поиску?
Приёмка и развитие
Зафиксируйте результаты испытания в таблице приёмки: вопрос, роль, доступная коллекция, ожидаемый документ, фактические идентификаторы, версия корпуса и решение человека по цитате. Положительный тест требует совпадения фрагмента с исходником; отрицательный — отсутствия закрытого текста в результате. Отдельно проверьте неверные аргументы, пустую выдачу и недоступность поискового хранилища. Так видно, где сбой вызова, где ограничение прав, а где пробел в самом корпусе.
Возьмите один разрешённый и один закрытый тестовый документ. Опишите входную схему поиска и запустите проверку под двумя ролями. Приёмку завершайте сверкой ссылок с исходниками и отказа сервера по закрытому документу.
После испытания подключайте новый корпус только с владельцем данных и описанным правилом обновления. Измеряйте долю ответов с открываемым источником на вашем наборе вопросов, число ошибочных отказов и случаи выдачи лишнего фрагмента. Эти показатели служат внутренней проверкой качества, без обещания результата для любого запроса. При изменении политики доступа повторяйте тест под соответствующими ролями; при изменении корпуса повторяйте проверку версии и цитаты.
Если задача выходит за рамки демонстрации, состав работ зависит от источников, способа установления личности, качества документов, обработки редакций и требований к журналу. Обсудить такой контур можно на странице внедрения нейросети для документов; стоимость рассчитывают под вашу задачу после определения границ. Отдельно проверьте, что сотрудник может оспорить ответ и открыть оригинал, а владелец системы способен отозвать доступ без изменения текста инструкции модели. При споре сохраняйте идентификатор вызова и версию корпуса; эти сведения помогают воспроизвести ситуацию без пересылки полного текста закрытого документа.