Comments 20
Отличный разбор! Как разработчик, работающий с агентными системами, добавлю важный нюанс: ключевое различие между Tools и Skills часто лежит в уровне абстракции. Tools — это атомарные действия (вызов API, чтение файла), а Skills — скомпонованные сценарии, которые могут комбинировать несколько Tools + промпт-инструкции. На практике мы пришли к тому, что Agent Loop должен быть максимально тонким — роутинг, вызов инструментов, проверка стоп-условий. Вся «логика» уходит в Skills и системный промпт. Это сильно упрощает отладку.
Спасибо за отзыв!
Tools и Skills действительно можно определить, как "атомарные действия" и "сценарии", и один из заключительных тейков статьи состоит в том, что если вы можете сделать "атомарным действием" сразу весь "сценарий", то так и следует поступить. Это и разгрузит контекстное окно, и повысит точность.
Плюсующим рекомендую пролистать другие комментарии комментатора ^_^
Неожиданно практически ничего нет по MCP.
Когда спросил по этой теме саму LLM, она выдала мало похожего на то, что в этой статье.
Вроде "MCP - набор конкретных знаний. Можно просто скормить LLM файл с документацией, можно сделать базу данных, в которой по запросу термина будет выдаваться ответ именно по нему". Глобальная цель - дать информацию, которую LLM сама врядли найдет, таким способом, чтобы сэкономить максимум токенов.
Я раскрыл термин MCP с пользовательской точки зрения, а не с технической. Фраза "подключить mcp сервер к агенту" буквально значит "дать агенту пачку тулов, чтобы он мог что-то делать" (например создавать те же события в календаре).
То, что вы привели как определение MCP на мой взгляд скорее является определением для RAG базы знаний. Нарезали данные на кусочки (чанки), каждому дали свой вектор, сложили все в векторную БД и теперь по вводу слова "Doсker" быстро находим кусочки, которые близки по смыслу, обогащаем ими пользовательский промпт и модель генерит ответ чуть лучше.
Глобальная цель MCP - создать в индустрии некий стандарт (P это протокол)
1) разработчик MCP сервера дает некоторый инструментарий (набор тулов) пользователю и точно знает, что пользователь сможет им воспользоваться (потому что это стандарт индустрии)
2) пользователь MCP сервера абстрагируется от всего и просто получает готовый набор инструментов (тулов) для того, чтобы дальше строить свои более сложные сценарии (скиллы)
upd. Добавил пару предложений про MCP в качестве примеров
вот этот текст целиком нисколько не приблизил к пониманию термина MCP. Читаю - "mcp - создать стандарт" - ни о чем вообще. "разработчик mcp передает некий инструментарий, набор тулов" - было бы понятно, если бы не прочитал другое определение -
MCP сервер - это сервис, который предоставляет определённые услуги (например, поиск по локальной файловой системе, в БД или работа по API с GitHub). LLM может использовать эти сервисы для решения поставленной задачи.
гораздо понятнее и ближе к тому, что выдала по этому же запросу llm. Серверу MCP необязательно возвращать tool. Это может быть и текст и промпт.
Так как-то понятнее, если вообще ничего по теме не знаешь
Пожалуй да, написал недостаточно понятно
Цель Model Context Protocol - создать стандарт, благодаря которому разработчик будет знать как дать пользователю набор инструментов, чтобы он вообще мог им пользоваться.
Цель Model Context Protocol сервера - дать пользователю (или его агенту) этот набор инструментов.
По поводу "mcp не обязательно возвращать тул - это может быть и текст и промпт" не вполне согласен. Согласно спецификации MCP (modelcontextprotocol.io) - есть три основные вещи, которые может возвращать MCP сервер: resources, tools and prompts.
Ресурсы это "существительные" - например профиль пользователя или пост в ленте. Они недоступны LLM - спецификация определяет их как "Resources in MCP are designed to be application driven"
Prompts это собственно промпты, но только они отдаются не LLMке, а пользователю. Цитата из спеки - "Prompts are designed to be user controlled"
Tools это "глаголы" - например "создать пост". Вот именно они к LLM в контекст и попадают - "Tools in MCP are designed to be model-controlled"
Возвращаясь к тезису - LLMке из MCP сервера может отдаваться только список tools, а остальные концепции я решил не раскрывать в этой статье.
Я понял. Мы говорим о том же самом. Только вы используете термины, которые я бы никогда не понял, если бы буквально накануне не пытался бы разобраться в теме.
Например:
Ресурсы это "существительные" - например профиль пользователя или пост в ленте. Они недоступны LLM - спецификация определяет их как "Resources in MCP are designed to be application driven"
Ресурсы (Resources)
База знаний: Сервер предоставляет доступ к базе данных FAQ, технической документации или справочным материалам, что позволяет LLM обрабатывать вопросы с более глубоким контекстом.
[вырезано...]
П1 мне ничего не говорит. П2 позволил мне сразу набросать простенький MCP (дока по локальному api, я увидел, как я могу применить это у себя).
П2 это из https://habr.com/ru/articles/879970/
Мне, честно говоря, кажется, что в этой статье автор плохо раскрыл тему.
Среди примеров для tools от приводит GitHub Server
GitHub Server: Сервер для управления репозиториями, работы с GitHub API и получения данных о проектах. Он позволяет интегрировать функциональность GitHub в приложения с использованием MCP.
А среди примеров для resources File System Server
File System Server: Обеспечивает безопасный доступ к локальной файловой системе, позволяя выполнять операции чтения, поиска и управления файлами.
На мой взгляд, тот факт, что автор приводит эти примеры говорит о его низком уровне понимания освещаемой темы. Из приведенных фрагментов (да и из статьи в целом) совершенно не понятно, например, чем отличаются tools от resources. Автор не упомянул ключевое отличие - что tools преднозначены для LLM, а resources для приложения (через которое пользователь взаимодействует с LLM).
Вынужден также признать, что когда я написал "ресурсы это существительные" я был неправ. Сам в этой части тоже пока разбираюсь (и потому решил в статье упомянуть эти концепции лишь вскользь). Понимание к которому я пришел в настоящий момент: ресурсом может быть и действие - например "сконвертировать валюту". Разница в том, что если пользователь нажимает на кнопку в приложении и приложение отправляет запрос на сервер, то это значит, что разработчик приложения использовалresource(например - обычный REST запрос) при создании и теперь кнопка работает. А если это LLM пишет convert(...) , то же самое приложение это ловит и по ранее полученному описанию тула от сервера обращается на тот же сервер с тем же действием - это уже тул (связка "правильная инструкция для модели" + "правильно описание для приложения как запускать тул").
А в качестве примера промтпа приведено следующее
Сценарий выбора инструмента: «Если пользователь запрашивает конвертацию валют, вызови инструмент конвертера и верни результат в виде 'x [исходная валюта] = y [целевая валюта]'.»
И это еще нагляднее показывает, что автор на самом деле ничего не понял(
Я снова сошлюсь на спецификацию и приведу цитату - "Prompts are designed to be user-controlled <...> For example, as slash commands" (и ниже картинка из документации - что имеется ввиду).
Спецификация явно указывает, что промпты используются пользователем, а не моделью. А в примере из статьи говорится "Если пользователь запрашивает конвертацию валют", что явно указывает на то, что автор думает, что промпт от mcp сервера работает как skill (и буквально описывает тригер для этого скилла).
Ближайшей аналогией в данном случае являются commands доступные в Claude Code. Это тоже предподготовленные промпты, но живущие не на сервере, а на клиенте и также доступные пользователю для "вызова".
Иначе говоря - я считаю что приведение примеров в таком виде, как приводит их автор статьи - дает либо неполное, либо ложное понимание.
Но допускаю, что мои примеры в действительности не дают вообще никакого, сколь бы наглядными они мне не казались.
совершенно не понятно, например, чем отличаются tools от resources.
Вообще, это как раз в вашей непонятно. Вы сводите одни термины к другим терминам, затем к ненужным уточнениям типа "цель - стандарт". Вот на кой мне знать, что цель - стандарт? Или что в данном контексте "Resources in MCP are designed to be application driven"?
А по его выходит, что если просто подсунуть LLM текстовый файл, это уже MCP сервер. Окей, я по-быстрому собираю mcp, который будет скармливать локальную документацию llm. Что я получил на выходе? Правильно, tool. Но это теперь я знаю, что это tool. Хотя, в определении было " Сервер предоставляет доступ к базе данных FAQ, технической документации или справочным материалам". И оно дало мне понять, что я как-то могу это использовать.
В итоге есть ваше определение, которое мне вообще ни о чем не говорит, и "неправильное" определение, которое дало мне понятие о том, что я могу как-то это использовать (и я использовал).
Что из этого правильнее даже обсуждать не буду, еще условно вчера я даже терминов этих не знал.
Вот только если подсунуть LLM текстовый файл это не будет mcp сервер... Это будет просто текстовый файл подсунутый в LLM.
Что такое MCP определено предельно четко. К MCP серверу есть зафиксированные в тексте требования.
Если ваше понимание MCP привело вас к действиям, которые помогли вам решить задачу - это отлично, но это не всегда значит, что вы сделали именно MCP.
Отмечу также, что текстовый файл скормленный в LLM также не будет являться тулом. Он может помочь вам ту же задачу, что и тул, но тулом (в его обычном определении) не станет.
Все таки у терминов есть свои определения и нередко подробное описание "как они устроены внутри" - когда мы говорим "это MCP сервер, а это не MCP сервер" следует описаться именно на них.
ок. по кругу идти не будем уже. Повторюсь, это буквально второй случай, когда я столкнулся с понятием mcp. Наверняка мне еще много разбираться.
Может код ниже это и не mcp сервер, а чтение локального файла в нем это вовсе не tool, но выглядит похоже.
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("LocalFileServer")
@mcp.tool()
def read_local_notes() -> str:
и тд
Да, это mcp сервер, но от вас скрыта вся реализация, и видимо из-за этого и статьи на которую вы сослались выше и которая поверхностно и неточно раскрывает тему, мы и дискутируем.
Тут вы не передаете в модель текстовый файл.
Вместо этого вы при помощи готовой библиотеки подготавливаете набор тулов, а потом передаете его в LLM, чтобы она используя эти тулы могла при желании открыть текстовый файл.
Подготовить набор тулов в данном случае значит написать @mcp.tool() перед некоторыми функциями, чтобы библиотека fastmcp по этим функциям самостоятельно
Подготовила правильный промпт для модели
Рассказала вашему приложению как правильно эти функции вызвать
Так пример из документации
@mcp.tool
def add(a: int, b: int) -> int:
"""Add two numbers"""
return a + bПревратится в
1) строчку в системном промпте к LLM: туда пропишется описание `Add two numbers` и подсказка что для этого действия нужно написать условное add(...), а еще указание, что параметры у функции целые
2) "связку" внутри вашего приложения (через которое вы общаетесь с LLM и в которое вы подключаете ваш MCP сервер) если модель написала add(...) то вызови функцию add.
То есть в вашем примере вы в LLM подсовываете не сам файл, а строчку `Если хочешь прочитать файл, то напечатай read_local_notes() и получишь содержимое файла`. Добавим к этому промпту факт, что приложение действительно этот запрос обработает - и теперь уже можем называть это тулом.
Довольно наглядно, что MCP в данном случае является объединением из большого количества тулов. Если вы напишете рядом еще одну функцию и добавите @mcp.tool то добавите в этот набор еще один тул.
вот зачем вы используете слова "набор", "объединение" и тп. на примере, где ровно одна функция с декоратором tool? Да, набор из одного элемента - тоже набор. Но, вы точно хотите так начинать объяснение людям, которые вообще не в теме?
Статьи с упрощенными определениями, библиотеки со скрытой реализацией помогают сделать простейшую реализацию. С которой уже можно играть и разбираться дальше.
<del>
В статье не раскрыт механизм активации скиллов. То есть ясно, что скилл добавляется в промпт, но не раскрыто, что этому предшествует. Например, как агент понимает какой скилл ему активировать до того как оный попал в контекст? Или каким образом происходит передвижение от одного скилла к другому? В остальном статья довольно неплоха в качестве "демистификации" агентов для начинающих.
В статье описано, но кратенько. Любой скилл содержит секцию “когда использовать этот скилл”. В каждой сессии фреймворк формирует системный промт для модели, куда помимо непосредственно запроса пользователя подмешивает список всех активных тулов с описаниями и секции “когда использовать этот скилл” для всех активных скиллов. Если модель захочет что-то сделать, она попросит у фреймворка полный текст скилла через тул. Либо скилл может быть напрямую подмешан в запрос пользователя целиком, если он вызывает его явно.
Например, представим некий скилл для работы с docx файлами. Составим большой промт, где опишем, какими python библиотеками пользоваться для чтения docx файлов, как их правильно парсить и сохранять, чтобы модель не выдумывала велосипеды. В начале файла скилла напишем, что это скилл /docx с инструкциями по работе с docx файлами.
Если скилл активен, во все сессии будет подмешиваться в системный промт именно эта фраза, что в среде есть инструкция для работы с docx файлами, но без самого текста инструкции. Если модели потребуется в ходе сессии работать с docx, она вызовет тул skill-read и прочитает полный текст этого скилла.
Либо если пользователь явно пропишет в запросе “используя /docx оформи мне отчёт” - полный текст скилла добавится в запрос сразу, без промежуточного вызова тула на чтение полной инструкции.
Хорошое описание базовых понятий агентной разработки, причем полезное не только для новичков.
Тезис номер ноль - LLM умеет только получать текст и отдавать текст.
Таким образом - и Tools, и Skills, и MCP - это prompt-injection => prompt templates.
Hooks - подписка на события API (пока через конфиг).
Такие дела.
Tools, Hooks, Skills, MCP — что есть что?