Команды MCP сервера (MCP prompts) — Transcript

Видео объясняет структуру и работу MCP-сервера, особенности промтов и их отличие от скилов на примерах и практиках.

Key Takeaways

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

Summary

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

Chapters

Full Transcript — Download SRT & Markdown

Speaker A

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

Speaker A

условно статичное и всё в таком духе. Второе - это тулы. Ну, тулы, они в Африке тулы какой-то скрипт, который выполняет мутации, который что-то там меняет внешнем мире, либо возвращает данные, но на основе других, как-то их модифицируя, как условные селект

Speaker A

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

Speaker A

же будет в описании к видео. Сходите, посмотрите. Ти можно лайкнуть, подписаться, оставить комментарий, а может даже поддержать меня на sponsor.ru. Так вот, в целом, что такое скилы и что такое MCP с вот этим набором инструментов? Скилы - это что-то

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

пользователей к вашему скрипту, который вы распространяете отдельно от AP. Ну а в случае, если вы предоставляете какое-то IP самостоятельно, допустим, вы atласин и у вас есть джира, то вам логичнее создать свой MCP-сервер, который будет входить в ваше IP, будет

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

Пользователь, скорее всего, даже не узнает о том, что вы произвели какое-то обновление в вашем сервере, если он об этом не задумывался и вы его отдельно не оповестили. Ну, может быть, максимум заметит, что у вас появилась новая команда, потому что если приглядеться,

Speaker A

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

Speaker A

можем передавать какие-то параметры с автокомплитом, кстати, они работают. Также мы можем промты возвращать не только в виде текста, как здесь в примере, с уже подстановленным каким-то параметром, но и самое интересное, что мы можем в целом возвращать целый кусок

Speaker A

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

Speaker A

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

Speaker A

работаем в рамках спецификации связанных инструментов. И таким образом модель ваша сразу понимает, что то, что вы ей вернули - это не какие-то рандомные данные, это ресурс. И в случае, если она в своих размышлениях приходит к тому, что этот ресурс надо прочитать, она

Speaker A

видит, что вы его уже подложили, и, соответственно, можно его не читать. Ничего нового она не получит. И всё это возвращается модельке в виде пачки ответов. Если посмотреть SDK питона, здесь очень хороший пример в Гитхабе.

Speaker A

Да, ссылочки на все странички, которые вы видите на экране, будут в описании к видео. Как обычно, посмотрите это там.

Speaker A

Мы можем заметить, что у нас здесь имеется целый блок сообщений, которые мы возвращаем из промта. Что это и зачем?

Speaker A

Вы можете с помощью своего CP-сервера в разделе промптов возвращать вашей модельке не просто какой-то промпт, а вы можете формировать какую-то историю чата. Таким образом, вы даёте модели контекст, как будто бы уже произошла какая-то беседа, допустим, между ассистентом и пользователем, как в

Speaker A

примере здесь. Оно вроде бы как бы и не всегда нужно в каких-то редких случаях, но иногда это позволяет вам обогатить контекст в таком виде, чтобы системе было проще воспринимать информацию.

Speaker A

Именно это мы и будем делать в процессе реализации нового промта. Мы будем возвращать resource вместе с пользовательским запросом. И давайте перейдём к процессу. Первым делом нам, конечно же, нужно запустить наш MCP-сервер в HTTP стриминге, запустить клода, чтобы подготовить промт для

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

MCP-сервер. Всё корректно, значит, промт отрабатывает. Видим обзор постов, которые были у меня недавно на канале.

Speaker A

Значит, промт нас полностью устраивает. Выходим из системы, сохранив предварительно промт у себя в настройках, и останавливаем MCP. Далее открываем наш любимый OpenCД, потому что не одним клодом мы живы. И в отличие от клод-кода, Openкодом можно пользоваться с неплохой моделькой, с бесплатным

Speaker A

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

Speaker A

пользователь не указал канал, то предварительно подгрузи ресурс, который возвращает список каналов. Проверь спецификацию, чтобы использовать соответствующий объект resource.

Speaker A

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

Speaker A

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

Speaker A

Отправляю в систему работать и иду наливать кофе, пока она справится с задачей. Итак, Open CД закончил.

Speaker A

Смотрим. Без каналов возвращает им этот ресурс URI и текстовую инструкцию. С каналами возвращает текст с указанными каналами инструкции. Метаданные промпта с дефолтом. Отлично. Автокомплит тоже починил. Тудушки свои все отметил.

Speaker A

Готово. Идём ревью, что получилось. И смотрим по порядку. Первое. Промт. У нас есть инструкция переменные количество дней. В остальном всё то же самое. Далее видим, что система продолбалась.

Speaker A

Возвращает джейсонку, а не объекты. И это придётся править ручками. Возвращая джейсоны, а не объекты. Можно попробовать её заставить сделать нормально. Копируем пару ссылок, вставим ей и скажем: "Ты возвращаешь JON, а не объекты исправь по примерам". И далее скидываю ей ссылки на GitHub, где

Speaker A

приведены примеры, как возвращать список объектов и как возвращать ресурс. Вправляем модель работать. А это, кстати говоря, наглядный пример, почему нужно уметь программировать, почему нужно знать те фреймворки, которые вы используете. Даже умные модели способны так продолбаться и срезать углы.

Speaker A

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

Speaker A

Выбирайте сами, какую роль вы будете выполнять в этом тандеме. Я выбираю вторую. Теперь всё правильно.

Speaker A

Возвращается объекты. Это я за тобой сейчас всё проверю, правильно ли ты всё это сделал. Смотрим, что у нас получилось. Так, видим, что у нас есть user message, emp resource и пользовательское сообщение, инструкция.

Speaker A

Отлично. Во втором случае, если мы указали каналы, то мы их просто перечисляем здесь и дальше добавляем инструкции. Всё хорошо, всё красиво.

Speaker A

Смотрим на автокомплитe. Моделька [фыркает] тут, конечно, немножечко замудрила. Я немножечко подформатирую код, чтобы его было легче читать. Так, у нас добавилось новое условие. Первое условие у нас для ресурсов. Второе условие у нас для промтов. И если аргумент каналы. Точно так же фильтруем

Speaker A

каналы и возвращаем название. В принципе, можно было, наверное, ставить и предыдущий автокомплит, но с более лёгким условием. Супер. Давайте проверим, что всё это работает.

Speaker A

Запускаем MCP инспектор def main Pie. Инспектор запустился. Коннектимся. Всё законнектилось. Открываем промты и видим, что у нас есть здесь промт, в котором мы можем указать количество дней, за которые мы хотим собрать digest. Проверим, что автокомплит работает. Да, let's здесь появляется. И

Speaker A

получаем промт. Смотрим в составе digest постов. Смотрим, что он сформировал. канала Let's Go Dre, посмотри в методе Qu. То есть, в принципе, здесь всё корректно. А если мы уберём название канала, мы должны увидеть, что здесь ещё появится ресурс. Да, видим, вот он,

Speaker A

ресурс подгрузился, и в нём тот же самый Let's go Drew. Ну, потому что у меня сейчас сохранён только один канал и тот же самый МпTт, но здесь уже нет списка каналов в начале. Отлично, это всё работает. Теперь можно проверять это всё

Speaker A

в клоде. Опять запускаем сервер, выходим из Open кода и запускаем Club. Проверяем, что MCP загружен. Да, connected. Всё отлично, значит, можно действовать. Вводим Backс и видим, что уже наш digжест в автокомплите появился.

Speaker A

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

Speaker A

самое, но указать название канала Let's Code Drew. К сожалению, здесь почему-то не работает Автокоe. И тут он срезал, посмотрел, что в истории я это уже упоминал. В принципе, всё отработало.

Speaker A

Думаю, для примера этого достаточно. Код вы найдёте на гитхабе. Как обычно, ссылочка под видео. Если вам понравилось видео, вы можете подписаться на мой спонсор и поддержать меня. Это очень помогает делать новые видео. Можно также поставить лайк, подписаться на канал,

Speaker A

оставить комментарий. Спасибо, что посмотрели это видео. Всем спасибо. Всем пока.

Topics:MCP серверпромтыскилыресурсытулыавтокомплитOpenCDHTTP стримингинтеграциятестирование промтов

Frequently Asked Questions

Что такое промты в контексте MCP сервера?

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

В чем преимущество MCP сервера перед скилами?

MCP сервер централизованно управляет обновлениями и ресурсами, что упрощает поддержку и интеграцию, в отличие от скилов, которые могут быть разрозненными и сложными в обновлении.

Как промты обогащают контекст взаимодействия с моделью?

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

Get More with the Söz AI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries, speaker detection, and unlimited transcriptions.

App Store Google Play

Or transcribe another YouTube video here →

Free tools: TXT to SRT · SRT Validator · Merge SRT · Subtitle to Text · All tools