Transcription
Приветствуем всех. Сегодня у нас на повестке дня, ну, я бы сказала, весьма интригующая технология. Называется Model Control или MCP, если коротко.
Привет. Да, MCP - тема горячая. Много о ней говорят в последнее время.
Мы будем опираться на материалы довольно подробного видеообзора. Там хорошо так разложена основы MCP, есть примеры и с кодом, и без. В общем, наша задача - разобраться, что это за зверь такой, этот MCP, зачем он нужен, ну и как работает.
Совершенно верно. И разобраться стоит, потому что это, по сути, попытка навести порядок в том, как большие языковые модели, ну, LLM и приложения на их основе, как они общаются с внешним миром, с инструментами, с данными.
Навести порядок звучит так, будто раньше был беспорядок. Ну, мягко говоря, представьте себе мир до USB. Вот честно, у вас есть компьютер, есть принтер, сканер, мышь, клавиатура, внешний диск, и у каждого свой разъём. LPT порт, COM порт, PS2, SCSI.
Ох, да, помню LPT порт для принтера, такой широкий, с защёлками. И вечно драйвера не те.
Вот куча проводов, переходников, под каждое устройство свой драйвер, свои настройки, полный хаос. А потом появился USB, один стандарт для всего, и периферия просто взорвалась, стало легко всё подключать. Вот MCP - это такая амбиция стать USB для LLM и инструментов. Универсальный способ подключения.
Интересная аналогия USB для AI. Хорошо, давай тогда распаковывать. MCP - Model Context Protocol. В видео давали определение от Anthropic. Это же они его придумали, >> да?
Anthropic. Они его определяют как, сейчас попробую воспроизвести, открытый протокол, который стандартизирует, как ваши LLM-приложения подключаются к вашим инструментам и источникам данных и работают с ними. Вот так. Довольно формально.
Формально, да. А если своими словами, что это значит вот для меня как для разработчика или даже просто для пользователя?
А вот давайте на примере. Представьте, вы хотите сделать AI-ассистента, ну, такого умного помощника, который, скажем, умеет назначать встречи.
Ага. Полезная штука.
Очень. Но чтобы он мог это делать, ему что нужно? Ему нужен доступ к вашему календарю, к почте, чтобы проверить доступность людей, отправить приглашение. Возможно, к Zoom или Google Meet, чтобы создать ссылку на видеовстречу. Может быть, к Slack, если вы им пользуетесь. А если это корпоративный помощник, то ещё и к внутренней CRM или базе контактов.
Да, уже целый список получается.
И вот до MCP для каждого из этих сервисов - календаря, Google, Outlook, Zoom API, CRM API - вам пришлось бы писать отдельный код интеграции, изучать документацию каждого API. Они все разные. Разные форматы данных, разные способы аутентификации, разная обработка ошибок. Это часы, дни, неделя работы, только на то, чтобы подключить эти инструменты.
Звучит как боль. Та самая аналогия с кучей разных портов и драйверов.
Именно. А MCP говорит: "Ребята, давайте договоримся об одном языке. Вместо того, чтобы каждый инструмент говорил на своём диалекте API, давайте создадим общий протокол общения. Приложение, ваш AI-ассистент, будет говорить на языке MCP, и каждый инструмент - календарь, почта, Zoom - будет предоставлять переводчика на этот язык, то есть MCP-сервер."
И это сработало. Судя по цифрам из видео, более 20.000 серверов. Похоже, что да.
Похоже, что да. Эта цифра, конечно, впечатляет. 20.000 готовых MCP-серверов за относительно короткое время. Это говорит о том, что идея стандартизации нашла отклик. Разработчики увидели в этом ценность и начали создавать эти сервера-переводчики для своих инструментов и данных.
В видео приводили пример с сервером Alpha Vantage. Это что-то про финансы? Да.
Да. Alpha Vantage - это сервис, который предоставляет доступ к рыночным данным: котировки акций, курсы валют, криптовалюты, экономические индикаторы. И вот, как показали в видео, у них есть готовый MCP-сервер.
И как его использовать?
А вот тут самое интересное. Показывали на примере Claude Desktop - это приложение от Anthropic. В его настройках есть секция для добавления MCP-серверов. Туда нужно просто скопировать небольшой кусочек текста, по сути, адрес сервера и краткое описание того, что он умеет делать. Это называется, кажется, манифест сервера.
Просто скопировать текст, не нужно писать код.
В этом случае нет. Просто копируешь этот манифест, и Claude узнаёт о существовании этого сервера Alpha Vantage и о его возможностях. Всё, теперь Claude может им пользоваться.
И что он делал в примере?
Там был забавный пример с ценами на кофе. Пользователь попросил Claude показать динамику цен на кофе за последние 10 лет. Claude понял, что для этого у него есть подключённый инструмент от Alpha Vantage. Он сначала запросил у пользователя разрешение: "Могу ли я использовать функцию Get Coffee Prices от сервера Alpha Vantage?"
А, то есть контроль у пользователя остаётся. Это важно.
Безусловно, безопасность и контроль - ключевые моменты. Пользователь дал согласие. Claude обратился к MCP-серверу Alpha Vantage, передал ему запрос конкретно: "Дай цены на кофе за 10 лет". Сервер сходил к себе в базу Alpha Vantage, получил эти данные и вернул их Claude по протоколу MCP.
И что Claude с ними сделал? Просто показал цифры.
Нет, он пошёл дальше. Он получил эти данные и прямо в интерфейсе чата построил интерактивный график. То есть он не просто получил данные, но и смог их обработать и визуализировать. И всё это выглядело как обычный разговор с чатботом. Но под капотом работала целая цепочка: Host (Claude) -> Client (MCP) -> Protocol (MCP) -> Server (MCP) -> Server API (Alpha Vantage) -> Real Source of Data (Alpha Vantage).
Впечатляет, особенно вот эта лёгкость подключения - просто скопировать манифест. Ещё видео подчёркивали гибкость. Кажется, что тот же сервер можно использовать не только в Claude.
Точно. И это, возможно, главное преимущество. Смотрите, сегодня вы используете Claude Desktop как хост-приложение для работы с сервером Alpha Vantage. А завтра вы решили построить свою систему автоматизации на платформе N8N или вообще написать собственное приложение на Python.
И что, придётся заново интегрироваться с Alpha Vantage?
А вот и нет. Если ваше новое приложение N8N или ваш код умеет говорить на языке MCP, то есть имеет MCP-клиент, вы просто берёте тот же самый манифест сервера Alpha Vantage и подключаете его к своему новому хосту, и он будет работать точно так же.
Ого. То есть сервер становится таким переиспользуемым кирпичиком?
Совершенно верно. Это принцип компонуемости. Вы один раз создаёте или находите MCP-сервер для нужного вам инструмента. Погода, база данных, CRM, отправка SMS, что угодно. И потом можете использовать этот "кирпичик" в любом MCP-совместимом приложении-хосте. Это разделяет разработку. Одни люди делают классные инструменты, серверы, другие - классные приложения-хосты, которые эти инструменты используют. Не нужно каждой команде заново изобретать велосипед для интеграции с каждым сервисом. Это действительно похоже на революцию, как с USB. Потенциал огромный.
Хорошо, тогда надо копать глубже. Как это устроено технически? В видео говорили про архитектуру. Хост, клиент, сервер, HCS.
Да, HCS - это основа архитектуры MCP. Давайте разберём каждую букву. Host - это, как мы уже поняли, само приложение, которое хочет получить доступ к внешним возможностям. Мозг операции, так сказать. В примерах это были Claude Desktop и N8N, но это может быть VS Code с AI-помощником, и какой-нибудь специализированный AI-агент для анализа данных, и чатбот на веб-сайте. Любое LLM-приложение, которому нужны внешние руки или глаза.
Окей, с хостом понятно. Дальше S.
Server. Сервер принимает запросы по протоколу MCP и выполняет их. Сервер капсулирует логику работы с конкретным инструментом или источником данных. Например, MCP-сервер для Gmail знает, как именно через Gmail API отправить письмо. MCP-сервер для Alpha Vantage знает, как запросить котировки. Важно, что серверы обычно стараются делать легковесными. Они посредники.
Посредники между кем и кем?
Между хостом и реальным сервисом. Именно между MCP-клиентом, который внутри хоста, и реальным API или базой данных. Сервер прячет всю сложность реального API за простым и стандартным MCP-интерфейсом. И этих серверов, как мы слышали, уже тысячи. Для работы со временем, с файлами, с базами данных (PostgreSQL, MySQL), с Git, с Redis, с облачными сервисами - почти со всем, что имеет API.
Хорошо. H есть, S есть, остался C. Клиент.
Клиент. И вот тут важный нюанс, который часто путают. Клиент - это не отдельное приложение. Клиент живёт внутри хоста. Это как бы встроенный в хост-приложение модуль, который умеет говорить на языке MCP. Его задача - взять пожелание от хоста, например, "хочу отправить письмо", и преобразовать его в конкретный запрос по протоколу MCP к выбранному MCP-серверу, и потом получить ответ от сервера и передать его обратно хосту. Каждый клиент обычно устанавливает соединение один на один с конкретным сервером.
Ага. То есть, если Claude host хочет поговорить с сервером Alpha Vantage, то он использует свой внутренний модуль MCP-клиент, чтобы установить связь и обменяться сообщениями по протоколу MCP.
Точно. Хост говорит: "Клиент, свяжись с сервером Alpha Vantage вот по этому адресу и попроси у него цены на кофе". Клиент берёт под козырёк, устанавливает соединение по MCP, отправляет формализованный запрос серверу, получает ответ, декодирует его и отдаёт хосту в понятном виде.
Эта архитектура HCS выглядит логичной. Она разделяет ответственность. Хост думает, что делать. Клиент знает, как говорить по MCP, а сервер знает, как выполнить конкретное действие или достать данные.
Да, и это разделение как раз и обеспечивает гибкость и переиспользуемость. Можно менять хосты, можно менять сервера, а протокол MCP и клиент внутри хоста остаются связующим звеном.
Но вот дальше в видео был ещё один уровень детализации про то, что находится внутри сервера. Оказывается, это не просто набор функций, там говорили про TRP: инструменты, ресурсы и шаблоны промтов. Вот это мне показалось особенно интересным.
О, да. TRP действительно важная часть концепции MCP, которая делает её гораздо мощнее, чем просто RPC (Remote Procedure Call) для LLM. Давайте разберём каждый компонент. T - Инструменты (Tools). Это самое очевидное. Это, по сути, функции или действия, которые сервер может выполнить по запросу клиента: отправить письмо, посчитать что-то на калькуляторе, получить котировки акций, добавить запись в базу данных, найти пользователя в CRM, запустить сборку проектов CI/CD, сгенерировать картинку - любая активная операция. Клиент говорит: "Используй инструмент X с параметрами Y и Z".
Понятно. Это как вызов функции в программировании.
В общем, да. Но есть ещё R - Ресурсы (Resources). А вот это уже интереснее. Ресурсы - это данные, которые сервер предоставляет клиенту только для чтения. Клиент может запросить содержание ресурса, но не может его изменить через MCP. Это важно.
А зачем это нужно? Почему не сделать всё инструментами?
Хороший вопрос. Представьте, что у вас есть большой файл с логами или, скажем, документация к какому-то продукту в виде Markdown файла или данные из базы данных, которые часто нужны для справки, но менять их не требуется. Например, список стран или архив контрактов. Делать для этого инструмент, который каждый раз будет читать файл или делать SELECT, может быть неэффективно, особенно если данные большие или запрашиваются часто. Ресурс - это как бы заранее подготовленный снимок данных, который сервер может отдать быстро и без лишних действий.
А, то есть это оптимизация для получения статических или редко меняющихся данных.
В том числе, но не только. Это ещё и семантическое разделение. Инструменты - это действия. Они могут иметь побочные эффекты: отправка письма, изменения БД. Ресурсы - это данные. Они безопасны для чтения. Это помогает LLM-хосту лучше понимать, что можно делать с сервером. В видео приводили пример: ресурс может быть логом всех изменений в БД, сделанных через инструменты этого же сервера. Клиент может прочитать этот лог-ресурс, но не может его изменить.
Логично. Инструменты для действий, ресурсы для данных. А что такое P? Шаблоны промтов (Prompt Templates). Вот это звучит загадочно.
P - Шаблоны промтов (Prompt Templates). Да, это, пожалуй, самая такая продвинутая фишка TRP. Шаблон промпта - это не просто функция и не просто данные. Это, по сути, заранее подготовленный, хорошо продуманный рецепт или инструкция для самой большой языковой модели (LLM), которая сидит в хосте.
Инструкция для LLM. Зачем? Она же сама умная.
Она умная, да, но чтобы получить от неё максимально качественный результат для конкретной задачи, связанной с конкретным сервером, часто нужен очень специфический, детальный промт. Написать такой промт с нуля может быть сложно и для человека, и для другой LLM. Промт-инжиниринг - это целое искусство.
А, то есть разработчик сервера, который лучше всех знает свой инструмент и данные, может заранее подготовить идеальный промт для типовых задач.
Именно. Он создаёт шаблон промпта. В этом шаблоне уже заложены все нюансы: какой стиль ответа ожидается, на что обратить внимание в данных, как структурировать вывод, какие шаги анализа предпринять. Пользователю или агенту в хосте остаётся только заполнить пробелы в этом шаблоне. Например, подставить конкретные данные для анализа или указать цель.
Можете привести пример, вот тот про анализ стенограмм.
Да, отличный пример. Допустим, есть MCP-сервер для работы со стенограммами совещаний. У него есть инструмент "загрузить стенограмму" и, возможно, ресурс "список участников". А ещё разработчик создал шаблон промпта "создать отчёт по совещанию". Если просто сказать LLM: "проанализируй стенограмму", результат будет непредсказуемым. А если сказать: "Используй шаблон "создать отчёт по совещанию" для вот этой стенограммы", то LLM получит от сервера детальную инструкцию: "Один. Найди ключевые решения, выведи списком. Два. Идентифицируй все задачи, создай таблицу: Задача - Ответственный - Срок. Три. Отметь пункты, требующие дальнейшего обсуждения. Четыре. Сделай краткое резюме, не более 100 слов. Пять. Формат вывода: Markdown." Понимаете, шаблон задаёт структуру и требования к результату. LLM остаётся только применить свои способности к тексту, следуя этому рецепту.
Теперь понятнее. Это как бы способ передать экспертизу по использованию инструмента прямо в сам инструмент. Не только что делать (инструменты) и что использовать (ресурсы), но и как лучше это сделать (шаблоны).
Совершенно верно. Это позволяет получать более стабильные, качественные и предсказуемые результаты от взаимодействия с LLM через MCP. В видео приводили комплексный пример с сервером для SQLite.
Да, да, я помню. Там были инструменты: read, insert, update, delete - стандартные операции с базой. Был ресурс: log изменений в базе, только на чтение. И были шаблоны промтов, например, для генерации оптимального SQL-запроса по описанию на естественном языке, учитывая схему этой конкретной базы.
Вот этот пример отлично показывает, как все три компонента TRP - инструменты, ресурсы и шаблоны - могут работать вместе в рамках одного MCP-сервера, делая его гораздо более мощным и удобным, чем просто набор API-поинтов.
Значит, архитектура HCS и начинка серверов TRP - это ключевые концепции. Хорошо. А как происходит само общение? Вот клиент хочет вызвать инструмент на сервере. Что происходит технически? Жизненный цикл коммуникации?
Есть три основных этапа. Один - рукопожатие (handshake). На этом этапе может происходить обмен какой-то метаинформацией, проверка совместимости версии протокола, возможно, аутентификация. Два - обмен сообщениями (message exchange). Это основная работа. Клиент шлёт запросы: "Вызови инструмент X", "Дай ресурс Y", "Примени шаблон Z к данным W". Сервер обрабатывает запрос, выполняет нужные действия или читает данные или готовит ответ по шаблону и отправляет ответ обратно клиенту. Таких циклов запрос-ответ может быть много. Три - завершение (termination). Когда работа сделана или хост больше не нужен этот сервер, клиент или иногда сервер инициирует разрыв соединения. Все ресурсы освобождаются.
Это понятно на концептуальном уровне. А как эти сообщения передаются по сети или не по сети? В видео упоминали транспорты.
Отличный вопрос. Да, транспорт - это именно то, как физически или логически передаются сообщения между клиентом и сервером. Выбор транспорта зависит от ситуации. В видео разбирали два основных сценария. Первый, когда всё происходит локально.
Локально, то есть и хост, и сервер на моём ноутбуке.
Именно. Локальный сервер (local server). Представьте, вы пишете код в VS Code (host), и у вас локально запущен MCP-сервер, который, например, умеет работать с вашими файлами на диске или с локальной базой данных. Зачем гонять трафик по сети?
Действительно, незачем. И как они общаются тогда?
Есть разные способы. Самый простой и распространённый для локальных хостов и серверов - через стандартные потоки ввода-вывода (stdin/stdout). Хост запускает процесс сервера и просто пишет запросы ему в stdin, а ответы читает из stdout. Это очень быстро и эффективно для локальных задач. Аналогией из видео была про готовку на одной кухне: можно просто передать записку или сказать словами.
Понятно. А если сервер не локально, что чаще всего и бывает, наверное, сервер где-то в облаке или на другом компьютере в сети.
Да, это второй и, вероятно, более частый сценарий - удалённый сервер. Здесь уже без сети не обойтись. И видео описывало два основных сетевых транспорта для MCP. Первый - HTTP + SSE (Server-Sent Events). Этот вариант использует стандартный HTTP-протокол, но с одним важным дополнением: SSE позволяет серверу самому отправлять данные клиенту в любой момент по уже установленному соединению. Это делает коммуникацию асинхронной и хорошо подходит для stateful (с сохранением состояния) взаимодействий.
Stateful - это что значит?
Это значит, что сервер помнит контекст взаимодействия с конкретным клиентом между запросами. Аналогия из видео: ресторан с официантом. Вы сели за столик, официант (сервер) принял ваш заказ. Он помнит, кто вы и что вы заказали. Если вы потом скажете: "Повторите напиток", он поймёт, какой именно, потому что он помнит состояние вашей сессии. SSE помогает поддерживать это долгоживущее соединение, по которому сервер может, например, присылать обновление статуса долгой операции.
Ага. А второй вариант какой был?
Streamable HTTP. Этот транспорт в видео позиционировали как более гибкий и предпочтительный во многих случаях. Почему? Потому что он может работать как в stateless (без сохранения состояния), так и в stateful режиме.
А stateless - это как?
Это противоположность stateful. Каждый запрос от клиента к серверу рассматривается как полностью независимый. Сервер не обязан помнить, что этот клиент делал 5 минут назад. Аналогия: фастфуд. Вы заказали бургер - одна транзакция. Потом решили взять картошку - новая независимая транзакция. Кассир (сервер) не связывает их вместе. Stateless-системы обычно проще масштабировать, потому что любой экземпляр сервера может обработать любой запрос.
Но вы сказали, streamable HTTP может быть и stateful.
Да, в этом его гибкость. Протокол позволяет при необходимости установить сессию и поддерживать состояние, как в варианте с SSE. Но если состояние не нужно, он может работать и в stateless-режиме. Это даёт разработчикам сервера и клиента больше выбора. Поэтому Streamable HTTP часто называют предпочтительным транспортом для удалённых MCP-серверов.
Понятно. Значит, есть локальный транспорт (stdin/stdout) и два основных сетевых: HTTP + SSE и Streamable HTTP, причём второй более универсальный. Выбор зависит от того, где сервер и нужен ли ему контекст сессии. Так, с теорией, кажется, разобрались. Архитектура HCS, начинка серверов TRP, жизненный цикл, транспорты. Вроде всё уложилось. Теперь самое вкусное - практика: как создавать эти MCP-серверы. В видео было два подхода: без кода и с кодом. Начнём с первого, с N8N.
Да, N8N (произносится как "эйтен"). Это популярная low-code/no-code платформа для автоматизации, что-то вроде Zapier или Make, но с открытым исходным кодом и возможностью хостить у себя. И вот, оказывается, в N8N встроили возможность визуально создавать HCS-сервера.
Визуально, то есть мышкой перетаскивать блоки.
Именно так. В демонстрации показали, как создать новый рабочий процесс в N8N, который будет работать как MCP-сервер. Туда добавили два узла, которые стали инструментами сервера.
Какие инструменты там сделали?
Очень простые для наглядности. Первый узел - калькулятор: просто принимает два числа и операцию, возвращает результат. Второй узел - Gmail, который позволял отправить email через подключённый аккаунт Google. Настроили эти узлы, соединили их со стартовым узлом MCP Server Trigger.
И всё, сервер готов.
Почти. Дальше нужно было нажать кнопку "Активировать", и N8N автоматически сгенерировал публичный URL-адрес для этого сервера. Этот URL и есть его адрес в мире MCP. Хорошо, сервер есть, а как его использовали?
А дальше сделали второй рабочий процесс в N8N, который выступил в роли хоста. То есть он имитировал AI-агента, которому нужно было использовать наш сервер. В этом хост-процессе добавили специальный узел MCP Client.
Ага, вот он, клиент из архитектуры HCS.
Да, в настройках этого узла MCP Client просто вставили URL нашего сервера, который получили на предыдущем шаге, и выбрали транспорт. Там был доступен HTTP Streamable, что логично для сервера, работающего в облаке N8N.
Настроили связь, а потом тестировали.
Конечно. Запустили хост-процесс и дали ему команду: "Сначала посчитай 11 x 99". Host через MCP Client отправил запрос на наш N8N-сервер. Сервер активировал узел-калькулятор, посчитал и вернул результат - 1089 - хосту. Всё, сработало.
А вторую команду про email?
Тоже проверили. Дали команду: "Отправь email на такой-то адрес с темой "Тест MCP" и текстом "Привет из N8N"". Хост снова обратился к серверу, но на этот раз сервер задействовал узел Gmail. Письмо ушло.
Звучит очень просто. Собрал сервер из кубиков, получил URL, подключил клиенту, и заработала. No-code в действии.
Да, для создания относительно простых серверов с инструментами это выглядит очень привлекательно. Но что ещё показали - это гибкость. Помнишь, мы говорили про переиспользуемость?
Да. Что один сервер можно использовать из разных хостов.
Вот они это и продемонстрировали. Взяли тот же самый N8N-сервер с калькулятором и Gmail и подключили его к совершенно другому хосту - Claude Desktop. Как?
Тоже через узел MCP Client. В Claude же нет N8N?
Нет, конечно. У Claude свой способ настройки MCP-серверов через конфигурационный файл. Туда просто добавили новую запись, указав URL нашего N8N-сервера. И что интересно, в этой конфигурации для Claude указали другой транспорт - SSE (Server-Sent Events).
А сервер N8N его поддержал?
Видимо, да. Или протокол достаточно гибкий, чтобы договориться. Это интересный момент, который показывает, что хост и сервер могут выбрать взаимоприеммый транспорт из поддерживаемых обоими. И после добавления в конфиг Claude смог точно так же использовать калькулятор и отправку почты с N8N-сервера, как и другой N8N-процесс.
Круто. Один сервер, два разных хоста, даже с разными транспортами. Но ты упомянул, что у low-code подхода в N8N были ограничения.
Да, и это важно понимать. На момент записи того видео N8N позволял создавать в MCP-серверах только инструменты (tools). Возможности добавить ресурсы (resources) или шаблоны промтов (prompt templates), то есть R и P из TRP, в интерфейсе N8N не было.
А, то есть всю мощь TRP через код пока не раскрыть.
Получается, что так, по крайней мере, в той реализации. Возможно, со временем добавят, но пока это ограничение, и оно логично подводит нас ко второму подходу.
К созданию серверов с помощью кода, где уже можно реализовать всё.
Именно. В видео была вторая демонстрация, где MCP-сервер писали уже кодом. Целью было сделать интеграцию с Google Workspace, конкретно с Google Sheets (таблицами) и Google Forms (формами). О, это уже более сложная задача, чем калькулятор.
Да, и здесь в роли хоста опять выступал Claude Desktop. А вот сервер был кастомный, написанный, судя по синтаксису декораторов, на Python с использованием какой-то MCP-библиотеки. И вот этот сервер уже реализовывал все три компонента TRP.
Так, что там было? Какие инструменты?
Инструменты были для работы с Google Sheets: List Spreadsheets (получить список таблиц, к которым есть доступ), Read Sheet (прочитать данные из листа), Write Sheet (записать данные). Возможно, были и для Forms, но акцент был на Sheets.
Понятно. А ресурсы?
В качестве ресурса сделали доступ к метаданным таблицы, например, к названиям колонок. То есть можно было быстро запросить: "Какие колонки в таблице X?" и получить только их список, не загружая все данные листа. Это как раз пример эффективного использования ресурса для чтения метаинформации.
Логично. А шаблоны промтов?
А вот шаблоны были для более интеллектуальных задач. Например, шаблон Analyze Sheet Data. Идея была в том, чтобы не просто прочитать данные (это мог сделать инструмент Read Sheet), а чтобы LLM-хост провёл глубокий анализ этих данных, следуя инструкциям из шаблона, и выдал результат в нужном формате. Ещё упоминался шаблон Create Report Template, видимо, для генерации какого-то стандартного отчёта по данным из таблицы. И как это работало на практике?
Показывали такую цепочку: Один. Пользователь просит Claude: "Найди мою таблицу с бюджетом". Два. Claude использует инструмент List Spreadsheets сервера, чтобы получить список таблиц. Находит нужную. Три. Пользователь: "Какие там колонки?" Четыре. Claude обращается к ресурсу сервера, чтобы получить имена колонок. Показывает их. Пять. Пользователь: "Проанализируй расходы за последний квартал и построй диаграмму." Шесть. И вот тут Claude использует шаблон промпта Analyze Sheet Data. Он передаёт данные из таблицы (возможно, предварительно прочитав их через инструмент Read Sheet или получив от сервера вместе с шаблоном) и сам шаблон на вход своей LLM. LLM, следуя инструкциям шаблона, проводит анализ, находит нужные данные, агрегирует их и генерирует не просто текст, а прямо в интерфейсе Claude строит диаграмму расходов.
Ничего себе. То есть шаблон промпта помог LLM не просто ответить на вопрос, а выполнить сложную задачу анализа и визуализации.
Именно. Он направил, как лучше использовать свои способности для решения этой конкретной задачи с этими конкретными данными. В этом и сила шаблонов промтов. Они позволяют упаковать сложную логику взаимодействия LLM с данными в переиспользуемый компонент сервера.
И в видео упоминали какие-то декораторы в коде, типа @MCPResource.
Да, мельком показали. Это типичный подход в Python-фреймворках. Разработчик просто пишет обычную функцию, например, `def get_sheet_data(sheet_name)`, и помечает её специальным декоратором `@MCPTool`, или пишет функцию для ресурса и ставит `@MCPResource`. Библиотека MCP сама разбирает эти декораторы и делает эти функции доступными через протокол MCP. То же самое, вероятно, и для шаблонов - какой-нибудь `@MCPPromptTemplate`. Это упрощает разработку серверов кодом.
Ясно. То есть кодовый подход, хоть и требует навыков программирования, даёт полную свободу реализовать всю мощь MCP: инструменты, ресурсы и шаблоны промтов, чего пока не хватает в low-code решениях вроде N8N.
Совершенно верно. Код даёт максимальную гибкость и контроль над тем, что и как предоставляет ваш MCP-сервер.
Ну что ж, мы прошли довольно долгий путь от базовой идеи MCP, как USB для AI, через архитектуру HCS и компоненты серверов до практических примеров создания этих серверов без кода и с кодом. Каков итог? Что мы имеем в сухом остатке?
А итог, на мой взгляд, очень многообещающий. MCP действительно выглядит как потенциально фундаментальный слой для всей экосистемы AI-приложений. Это попытка стандартизировать то, что до сих пор было хаосом взаимодействия LLM с внешним миром.
И эта стандартизация, как и в случае с USB, может привести к чему? К большему количеству инструментов, к более умным приложениям?
Потому что не нужно думать о сотне разных способов интеграции. Достаточно поддержать один стандарт MCP. Это может привести к появлению огромного разнообразия серверов для самых нишевых задач. 20.000 - это уже много, но может стать и 200.000.
А для приложений-хостов?
Для них это означает лёгкий доступ к этому огромному пулу возможностей. Представьте AI-агента, который может легко подключить сервер для бронирования билетов, сервер для прогноза погоды, сервер для управления умным домом, сервер для перевода текстов, сервер для доступа к научной базе данных - просто добавляя их манифесты в свою конфигурацию. Это позволяет создавать гораздо более мощных и универсальных AI-помощников.
И разделение на инструменты, ресурсы и шаблоны промтов (TRP) - это тоже важный элемент.
Безусловно, это показывает, что MCP - это не просто про вызов функций. Ресурсы дают эффективный доступ к данным, а шаблоны промтов - это способ инкапсулировать ноу-хау по взаимодействию с LLM для конкретной задачи, делая результаты более качественными и предсказуемыми. Это добавляет протоколу глубины.
Хорошо, картина складывается довольно оптимистичная, но вот в самом конце видео прозвучала мысль о возможной коммерциализации MCP-серверов, и это наводит на размышления.
Да, это интересный поворот. Если MCP станет стандартом де-факто, то логично предположить, что появятся компании, которые будут создавать и продавать доступ к своим MCP-серверам. То есть возникнет рынок MCP-серверов, как сейчас есть рынок SaaS-сервисов.
Вполне возможно. Представьте себе маркетплейс, где вы можете найти и подписаться на MCP-сервер для работы с Salesforce или для продвинутого анализа медицинских данных или для генерации юридических документов по шаблону. Разработчики приложений-хостов смогут не писать эти интеграции сами, а просто арендовать нужные возможности через MCP. Звучит удобно, но какие тут могут быть подводные камни?
Ну, во-первых, зависимость. Если ваше приложение построено на десятки платных сторонних MCP-серверов, вы становитесь зависимы от их стабильности, цен, политики обновлений. Что если ключевой сервер вдруг станет недоступен или резко подорожает?
Да, это риск. А ещё?
Вопросы безопасности и приватности данных. Как будет обеспечиваться безопасность передачи данных через цепочку хост, клиент, сервер, реальный сервис? Кто несёт ответственность в случае утечки? Как контролировать, какие именно данные уходят на сторонний MCP-сервер.
Стандартизация протокола здесь поможет.
Отчасти да. Протокол может включать механизмы безопасности, но реализация этих механизмов в конкретных серверах и клиентах, а также общее архитектура безопасности решения - это всё равно останется зоной ответственности разработчиков.
И ещё, наверное, вопрос качества и доверия. Если серверов будут тысячи, как понять, какой из них надёжный, безопасный и действительно делает то, что заявлено? Понадобятся какие-то системы репутации и сертификации?
Скорее всего, да. Как и в любом зрелом рынке API или SaaS, возникнут вопросы доверия, верификации, SLA (Service Level Agreement). Экосистема должна будет выработать механизмы для этого.
То есть MCP открывает огромные возможности, но и ставит новые вопросы - экономические, технические, организационные. Это не просто технический стандарт, это потенциально новая модель построения и монетизации AI-приложений.
Совершенно верно. И будет очень интересно наблюдать, как эта экосистема будет развиваться. Станет ли MCP действительно универсальным стандартом? Какие появятся маркетплейсы? Как будут решаться вопросы безопасности и доверия? Это вопросы на ближайшие годы.
Что ж, на этой ноте, полной и возможностей, и вопросов, мы, пожалуй, и завершим наш сегодняшний детальный разбор Model Context Protocol. Надеюсь, нам удалось погрузиться достаточно глубоко и дать пищу для размышлений.
Да, тема оказалась действительно многогранной. Спасибо за интересную беседу.
И спасибо всем, кто был с нами. До новых встреч.