MCP — новый стандарт для AI-агентов? | Александр Яковлев

Всех приветствую. Меня зовут Александр. Я руководитель направления AI пайплайнов и ментор по AINGринг. Сегодня я подготовил для вас небольшой и, надеюсь, увлекательный рассказ про MCP.

Что это такое? MCP расшифровывается как Model Context Protocol и значит, буквально следующее. Это стандартный способ подключения агента к внешним инструментам и данным, чтобы лэмка могла не просто болтать, а совершать разные действия.

Сегодня мы разберёмся, для каких задач MCP реально незаменимо и эффективен. А для каких наоборот неудобен и неповоротлив? Увидим, что MCP - это не просто набор инструментов и чем он отличается от опишки с парой промтов. Вживую соберём свой MCP и подключим к простенькой LLM, чтобы она смогла управлять арендованными облачными серверами. И в каких случаях MCP впустую жёт ваши деньги и как этого избежать.

В какой-то момент эта технология получила огромное распространение и не на пустом месте. Карпатый внёс MCP в обязательный стек двадцать пятого года. Сэм Альтман публично его нахваливала, а число скачиваний разных MCP серверов перевалила за 100 млн в месяц. Ну давайте копнём чуть глубже и честно разберём, для каких задач MCP реально крут, а для каких он океill или просто не самый удачный выбор.

Зачем вообще людям понадобился такой протокол? Каждая модель, лмка, агент, whatever, теоретически умеет говорить с каждым инструментом. Но каждую такую связку нужно писать отдельно. И когда нет общепринятого способа это делать, например, четыре модели на четыре инструмента требует 16 отдельных интеграций, каждую из которых нужно разработать и поддерживать. Это N на M. MCP превращает это в N + M. Каждая модель и каждый инструмент подключаются к одному общему контракту, и мы получаем восемь связей вместо шестнадцати.

Аналогия USBC. Вместо того, чтобы плодить для каждого устройства свой порт, свою зарядку, свой переходник, удобнее перейти на один разъём. MCP делает то же самое для AI инструментов. Формально это открытый стандарт от Tropic, появился в ноябре двадцатого, через который LM приложение подключается к внешним инструментам и данным.

В своё время Microsoft запустила Language Server Protocol для VSCOD. Для До этого каждая ID поддерживала каждый язык отдельно, то есть возникала та же та же проблема. Для каждого языка мы пишем свою ID, что супер неэффективно, дорого и так далее. С этим протоколом можно написать языковой сервер один раз, и он работает и с VS-codд, и сWim, и с другими айдиешками. MCP делает то же самое, только вместо ID и языков программирования у нас агенты и инструменты для них.

За всем этим стоит сдвиг парадигмы, который хорошо сформулировал тот же Карпатой от Promt engриering к contex engриering. То есть мы переходим от того, чтобы впихнуть всё нужное в текст промтать модели каналы доступа и подтягивать необходимый контекст, когда это потребуется. Ну и MCP явился технической реализацией такого сдвига.

Итак, у нас есть три роли и один, связывающий всё контракт. хост, среда, где живёт агент, курсор, VS-код и так далее. Клиент, часть хоста, который общается с серверами по протоколу, открывает соединение, держит сессии и сервер. Программа, которая предоставляет инструменты, ресурсы и промты. Это Gthub, базы данных, облако, тасктрекеer, в общем, любой объект, который предоставляет возможности выполнять те или иные действия.

Формат сообщений JSON RPC 2.0. Обычный запрос-ответ в JSON. Транспорт STD ио для локального пользования и HTTP для удалённого. Сессия при этом stateful. По умолчанию хранит состояние между сообщениями, в отличие от обычного REST, где каждый запрос сам по себе. И главное, серверу неважно, кто именно его зовёт, а клиенту, как сервер устроен внутри. Между ними стандартный контракт. Отсюда и переносимость. Один и тот же. Сервер работает и в курсор, и в клодкод, и в кодекс, и в других средах без изменений.

Для полноты картины важно понимать, что MCP - это не только набор инструментов. Примитиво в протоколе на самом деле три. Тулы, с помощью которых агент что-то делает, создаёт задачку, выполняет IP запрос, отправляет сообщение мессенengжер и так далее. Ресурсы - это просто данные, доступные по адресу. Любая полезная информация, которую юзер в тот или иной момент сможет захотеть посмотреть. И промты - это переиспользуемые шаблоны, инструкции, по сути, скилы. которые ю usзер получает при подключении к серверу. Набираешь слш в курсор илид-код. Часть команд может быть как раз от MCP-сервера. Все эти примитивы мы скоро увидим на примере и потрогаем ручками.

За год с небольшим MCP прошёл путь от внутренней разработки атрок до общепринятого стандарта. До России технология уже тоже дошла. У Яндекса есть свои официальные MCP-тулы для работы с облаком. У Вкусвила свой MCP-сервер. Там можно попросить агентика собрать корзины по промту. Я уже даже себе такого ботика сделал. Реально работает.

Есть две ситуации, когда у MCP реально нет альтернативы. Первое, когда у сервиса просто нет публичного IP, ну или пользователь не программист. В этом случае, если сам сервис открывает MCPN Point, это становится самым естественным, а часто и единственным способом. которым агент вообще может дотянуться до него без всяких капч и других проверок на роботов. Вторая ситуация Agent Fest подход. Чем больше у людей персональных агентов, тем выгоднее серверам сервисам открывать MCP и оптимизировать контент под то, чтобы агент их находил. А если сервиса нет в MCP, он просто станет менее видимым в агентных сценариях. В какой-то момент мы даже можем оказаться в положении, что если у сервиса не будет MCP, это как 10 лет назад у сервиса не было бы мобильного приложения. И это вполне правдоподобный сценарий.

Платформы, предоставляющие услуги интеграции, сами называют MCP угрозой их бизнес-модели. Ну и это, на самом деле, уже происходит. Про Яндекс я уже сказал, это самая полная руикосистема. К архив можно подключить MCP. Агент сможет тянуть статьи, цитаты, метаданные. Entry позволяет агенту поймать ошибку с трейсом, конкретными строками и файлами, где что-то упало. А через GitHub агент может открыть эти файлы, посмотреть свежие полурекревесты и, например, предложить фикс. Жиры, confluence, bitбаet дают агенту возможность детонуться до задач, доков и кода. Shopify позволяет агенту шопиться, искать товары в каталоге магазина, смотреть цены, наличие, собирать корзину и так далее. Кстати, сейчас похожий функционал делают Яндекс Market и Яндекславка на базе Алисы.

На этом слайде мы видим цену, которую приходится платить за использование MCP не по назначению. В двадцать пятом году сделали замер, сколько токенов уходит у агента просто на то, чтобы подключить GitHub MCP. Получилось около 23.000 токенов. То есть сервер грузит в контекст схемы всех своих инструментов сразу. Если то же самое сделать через GitHub C, токенов тратится почти ноль. Схемы в контексте нет. Агент зовёт её как мы с вами, просто командой в консоль. А понимает он, какие команды нужно вызвать просто из общих знаний. Сегодня мы повторим этот замер вживую и увидим эффект своими глазами.

Теперь разберём два способа раздать одну и ту же возможность, например, своей команде на работе. Скил или правила - это просто текстовый файлы в репозитории. Автор написал один раз, команда потянула, каждый поправил формулировку под себя и заодно гит истории с кодрев бесплатно из коробки. А вот MCP сервер просто так вот не поправишь. Чтобы кастомизировать его под себя, нужно его клонировать, пропатчить, как-то поднять на каждого или на всю команду. И каждый раз, когда оригинал обновляется, ещё и разрешать нетривиальные конфликты в коде. То есть довольно неприятные сопутствующие трудности. Поэтому MCP, по большому счёту, нужен ровно там, где без него не справиться. Это способ больше про унификацию и контроль со стороны владельца сервиса. М а где есть CLI или открытая IP, скил с инструкцией часто выигрывает, даёт контроль уже юзеру, большую кастомизацию и обходится дешевле по токенам.

Под капотом всё довольно просто. Давайте проследим на одном вызове тула. Что реально летает между агентом и сервером? Когда агент подключается к MCP- серверу, он шлёт такую цепочку. Сперва Initialй - это рукопожатие. Я клиент такой-то версии. Что ты умеешь? Сервер отвечает на него списком возможностей. Дальше Tools List. Покажи, что у тебя есть. М. Сервер возвращает описание инструментов, имя, схема параметров, текстовое описание для модели. И чтобы что-то сделать, Tools call, вызови инструмент с такими-то аргументами. Сервер выполняет и возвращает результат. Всё это обычный Jon PC, который передаётся по транспорту. И сейчас мы как раз увидим это на примере.

Теперь переместимся в курсор. Сейчас мы напишем свой MCP сервер на Python. Кстати, писать MCP-сервер можно абсолютно на любом языке. Подключим его к агентам из разных агентских айдиишек. Я выбрал рукод, может быть, не очень популярный clotдко и курсор, собственно, нативный агент курсора. И посмотрим, как он работает с реально арендованным сервером. У меня есть сервера на Яндекс Clуде. Вот к ним и будем ходить и что-то делать с ними. Давайте нач м в конце ещё, как обещал, замерим разницу в потреблении токенов между использованием MCP и простого промта для одной и той же задачи. Но давайте начнём с сервера. Я заранее создал описание того, что будет делать каждый инструмент, и составил один пром для разнообразия. Если помните, я говорил, что MCP - это не только тулы. Так что посмотрим на все его возможности разом. М, audit cloud. М, тут я просто написал: "Посмотри на мой Яндекс Cloud, там перечисли все VM, которые есть, посмотри, какие простаивают больше стольких-то дней". Там, чтобы это был кандидат на чистку. Предложи это, например, мне удалить, если оно там реально простаивает и ненужном, зачем за это деньги платить? И в общем, сделай отчёт об этом. Вот. Ничего не удаляй без моего подтверждения. Вот четыре тулы ещё сделал. Первое - это снести всё в песочнице. Песочница - это отдельная изолированная папка. Просто я её отделил физически от моих реальных серверов, чтобы агент не путался и не удалил случайно мне всё, что мне нужно. М, посмотри простаивающих кандидатов. Мм, то есть принимай параметр, сколько дней простая простое, например, семь по умолчанию. Ну и перечислит, какие вмки сейчас действительно не используются. Может быть, надо их снести. Собственно, верни список всего, что есть, какие вмки сейчас есть у меня в облаки. И создать новую VM. М, я сделал префикс MCPдема, чтобы там они не путались опять же друг с другом на всякий случай. Вот. И тут перечислил параметры, с которыми создать ВМКУ. Это самая такая дешёвая конфигурация на Яндексклауде. Вот. чтобы много не платить. Мм, и написал команду, которая создаёт такую ВМКУ. Вот, чтобы она вокруг мм наш наша MCP тула будет обёрткой над этой командой. Просто вот и ещё я придумал такой ресурс. по этому урлу будет локальному будет доступна информация о том, в какой в нашей песочнице сколько вмок в данный момент активны. Вот, например, я забуду почистить в конце видео. Вот я могу зайти на этот local host условный и посмотреть. О'кей, у меня тут что-то простаивает, давайте удалим. Вот это так для демонстрации возможностей. О'кей. Все эти тексты мы сейчас передадим кдут вместе с промтом. Давайте свояем промт. Изучи вот эту папку. Наша цель написать YC Local serverp и подключить его к Row код код и курсор через м через м ну ладно, по-другому и курсор используй fast mcp stdo. По сути обёртка над YC силы I subпроess. Я уже авторизован в YC. Так, реализуй все четыре тула. Плюс один ресурс, плюс один промт по спекам. Config и mask public IP из ENV. Маскируй публичные IP в выводах. инструментов. Сейчас допишу и разберём поподробнее, что я тут прошу сделать. Вот пока он будет работать. Пример создания VM в oneшот. М. Если тебе не хватает текста про устройство MCP, сделай миниarch. Так, давайте выберем Opus. Ну, пусть Опус будет и немножко попланируем. Так что я тут ему дал. Во-первых, fast MCP - это официальный фреймворк для MCP серверов на Python. Он позволяет писать примитивы как обычные Python функции. Покажу, как это работает, когда сервер будет готов. М, subpress - это просто модуль Python для запуска любых программ. С помощью него мы без терминала будем запускать YC Яндекс Cloud консоль, ловить и парсить вывод. И сам YCI - это просто официальная Яндекс Cloud утилита для управления облаком через терминал. Там уже есть авторизации и все нужные нам вызовы. То есть мы строим по сути над ней свою кастомную обёртку. Хочу сделать тут мини-ремарку. Я добавил в конце. Если тебе не хватает контекста, сделай miniни research. Дело в том, что у Клода знания примерно на середине прошлого года обрываются, поэтому он может не знать про устройство современных MCP. Угу. Хотел cн сделать, но я ему заплетил это в настройках. О'кей, давайте посмотрим, что ещё я ему тут скормил. Example. Тут просто у нас бинарник вот этой утилиты для работы с Яндекс Cloud. ID папки вот этой нашей песочницы, которую я создал. Подсеть, геозона, в которой расположена машина. Префикс просто для пущей пущей пущего разделения мм вот этих игрушечных ВМ и настоящих. и маскировка, включение маскировки IP, чтобы агент не видел, что у нас за айпишники, он всё равно с ними работает по айдишникам ресурсов. Мм, так MCP Jonт в репо. Single. Он спрашивает, нужно ли один скрипт написать или как-то там покрасивее развести.Х. Да, покажу, что за MCPJSON. Он выглядит примерно вот так. То есть MCP Servers, как назовём этот MCP сервер? Команда бинарня, который его будет запускать. И, собственно, простая команда запустить в такой-то директории скрипт, который мы сейчас напишем. Вот. Потрясающе, что не нужно писать для разных м айдиишек разные эти jйсонки. Она одна и та же у меня для всех трёх. Тут она немножечко отдекорировалась, но это на самом деле сделал сам Рукот. Это не я сделал. Вот он там при подгрузке он его чуть-чуть под свой манёвр, под свой манер переписывает. Так, план готов. Давайте быстро прочитаем. Создавать. И удава удалять машины можно только в песочнице, что хорошо. Один файл config есть. Вот так он будет реализовывать вызов терминала. В общем, всё чётко, вроде бы понял. Давайте делать. Давайте переключимся тут даже на сонета, чтобы ещё быстрее было. О'кей, давайте откроем рукод. Пока что покажу, как это тут устроено. Вот я выбрал простую модельку такую dipic 3.2. не самая умная, но стулами работать умеет. Вот покажем, что даже она справится с нашими задачками. И вот тут есть MCP сервера. Вот он по Jсонке видит, что какой-то сервер есть, но пока что он не сможет к нему подключиться. А, угу, сервер уже написан, поэтому смог. Вот. Ну, anyway. Сейчас проверим работоспособность также и в других айдиишках. Давайте включим, посмотрим. Ага, в принципе, всё уже написано и работает. Давайте посмотрим, что у нас тут есть. У нас тут четыре инструмента, которые я уже рассказывал, что делают. один промтик skill команда, который через слш можно вызывать и ресурс. Выглядит он вот так. В данный момент в песочнице у нас нет вэмок. Сейчас мы создадим там Вэмку и посмотрим как раз, что оно изменилось. Причём создавать мы будем в рукоде, а смотреть здесь. Вот такая у нас кроссплатформенная вещь получилась. Так, ну сперва пройдемся по коду. Вот здесь он вызывает команду через Python модуль. И делает он это хорошо. Вот давайте сразу расскажу, как можно было бы это сломать. Если бы мы написали что-то типа того, прок равно sub process run. И здесь бы сделали join аргументов и shell равно true, то мы бы сделали следующее. Мы бы передали просто, мм, ну, представьте такую ситуацию. Злоумышленник как-то смог подкинуть вам аргумент, и, допустим, один из них будет вот такой. Arg равно наше любимое МФ всего. Вот тогда, так как эта команда она выполнила бы вот этот вот кусок, поскольку мы это всё схлопнули в одну строку, последовательно она бы сначала выполнила то, что мы хотели, а дальше бы снесла нам систему. Вот это опасная вещь. И довольно часто MCP сервера к такой штуке уязвимы. Вот, мм, здесь максимум, ну, только параметры нам могут подкинуть какие-нибудь вредоносные. В теории можно, наверное, придумать какую-нибудь атаку через параметры. Ну, это гораздо сложнее. Угу. Тут маскировка. Оставляем только первые два октета. Давайте посмотрим на Fast MCP. Вот видим, что код просто буквально обычная Python функция, а всю машинерию, связанную с тем, как это перевести в реальный инструмент, делает как раз декоратор из fast MCP фреймворка. Вот крутая штука. описание она прокидывает в описание самих тулов. Если посмотрим, то вот оно здесь будет. Вот. Что ещё тут интересного? Ну, для промта немножко по-другому декорируется. И для ресурса тоже своим образом добавляет ещё в том числе адрес, по которому будет доступен наш ресурс. Так, ну, в принципе, всё. Давайте ещё покажу быстренько MCP Инспектор. Это нативный способ тестировать функционал MCP сервера при разработке. Тут я пишу примерно такую же команду, которая у нас в Jсонках запускает всю весь этот сервер. Только добавляю ещё инспектор тут. Угу. Надеюсь, он где надо расположен. Давайте проверим путь. Где у нас написан? Вроде бы, да. Угу. Да. Вот наш MCP инспектор. Давайте подключимся. На самом деле это у нас уже буквально работающий сервер. Мы можем его прямо отсюда потыкать. Вот что-то такое похожее на Postman, только для MCP серверов. Можно проверить работоспособность всех своих написанных штук. Тут в меня не влезли табики сверху, оказывается, но в инспектор есть переключатель между resources, prompts, Tools и другими вкладками. Давайте посмотрим вот наш ресурс. Это то, как он сейчас выглядит. М, здесь у нас промты. можем менять параметр, сколько дней простое, и промт будет под это дело адаптироваться. И тулы, вот наши четыре тулы. Давайте что-нибудь вызовем, например, перечислим, какие у нас есть сейчас вмки в облаке. Всё работает. Уран. М. Да, у нас вот такие две ВМК. Это мои настоящие ВМ. М. Вот айпишники у них замаскированы, как и просили. Отлично. И ещё у нас есть тут интересная штука такая environment variables. Вот. На самом деле, если мы тут напишем mask public ip false, то сразу сможем протестировать, как это отразится на нашей туле. На самом деле она при вернёт то же самое, только не будет ничего маскировать. В общем, надеюсь, понятно, как это работает. Такая вот баг утилитка у нас. И внизу мы видим то, что обсуждали на слайдах. initialйiz tools list tools call и подобные штуки для промтов и ресурсов. Вот можно в это всё хорошенько потыкаться, чтобы лучше понять принцип работы. Сейчас это нам пока больше не пригодится. Давайте попробуем сделать какую-нибудь задачку. Так, давайте покажи мои ВМ в облаке. Найди простаивающие и подними мне песочницу. Тест один. Отвечай на русском. Угу. Вот. А провы очень важно выдавать, по крайней мере, поначалу на инструменты. Вот, чтобы он не сам это всё делал. Там l all и поехали автономно. Вот нужно следить за тем, что мы делаем. как работает, особенно только то, что мы сейчас написали. Мм, посмотрим. Да, вот тот же замаскированный вывод. Он нашёл все мои машинки. Отлично. Теперь ищет простаивающие. По умолчанию это неделя без какой-либо активности. И теперь попробует поднять песочницу. Ну, как я говорил, самая дешёвая конфигурация, там прерываемая машинка с одной 1 Гбм и всё такое. Давайте следить через наш ресурс, что там происходит. О, на самом деле машина уже поднялась. Вот и ресурс обновился. Нам не нужно. Позакрываю лишнее. Что-то много всего. Так, отлично, всё сделано. Вот мы видим, как модель за несколько минут научилась ходить к нам в облако, что-то там делать. Вот, на самом деле, могли любые абсолютные инструменты написать. Вот там, не знаю, хотим мы задеплоить нового бота. О'кей, сходи на ВМ, проверь на какой больше всего места и ресурсов для данной конфигурации, и разверни его там, например. Вот это удобный такой, удобная такая вещь. И давайте под конец почистим то, что мы создали. Снеси всё в Sandbox. Так, а также через ресурс проверим, что всё получилось. И потом сделаем ещё подход к промту, который мы написали, через курсор просто для разнообразия. Ага, удалена. Давайте проверим, что она реально удалена. Да, вмок больше нет. Отлично. Переходим в компоер. И помните, мы писали ещё промт. Вот мы видим его здесь. Audit Cloud YC Local Audit Cloud. В принципе, тут можно дописать что-нибудь ещё, какой-нибудь контекст добавить. Ну, в данном случае контекст не нужен. Просто пусть сделает то, что написано в промте, то есть аудит. Проверим ещё, подключилась ли в код-коде. Вот. И в кодкоде тоже работает. Супер. Ну вот. И он пошёл вызывать эти тулы там, потому что вот у него такая инструкция. Отлично. У меня есть такие инструменты. Пойду-ка я их вызову. Вот он на самом деле пошёл разыскивать, какие тулы у него имеются для решения этой задачи. Ну и всё сделал. Итак, мы увидели путь от нуля до готового функционального MCP-сервера за несколько минут и даже сделали с помощью него несколько физических действий. На самом деле серверами и вправду может быть неприятно управлять. Лично у меня для агента на этот случай прописаны скилы. Я с этой консолью только через агента общаюсь. И сейчас мы, кстати, замерим разницу этих двух подходов на ещё более понятном примере. Давайте закроем всё лишнее. В конце я вот хочу показать, что происходит, когда вы просто подключаете себе MCP и подгружаете целиком в контекст модели. А именно, все имеющиеся тулы, промты складываются в контекст модели, что тратит лишние деньги, забивает её контекст и может заметно снижать способности выполнять задачи, для которых MCP вообще не требуется. Справедливости ради. Это происходит сейчас не у всех провайдеров, но проблема всё ещё сохраняется. Возьмём реальный GitHub MCP м несколькими десятками тулов и замерим, во сколько токенов обходится его подключение вот так в лоб, когда модель получает на вход описание всех тулов. И потом сравним с тем, как ту же задачу решает агент, действуя напрямую через консоль. Первым делом стянем реальное описание и схемы тулов с официального GitHub MCP сервера. Сейчас запущу небольшой скрипт, который это сделает. Мм, и Вера Python м capche. Вот мы поднимаем настоящий GitHub MCP в докере, забираем у него список инструментов и получили 44 тула, около 60 Кб. О'кей, давайте на них посмотрим. Вот видим здесь имя, тулы, что она делает, описание и какую-то схему, какие параметры она принимает. Вот и таких 44 штуки. Вот эта вся простыня в целом и грузится в контекст модели в начале диалога. Я написал тут скрипт, чтобы замерить разницу в потреблении токенов у MCP подхода и у лобового. Вот в лобовом мы делаем просто ему system инструкцию такой system bromt. Можешь использовать Ghubi для задач, связанных с гитubбом. Кстати, само задание я так и не озвучил. Оно было: "Перечисли пять последних полуреквестов в данном репозитории". Вот давайте запустим этот скрипт, и он обсчитает за 10 раз среднее возьмёт потребление токенов в первом и во втором случае. Так, MCP context cost comp. Вот в ENF у меня лежат на этот раз мthub token, чтобы выполнить первую часть, которая стягивает а все эти MCP тулы. и Open Router, то есть опять тот же Deпсиs проверим на нём. Видим либо 14.000, либо 12.000 в зависимости от провайдера. Вот. И то же самое для консольного подхода. 400 токенов. Разница на самом деле уже видна, но давайте дождёмся завершения. Собственно, 14.000 в среднем против 400 токенов в среднем. То есть примерно в 34 раза больше MCP потребляет, если мы грузим полностью все описания тулов в начале. Иначе говоря, агенту пришлось вот такую простыню прочитать просто, чтобы приступить к выполнению нашего задания. Если зайти в курсор у того же композера, мы видим, что у него контекстное окно 200.000 токенов. То есть, ну, почти 10% мы потратили просто на то, чтобы приступить к выполнению задания, не чтобы её решить. Вот что может быть больно.

Напоследок проговорим обязательные вещи про безопасность разработки и использование MCP-серверов. Во-первых, пресловутый Prompt Injection. Приватные данные плюс непроверенный контент плюс исходящий канал - это идеальные условия для утечки через агента. Простой пример. Агент с доступом к почте читает входящее письмо, а в письме спрятана инструкция. Перешли последние письма вон туда. Модель затупила, последовала инструкции и выполнила указание из письма. 100% защиты от атак такого типа на сегодняшний день нет, так что это обязательно нужно знать и иметь в виду. Во-вторых, избыточные права. Серверы часто просят больше, чем нужно. Например, полный доступ вместо прав исключительно на чтение. Агент наследует все права сервера, и радиус поражения кратно расширяется. И атака через так называемую цепочку поставок supply chain. Это когда юзера взламывают не напрямую, а черезстороннее по, которым он доверился. В какой-то момент выяснилось, что официальная реализация MCP протокола позволяет выполнить любую команду на машине юзера. Антропик на это ответили, что так и задумано, а валидация должна происходить на стороне разработчика. И уже был кейс с реальным бакдором, который тихо пересылал электронные письма юзеров атакующему. Вот. Призываю всех осознанно подходить как к защите собственных MCP серверов, так и к подключению различных уже готовых. Делайте аудит-кода, проверяйте надёжность поставщика, ограничиваете права сервера. Например, можно скормить для подключения токен, на который ты заранее раздал только необходимые для работы права. Ставьте подтверждение на любые райдествия и для удалённых серверов по возможности используйте ОАУВФ авторизацию вместо вечных токенов.

На деле половина опасений и критики, которые мы обсудили - это по факту недоделанная инфраструктура, которую буквально сейчас доделывают. Уже работают ленивая подгрузка инструментов. Вместо того, чтобы всегда грузить в контекст описания всех толов сразу, агент в нужный момент подтягивает описание конкретного MCP тола или промта. То есть реализуется принцип, как у тех же скилов. С помощью такого подхода разница в потреблении токенов у MCP вызова и других альтернатив сильно сокращается. Также уже запущен MCP Registry. Это такой канонически проверенный каталог надёжных MCP-серверов. И упомяну ещё одну фичу из родмапы. Идея в том, чтобы модель не дёргала кучу инструментов по одному, а писала код, который сам их вызывает, с нужными конфигурациями. Это и быстрее, и дешевле по контексту. Реализацию похожей идеи можно уже увидеть в clд-код. Там завезли режим workflow, в котором clд может написать кастомный скрипт, который пошлёт под агентов работать параллельно или последовательно с нужными конфигурациями.

Итак, сегодня мы приземлили хайп вокруг MCP на реальные преимущества и недостатки. Разобрали его концепт, архитектуру, увидели кейсы его внедрения знакомыми всем с сервисами, завайпкодили почти с нуля объективно полезный сервер, рассмотрели альтернативные подходы и немного поговорили про безопасность. Я считаю, о безопасности вообще важно говорить, чуть ли не в каждой статье, видосе, посте лишним точно не будет. Давайте подытожим.

Во-первых, MCP крутая штука. Она даёт нам единый контракт связи агента и некого инструментария вместо десятка отдельных интеграций. Во-вторых, это не замена скилам и прочим подходам. У каждого инструмента есть удачные юзкейсы и юзкейсы, где преимущества этого инструмента не раскрываются. Важно понимать, зачем вы используете тот или иной инструмент и в целом уметь им пользоваться. Как, не знаю, топором. Если не уметь обращаться с топором, его применение может иметь весьма неприятные последствия. В-третьих, MCP - это не только способ прокачать агента, пишущего код, а в целом новая парадигма, которая может позволить агенту заказывать еду, не знаю, бронить еду в ресторане, бронить еду в ресторане, бронить столик в ресторане или разбирать вашу почту. И если сервис не имеет такой обёртки, делать это неприятно. Либо вообще бывает почти невозможно.

На этом всё. Спасибо, если досмотрели. Пишите, какие клёвые MCP вы знаете или используете. Да и в целом любые вопросы. Постараюсь ответить на них в комментариях. Аревидерчи. Да.