В предыдущей главе мы запустили минимального агента, где голова (LLM) подключена к инструменту и сама крутит цикл. По этому опыту вы наверняка почувствовали: реальная сила агента почти целиком определяется тем, «к каким инструментам он подключён». В этой главе мы выберемся из изнурительного самостоятельного изготовления инструментов каждый раз и научимся стандартно подключаться к внешним инструментам и данным через общий стандарт — MCP (Model Context Protocol). MCP родился в Claude и сейчас становится стандартом подключения, охватывающим всю отрасль.
Цель — «подключаться безопасно по стандарту, не изготавливая инструменты самому»
Почему подключение инструментов — суть агента
Сама по себе LLM, как бы умна она ни была, умеет только «порождать слова». Узнать текущий остаток на складе или дописать одну строку в файл она не может, если нет средства коснуться внешнего мира. Агент способен крутить цикл «изучить — выполнить — проверить» лишь потому, что у него есть инструменты, воздействующие на внешнее.
То есть потолок возможностей агента определяется качеством и числом подключённых инструментов. При одной и той же LLM агент, у которого есть только калькулятор, и агент, подключённый к базе данных, поиску, файлам и внутренним API, различаются по возможностям как небо и земля. Нередко бывает так, что точно подключить хорошие инструменты даёт куда больший прирост ощущаемых возможностей, чем замена головы на более продвинутую.
💡 «Хорошо укомплектован инструментами» важнее, чем «умён». Даже способный человек с пустым ящиком инструментов ничего не сделает. Большая часть времени в разработке агентов на деле уходит на проектирование того, «какой инструмент и как безопасно передать». Эта глава — о самом ядре.
Пределы «голого» определения инструментов
В предыдущей главе мы определили инструмент своими руками. Написать функцию, передать LLM имя, аргументы и описание, а при вызове выполнить и вернуть результат — сам этот ход верен и остаётся основой. Проблема в том, что это приходится переделывать каждый раз, под каждый инструмент, под каждый проект.
Возьмём для примера «инструмент поиска по базе данных». Написать подключение, собрать запрос, отформатировать результат, обработать ошибки, безопасно обойтись с учётными данными… Весь этот комплект и в вашем проекте, и у соседней команды, и на другом языке каждый реализует по-своему. Один и тот же инструмент разработчики по всему миру снова и снова изобретают заново — вот реальность голого определения инструментов.
Инструмент, написанный под конкретный проект, привязан к этому фреймворку и языку, и его трудно вынести в другое место.
Чтобы подключить M видов инструментов к N платформам агентов, теоретически нужен N×M вариантов кода подключения.
Каждый раз, когда меняется спецификация точки подключения, приходится править по отдельности самодельные инструменты, разбросанные там и сям.
Это очень похоже на времена, когда для каждой периферии требовался свой кабель. Для принтера — специальный разъём для принтера, для мыши — для мыши; чем больше устройств, тем сильнее взрывается число способов подключения. Будь «общий разъём» — вся эта морока разом исчезает. Тут и появляется MCP.
Что такое MCP — общий стандарт подключения инструментов
MCP (Model Context Protocol) — это открытый стандарт, соединяющий ИИ с внешними инструментами и данными стандартным способом. Anthropic опубликовала его в конце 2024 года для Claude, после чего его начали поддерживать самые разные ИИ-инструменты и сервисы. На 2026 год он широко принят поверх границ вендоров и вырастает в отраслевой стандарт, развивающийся под нейтральным управлением. Важно то, что это общая спецификация, которую может реализовать любой, а не продукт одной компании.
Если выразить идею MCP одной фразой, это «USB для подключения ИИ-инструментов». Как с появлением USB периферию любого производителя стало можно подключать через один и тот же разъём, так и инструмент с поддержкой MCP «подключил — и работает» с любым MCP-совместимым агентом. Когда создающая и использующая стороны следуют одному соглашению, ад комбинаций N×M складывается до «N + M».
Это ваш агент или приложения вроде Claude. Сторона, которая спрашивает у сервера «какие сейчас подключены инструменты?» и вызывает нужные.
Сторона, которая публикует функции как «инструменты» — работу с файлами, поиск по БД, интеграцию с SaaS. Один сервер может иметь несколько инструментов.
Обе стороны общаются по заданному порядку. Когда клиент подключается, он сначала получает от сервера «список доступных инструментов» и «описание и аргументы каждого». LLM смотрит на этот список, выбирает подходящий под цель инструмент и вызывает его, а сервер выполняет и возвращает результат — вот этот обмен и складывается без отдельной реализации под каждый инструмент, в чём и суть MCP.
Клиент → сервер :«Подскажи доступные инструменты» Сервер → клиенту:«Три: search_docs / read_file / query_db, описания такие» LLM решает :«Вызову query_db с аргументами {sql:"..."}» Клиент → сервер :«Выполни query_db» Сервер → клиенту:«Результат — вот эти строки данных»
Способов публикации в основном два. Локальный тип — запускается как процесс на вашей машине; удалённый тип — подключается по сети. Локальный подходит для ваших файлов и dev-БД, удалённый — для интеграций с SaaS, общих для команды. У обоих соглашение «получить список инструментов и вызывать» одно и то же, и обращение на стороне клиента почти не отличается.
📖 Сначала — общая картина. Если сперва прочитать разбор «Что такое MCP», где доступно изложены происхождение, термины и состояние поддержки, материал этой главы зайдёт легче. Детали спецификации и версии эволюционируют быстро, поэтому перед реализацией обязательно сверьтесь с актуальной официальной документацией.
Использовать и создавать MCP-серверы
Самое вкусное в MCP — то, что уже опубликованные в мире серверы можно использовать как есть. Ходовые инструменты, как правило, кто-то уже подготовил в виде MCP-сервера. Подключив их к своему агенту, вы разом наращиваете его возможности без изобретения велосипеда.
Чтение и запись в заданной папке. Основа для того, чтобы дать читать документы или выводить результаты работы.
Выполнение SQL и обращение к схеме. На «посчитай» может ответить, обратившись к реальным данным.
Веб-поиск или поиск по внутренней базе знаний. Становится «рукой, которая ищет» свежую информацию и обоснования.
Трекеры задач, чаты, хранилища. Превращает существующие рабочие инструменты в руки и ноги агента.
Сам порядок подключения прост. Нужно лишь запустить желаемый сервер (или указать URL) и зарегистрировать в настройках клиента адрес сервера и учётные данные. Дальше агент при подключении получает список инструментов и вызывает их по мере надобности. Писать «начинку инструмента поиска по БД» вам не нужно. Ваша работа — комбинировать предоставленные инструменты под задачу.
⚠️ «Раз удобно — подключим всё» недопустимо. Каждый добавленный сервер увеличивает объём описаний, передаваемых LLM, на число его инструментов; решения рассеиваются, а простор для ошибочных операций растёт. Основа — подключать только те инструменты, что действительно нужны цели этого агента. Избыток инструментов, наоборот, снижает точность.
Свой сервер тоже можно создать
Инструменты, для которых нет готового сервера — внутренний собственный API, особая бизнес-логика, — достаточно написать в виде своего MCP-сервера. В этом достоинство MCP: опубликовав его однажды как сервер, вы сможете одинаково использовать его из любого совместимого агента. Инструмент, созданный под один проект, переиспользуется в следующем проекте и в другом агенте команды без переписывания.
Суть создания сервера — «определить нужную функцию как инструмент, объявить имя, аргументы и описание, а при вызове выполнить обработку и вернуть результат». Идея та же, что у голого определения инструментов из предыдущей главы, но решающе отличается то, что выход направлен не на «конкретного агента», а на «общий разъём MCP». Труд на создание — единожды, переиспользование — сколько угодно раз.
🛠 Если беретесь за реализацию. Конкретный код для сборки агентов и подключения инструментов в Claude практично изложен в введении в Claude Agent SDK. В SDK встроен механизм работы с MCP-серверами, и как подключение готовых серверов, так и создание своих можно выполнять по шагам из официальной документации.
Какие инструменты давать и как
Когда вы научились «подключать» инструменты, следующий вопрос — «что и как давать». Это узловая точка проектирования, определяющая качество и безопасность агента, и основа для последующих глав. Усвоим три принципа.
Давать только те инструменты и тот объём, что нужны задаче. «Если хватает чтения, право записи не давать». Для БД — ограниченный аккаунт только на чтение, для файлов — только целевую папку.
LLM решает, использовать инструмент или нет, опираясь только на его описание. Пишите конкретно: «что делает, когда применять, смысл аргументов, в каких случаях использовать нельзя». Расплывчатое описание порождает ошибочное применение.
Запись, удаление, оплата, выполнение команд и прочие необратимые операции не ставьте в один ряд с читающими. Обязательно прилагайте подтверждение перед выполнением, ограничение целей и запись в лог.
Особенно важен пункт ③. «Изучающие» инструменты (поиск, обращение, чтение) даже при ошибочном вызове редко наносят большой вред. А «изменяющие» (запись, удаление, отправка, выполнение) одной ошибочной операцией порождают непоправимый результат. Железное правило — осознанно разделять читающие и записывающие инструменты и на вторые накладывать несколько слоёв защиты.
| Тип | Пример | Риск | Как давать |
|---|---|---|---|
| Читающие | Поиск, обращение, чтение файлов | Низкий (внимание к обращению с информацией) | Сравнительно свободно. Ограничить область |
| Записывающие | Обновление файлов, запись в БД, отправка | Высокий (трудно отменить) | Подтверждение, ограничение, запись обязательны |
| Выполняющие | Выполнение команд, внешние вызовы, оплата | Максимальный (вход для сбоев и злоупотреблений) | По умолчанию защита + одобрение человека |
🔒 Этим мы досконально займёмся в главе 6. Контроль опасных инструментов, защита от prompt injection, проектирование процесса одобрения — темы, которые не обойти при выводе агента в продакшн. Мы разберём их вместе в главе 6 «Ограждения и безопасность», а из этой главы унесите лишь ощущение, что «у инструментов есть разница в уровне опасности». Не подключать без разбора недоверенные MCP-серверы — тоже важная привычка.
Продвинутые инструменты — управление браузером и другое
Среди инструментов в последнее время особенно привлекает внимание управление браузером. Смотреть на экран, переходить по ссылкам, заполнять формы, нажимать кнопки — если поручить агенту то, что человек делает в браузере, множество веб-сервисов без выделенного API превращаются в его «руки и ноги». Появились реализации, предоставляющие управление браузером в виде MCP-сервера, и порог подключения снизился.
Однако это один из самых мощных и самых рискованных инструментов. Опасность принять инструкции с экрана как есть (манипуляция, дезинформация), непреднамеренные клики и отправки, раскрытие учётных данных — всё, о чём говорилось про «выполняющие» инструменты в предыдущем разделе, ложится сюда в точности. Разумно начинать с задач ближе к чтению — просмотр, получение информации, а операции с записью снабжать тщательными ограждениями.
🌐 Насколько можно доверить? Реальные возможности и пределы агента, управляющего браузером, конкретно проверены в материале «Насколько ИИ может автоматизировать работу в браузере». Если уловить дистанцию «не всесилен, но при узком применении практичен», решения по выбору инструментов не будут шататься.
Не только браузер: чем продвинутее инструмент, тем пропорционально больше растёт и «что он может», и «что может случиться». Чем сильнее инструмент вы даёте, тем тщательнее применяйте три принципа — права, описание, ограждения — вот сообщение, которое я повторял на протяжении всей этой главы.
- Возможности агента определяются качеством и числом подключённых инструментов. Часто проектирование инструментов важнее самой головы.
- Голое самостоятельное изготовление инструментов плохо переиспользуется и оборачивается адом комбинаций N×M. Хочется общего разъёма.
- MCP — открытый стандарт, стандартно соединяющий ИИ с внешними инструментами. «USB для ИИ», где клиент (использует) и сервер (предоставляет) общаются по одному соглашению.
- Готовые MCP-серверы (файлы / БД / поиск / SaaS) можно подключить — и работает, а собственные инструменты — сделать своим сервером и переиспользовать.
- Принципы выдачи: ① минимизация прав ② качество описания ③ опасные инструменты отдельно. Чем сильнее инструмент (например, управление браузером), тем осторожнее.
Когда вы разобрались, как комплектовать инструменты, следующая стадия — «размножить агентов». Мы перейдём к проектированию, где работу, которую не тянет один агент, разделяют и связывают несколько. В следующей главе 4 «Проектирование мультиагентных систем» изучим разделение ролей и кооперацию агентов друг с другом (A2A).