Speaker A
Продолжаем разбирать MCP, и у нас на очереди ресурсы. Самая странная, наверное, и самая неочевидная штука.
Видео разбирает ресурсы MCP сервера, объясняет их структуру, отличия от темплейтов и демонстрирует практическую реализацию с примерами.
Ask about this video. Answers come from its transcript only — with the timestamp, so you can check them.
Generated from the transcript and can be wrong — check the timestamp.
Key Takeaways
- Ресурсы MCP — это статичные данные для чтения, а темплейты содержат переменные для динамического контента.
- Подписки и отслеживание изменений ресурсов требуют сложной реализации и не всегда нужны.
- Правильное использование URI схем критично для совместимости с клиентами MCP.
- Openкод и модели ИИ помогают быстро создавать и тестировать MCP ресурсы и темплейты.
- Автодополнение в MCP улучшает взаимодействие с ресурсами и является частью протокола.
What the video covers
- Обзор концепции ресурсов в MCP сервере — это данные только для чтения, доступные клиенту.
- Ресурсы имеют статичный URL и могут быть представлены файлами, веб-страницами или базами данных.
- Темплейты — это ресурсы с переменными в пути, позволяющие динамически подставлять параметры.
- Подписки на ресурсы и отслеживание изменений не рассматриваются в видео из-за сложности и специфики.
- Обсуждение стандартов URI схем и предупреждение об ошибках при неправильном использовании протоколов https, file, git.
- Практическая часть — написание кода с помощью Openкода и модели Deeps V4 Flashфри для создания ресурсов и темплейтов.
- Демонстрация запуска MCP сервера на Python и взаимодействия с ресурсами через браузерный инспектор.
- Пояснение механизма автодополнения (completion) в протоколе MCP и его важности для удобства работы с ресурсами.
- Тестирование MCP с клиентом Clode и показ корректного чтения данных из ресурсов.
- Видео сопровождается ссылками на репозиторий и документацию, а также призывом к подписке и поддержке автора.
Chapters
- 00:00Введение в ресурсы MCP сервера
- 00:44Подписки на ресурсы и их сложность
- 01:33Отличия ресурсов и темплейтов
- 02:27Аннотации и дата модификации ресурсов
- 03:16URI схемы и стандарты MCP
- 03:59Призыв к подписке и ссылки на ресурсы
- 04:52Практическое создание ресурсов с Openкодом
- 05:40Различия ресурсов и темплейтов на примере
- 06:23Запуск MCP сервера и инспектор
- 07:20Работа с темплейтами и автодополнением
Full Transcript — Download SRT & Markdown
Speaker A
Особенно это хорошо заметно странность и неочевидность на фоне того, что здесь есть ещё такая часть, которая называется темплейты. Первый раз, когда я её увидел, я вообще подумал, что типа ух, ни хрена, шаблоны можно что ли хранить, но оказалось всё гораздо прозаичнее.
Speaker A
Идём по порядку. Ресурсы на самом деле — это что-то доступное только на чтение для вашего клиента, кто будет подключаться к вашему MCP. И по факту это переносится на какие-нибудь сущности, например, файлы на жёстком диске, странички в интернете, таблица в базе данных. Сами можете определить свои доменно области, чем это может быть.
Speaker A
Одна из прелестей ресурсов заключается в том, что у нас на них можно подписаться и отслеживать, когда они были изменены.
Speaker A
Я в этом видосе делать не буду. Вам, если понадобится, вы и будете это делать. У меня просто это сервер в зависимости от третьих данных. И это будет какой-то слишком сложный код, который я не хотел бы в этом видео сейчас разбирать.
Speaker A
Тем более в любом случае это будет высасывание из пальца, потому что свой MCP я собираюсь подключать только какому-то клиенту, вроде, и ассистента. А подписки — это всё-таки для какого-то более живого агента, который работает постоянно и может получить запрос откуда-то снаружи, как-то среагировать.
Speaker A
Ну, в общем, явно не про ассистента. Первое, что мы можем делать в рамках протокола — это посмотреть, какие у нас ресурсы вообще доступны. У нас это будет доступно практически из коробки. Делать ничего для этого не придётся. Мы просто опишем, какие у нас есть ресурсы.
Speaker A
Чтение ресурса — основная часть логики, которую мы будем реализовывать, те самые загадочные темплейты. По факту это те же самые ресурсы, но в пути к которым мы будем вставлять какие-то переменные. То есть, по большому счёту, это параметр из веба, хорошо нам знакомый.
Speaker A
Каких-то радикальных отличий от обычного ресурса нет. В терминах MCP ресурс — это что-то со статичным URL, который не меняется, который мы не резолвим на клиенте, а отображаем как есть. В нашем случае это будет просто список всех ресурсов внутри одной категории.
Speaker A
А темплейтом будет информация о канале, когда мы на него, допустим, подписались, либо если мы на него не подписаны, то информация о том, что не подписаны мы на него, и список всех постов с канала. Так как подписки мы не будем рассматривать, мы скипаем этот раздел.
Speaker A
Можно почитать вам самостоятельно, если очень интересно, если очень нужно. Описание реализации протокола в виде типов. Нам это не очень интересно. Здесь самая интересная часть — это аннотации. Но так как мы клиента не будем реализовывать, она тоже как бы не очень релевантна.
Speaker A
Я рассматриваю только подключение к обычному клиенту, а эта информация помогает разделить, например, ресурсы, доступные только пользователю либо ассистенту по умолчанию, доступны им обоим, какие-то приоритеты и дата последней модификации.
Speaker A
Но так как мы только собираем ресурсы и транслируем их далее в ассистента, нам это тоже не очень имеет смысл какой-то реализовывать L modified дату.
Speaker A
И самая интересная часть — доступ ко всем ресурсам осуществляется в виде URI.
Speaker A
Итак, QI схема у нас уже, в принципе, понятная, давно существующая, все мы с ней знакомы, поэтому решили ещё и залочить пару-тройку протоколов уже существующих. Это https. Если сервер поддерживает доступ к вебу, то вы сами реализуете, как он должен это реализовывать.
Speaker A
Если не реализуете, то занимать данный протокол нельзя. То же самое касается протоколов Файл и Git.
Speaker A
Просто обратил ваше внимание, чтобы, не дай бог, вы случайно не задействовали эти схемы каким-нибудь неправильным способом, потому что с большой долей вероятности какой-нибудь клиент вроде клода или кодекса или опенкода может обидеться на вас и начать выдавать какую-нибудь ахинею, которой вы не ожидали.
Speaker A
Ну и в целом спецификация подразумевает, что мы будем строго следовать стандарту при создании своих кастомных URI схем.
Speaker A
Последующий раздел нас вообще не интересует — Handling Security Consideration, но нам, конечно же, уже хочется скорее начать писать код.
Speaker A
Продолжаем мы всё в том же репозитории, который я показывал в прошлом видео. Ссылочка на него будет в описании к видео. Также как и ссылочка на документацию, которую вы только что смотрели, кстати говоря.
Speaker A
Там ставим лайк, подписываемся, пишем комментарии.
Speaker A
Это очень поддерживает канал. Ну а тем, кто подпишется на sponsor.ru, я вообще буду признателен практически вечно.
Speaker A
Навсегда останетесь в моём сердечке. Итак, начинаем писать код. Конечно же, писать мы его тоже будем не руками, а с помощью Openкода.
Speaker A
И ставшей уже привычной модели Deeps V4 Flashфри на состоянии на начало июня двадцать шестого года. Моделька всё ещё бесплатно доступна, что не может не радовать.
Speaker A
Задачу ставим самым простым и максимально естественным способом. Мы что-то обходим всё-таки с вами. Какие тулы у нас уже сейчас можно переделать на ресурсы и вообще, надо ли нам это совершать?
Speaker A
Да хватит копировать в буфер и какие ресурсы стоило бы добавить, опираясь на то, что у нас есть. Отправляем железку работать.
Speaker A
Моделька закончила. Самое главное, что она здесь очень хорошо отметила — это отличие в корне. Ресурсы они всегда должны быть только ридли, если вы хотите получить какие-то данные и дальше с ними работать.
Speaker A
Если у вас есть хоть какие-то мутации на стороне сервера, то, по-хорошему, это не подойдёт, и вам надо делать ту. Текущее разделение, которое моделька здесь обозначила, оно действительно очень на тоненького проходит под эти требования.
Speaker A
Давайте здесь не согласимся, чтобы она добавила один ресурс и один темплейт. Это вот как раз разница наглядно по поводу того, чем отличаются ресурсы и темплейты. Ресурс — это статичная строка, а темплейт — это у нас наличие в этой строке какого-то переменного кусочка, того самого puff variable.
Speaker A
Отправляем модель работать. Давай, делай. Она предложила одно, а по факту сделает ровно то, чего я от неё ожидал. Разделила задачу на три разных ресурса. То есть один ресурс, два темплейта, просто список каналов, информация по каналу, подписаны, не подписаны и посты из кэша данного канала.
Speaker A
По мне, идеальный сценарий для того, чтобы показать разницу между всеми этими сущностями. Моделька закончила.
Speaker A
Моделька сделала всё, что обещала. Три новые сущности с новым URI TG, что в нашем случае означает Telegram. Давайте попробуем теперь это всё запустить.
Speaker A
Напоминаю, если вы так же, как и я, работаете в инфраструктуре питона, здесь мы просто запускаем MCP def main pi и идём в браузер ждать, пока откроется инспектор. Вот инспектор открылся.
Speaker A
Делаем коннект. Смотрим список ресурса, смотрим список темплейтов. Если сверимся тем, что я говорил раньше, то мы видим, да, действительно, один ресурс и два темплейта. Ровно они здесь и появились.
Speaker A
Запускаем первого и видим, что у нас очень некрасиво и неудобно отображается код, на который мы подписались в прошлой серии. Переходим на resource channels resource. И здесь нужно ввести имя.
Speaker A
Давайте введём Let's и проверим, подписаны мы на него или нет. Добавлены, да? И дата, когда я добавил этот ресурс.
Speaker A
Смотрим второй темплейт. И опять здесь нужно указать имя LEDs code. Drew. Вводим, читаем ресурс и видим список последних постов, которые у нас тут сохранены в базе данных.
Speaker A
И который мы можем прочитать. Крайне, конечно, неудобно это всё читать на таком маленьком экранчике, но самые внимательные, конечно, заметили, что когда я здесь открываю, здесь появляется поле ввода с поиском, но никакого поиска не происходит.
Speaker A
Что это за поле и нахрена оно здесь нужно? Это поле — это одна из фишек протокола MCP. Как вы помните, если в каком-нибудь агенте начать вводить имя файла, допустим, вот в опенкоде я добавляю собачку и начинаю писать, допустим, Redmi.
Speaker A
И мы видим, что автодополнение появляется здесь и показывает, какие филды есть. Это тоже часть протокола, и поэтому нужно это реализовывать отдельно.
Speaker A
И это расширение называется неожиданно comptition, наш любимый compition. И он входит в протокол, и он чётко описан, как его настраивать, как ег
Speaker A
Собираем список постов, компонуем всё это в одну большую строчечку и возвращаем. В принципе, всё терпимо. И вот он completion- это отдельный декоратор, который определяет хендлер для комплишена. То есть, по большому счёту, это тот же самый endpint, как если бы мы делали это на нашем сайте на
Speaker A
каком-нибудь. Первым делом принимает реф ими ресурса, с которым мы работаем, для которого нам нужен автокомплитe.
Speaker A
Аргумент - это тот аргумент, который мы обрабатываем. В данном случае это у нас name. И ещё здесь может быть третий параметр, который содержит ссылки на контекст для других аргументов. Если ваш темплейт содержит несколько паф варийблов и вам нужно их как-то между
Speaker A
собой состыковывать, допустим, компания и подразделение компании или, допустим, страна, город, ну, в общем, в таком духе, когда у вас есть связь между этими самыми параметрами. Completition у нас один на весь MCP-сервер, и, соответственно, он может принимать рефы совершенно разные. То есть здесь у нас
Speaker A
только один протокол ТГ, но протоколов может быть несколько и, соответственно, путей внутри и по фриблу должны быть разные. Поэтому здесь, по-хорошему, если мы начинаем что-то модифицировать, разные пафойблы, разные протоколы, то здесь нужно добавлять какой-то роутер, который будет перекидывать в зависимости
Speaker A
от исполнения на хендлеры, которые будут, собственно, всё это обрабатывать в подходящем виде. Так как у нас ничего здесь сложного нету, мы получаем здесь список каналов, а дальше просто фильтруем весь список, отбирая те, которые начинаются с тех же букв,
Speaker A
которые мы передаём на вход. Здесь, по-хорошему, конечно, можно добавить перевод к нижнему регистру. И здесь, кстати, тоже неплохо было бы привести к нижнему регистру. После того, как мы провалидировали, что у нас код тут работает, после того, как мы код
Speaker A
провалидировали, нам остаётся только перезапустить наш MCP. Хотя, наверное, хватило бы и просто переконнектиться, но я уже это сделал. Делаем конект, убираем всё лишнее, чтобы оно нам не мешало, и смотрим темплейты. Начинаем вводить имя LEDS и получаем ошибочку. А, ну вот то,
Speaker A
что я и говорил, принимает два позиционных параметра, но на вход прилетело три. Нероночка совершенно забыла про третий аргумент. Нтекст.
Speaker A
Блин, я тип не помню, но давайте, кстати, сейчас сразу и проверим, будет ли restart работать или нет. Let's. И опять ошибочка. Completion object can be inwaited. Ну вот сам говорил, что нужно отслеживать все ошибки, но нихера сам не
Speaker A
отслеживаю. Данная функция должна быть асинхронной. Забавно, что остальные не асинхронные, это должно быть асинхронное. Ну что ж, здесь, видимо, так принято. Вновь проверяем, что у нас работает. Completition и видим, да, вот он работает. Let's do добавляется.
Speaker A
читаем и получаем ответ. Таким образом, вы можете добавлять неограниченное количество аргументов и использовать для них autпт. Но, повторюсь, работает это далеко не для всех клиентов. Давайте попробуем заиспользовать этот MCP в клоде. Тормозим его здесь. И просто, насколько я помню, у нас здесь же просто
Speaker A
веб-сервер, да? Запускаем Python main P. Видим, что он у нас стартанул. Входим из Open кода, запускаем clad и проверяем, что ресурсы у нас доступны. ТГ. И вот видим, все наши ресурсы здесь присутствуют. Давайте посмотрим. Клод ни хрена не понимает, что я от него хочу.
Speaker A
Ну, это нормально, он и не должен. Давайте посмотрим. Последние посты из канала. Let's code. Нажимаю Tab.
Speaker A
Автоматический. Автопete сработал. То есть оно всё-таки есть, да? Вот processing request. Complete request. Он почему-то просто не показывает выпадающий список, либо я его просто не заметил. Ну-ка LED. А, топ. Серьёзно? То есть автокомплит есть. Просто он Ну это
Speaker A
я, я могу, я умею. Так, запускаем. Смотрим. Я вижу каналдрю. Нужно уточнить, что вы хотите сделать.
Speaker A
Добавить канал, изучить посты. Давайте попробуем эту же команду пост. Что там было последнюю неделю? Проверим. Так, я по ходу дела использовал ресурс, которого не определил. Да, nameйм, да?
Speaker A
Нет, посты. Channel name пост. Ну, что-то он, короче, читать не хочет. Надо разбираться. Итак, я не знаю, что произошло после того, как я всё закоммитил, запушил, ничего не менял.
Speaker A
Просто решил разобраться с тем, какие тут могут быть проблемы. Перезапустил сервер. Вот он у меня работает. Во всё.
Speaker A
Запускаю клод. Тот же самый MCP connected. Те же самые тулы, те же самые ресурсы. Ничего не изменилось. Но при этом, если я добавляю ТГ channels, let's go, делаю посты, что свежего было, клод почему-то раздуплился и начал нормально читать данные из ресурсов. И вот он
Speaker A
распарсил все посты, которые прилетели. Соответственно, автокомплет работает, ресурсы читаются, и наш MCP-сервер может шарить контекст, точно так же, как это происходит с внутреними MCP, которые зашиты в клодко-коде каких-либо отличий.
Speaker A
Спасибо, что посмотрели это видео. Всем спасибо. Всем пока.
Topics:MCP серверресурсы MCPтемплейтыOpenкодDeeps V4 FlashфриURI схемыавтодополнениепротокол MCPClode клиентPython MCP
![🔪🔥Песня “Злодей” [DUSTTALE]🚬 — Transcript](https://i.ytimg.com/vi/NQxQkKuwSjY/maxresdefault.jpg)
