Tools, Hooks, Skills, MCP — что есть что?

[Genius_Russian_Coders]

Отличный разбор! Как разработчик, работающий с агентными системами, добавлю важный нюанс: ключевое различие между Tools и Skills часто лежит в уровне абстракции. Tools — это атомарные действия (вызов API, чтение файла), а Skills — скомпонованные сценарии, которые могут комбинировать несколько Tools + промпт-инструкции. На практике мы пришли к тому, что Agent Loop должен быть максимально тонким — роутинг, вызов инструментов, проверка стоп-условий. Вся «логика» уходит в Skills и системный промпт. Это сильно упрощает отладку.

[vanek_goriachev]

Спасибо за отзыв!

Tools и Skills действительно можно определить, как "атомарные действия" и "сценарии", и один из заключительных тейков статьи состоит в том, что если вы можете сделать "атомарным действием" сразу весь "сценарий", то так и следует поступить. Это и разгрузит контекстное окно, и повысит точность.

[AndrewBond]

Неожиданно практически ничего нет по MCP.

Когда спросил по этой теме саму LLM, она выдала мало похожего на то, что в этой статье.

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

[vanek_goriachev]

Я раскрыл термин MCP с пользовательской точки зрения, а не с технической. Фраза "подключить mcp сервер к агенту" буквально значит "дать агенту пачку тулов, чтобы он мог что-то делать" (например создавать те же события в календаре).

То, что вы привели как определение MCP на мой взгляд скорее является определением для RAG базы знаний. Нарезали данные на кусочки (чанки), каждому дали свой вектор, сложили все в векторную БД и теперь по вводу слова "Doсker" быстро находим кусочки, которые близки по смыслу, обогащаем ими пользовательский промпт и модель генерит ответ чуть лучше.

Глобальная цель MCP - создать в индустрии некий стандарт (P это протокол)

1) разработчик MCP сервера дает некоторый инструментарий (набор тулов) пользователю и точно знает, что пользователь сможет им воспользоваться (потому что это стандарт индустрии)

2) пользователь MCP сервера абстрагируется от всего и просто получает готовый набор инструментов (тулов) для того, чтобы дальше строить свои более сложные сценарии (скиллы)

upd. Добавил пару предложений про MCP в качестве примеров

[AndrewBond]

вот этот текст целиком нисколько не приблизил к пониманию термина MCP. Читаю - "mcp - создать стандарт" - ни о чем вообще. "разработчик mcp передает некий инструментарий, набор тулов" - было бы понятно, если бы не прочитал другое определение -
MCP сервер - это сервис, который предоставляет определённые услуги (например, поиск по локальной файловой системе, в БД или работа по API с GitHub). LLM может использовать эти сервисы для решения поставленной задачи.

гораздо понятнее и ближе к тому, что выдала по этому же запросу llm. Серверу MCP необязательно возвращать tool. Это может быть и текст и промпт.

Так как-то понятнее, если вообще ничего по теме не знаешь

[vanek_goriachev]

Пожалуй да, написал недостаточно понятно

Цель 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, а остальные концепции я решил не раскрывать в этой статье.

[AndrewBond]

Я понял. Мы говорим о том же самом. Только вы используете термины, которые я бы никогда не понял, если бы буквально накануне не пытался бы разобраться в теме.

Например:

1. Ресурсы это "существительные" - например профиль пользователя или пост в ленте. Они недоступны LLM - спецификация определяет их как "Resources in MCP are designed to be application driven"

2. Ресурсы (Resources)

   • База знаний: Сервер предоставляет доступ к базе данных FAQ, технической документации или справочным материалам, что позволяет LLM обрабатывать вопросы с более глубоким контекстом.

     [вырезано...]

П1 мне ничего не говорит. П2 позволил мне сразу набросать простенький MCP (дока по локальному api, я увидел, как я могу применить это у себя).
П2 это из https://habr.com/ru/articles/879970/

[vanek_goriachev]

Мне, честно говоря, кажется, что в этой статье автор плохо раскрыл тему.

Среди примеров для 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" (и ниже картинка из документации - что имеется ввиду).

Пример того, как клиент (например IDE) может предоставить пользователю доступ к prompts полученным от MCP сервера

Спецификация явно указывает, что промпты используются пользователем, а не моделью. А в примере из статьи говорится "Если пользователь запрашивает конвертацию валют", что явно указывает на то, что автор думает, что промпт от mcp сервера работает как skill (и буквально описывает тригер для этого скилла).

Ближайшей аналогией в данном случае являются commands доступные в Claude Code. Это тоже предподготовленные промпты, но живущие не на сервере, а на клиенте и также доступные пользователю для "вызова".

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

[AndrewBond]

совершенно не понятно, например, чем отличаются tools от resources.

Вообще, это как раз в вашей непонятно. Вы сводите одни термины к другим терминам, затем к ненужным уточнениям типа "цель - стандарт". Вот на кой мне знать, что цель - стандарт? Или что в данном контексте "Resources in MCP are designed to be application driven"?

А по его выходит, что если просто подсунуть LLM текстовый файл, это уже MCP сервер. Окей, я по-быстрому собираю mcp, который будет скармливать локальную документацию llm. Что я получил на выходе? Правильно, tool. Но это теперь я знаю, что это tool. Хотя, в определении было " Сервер предоставляет доступ к базе данных FAQ, технической документации или справочным материалам". И оно дало мне понять, что я как-то могу это использовать.

В итоге есть ваше определение, которое мне вообще ни о чем не говорит, и "неправильное" определение, которое дало мне понятие о том, что я могу как-то это использовать (и я использовал).

Что из этого правильнее даже обсуждать не буду, еще условно вчера я даже терминов этих не знал.