Да, это 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 то добавите в этот набор еще один тул.
Вот только если подсунуть LLM текстовый файл это не будет mcp сервер... Это будет просто текстовый файл подсунутый в LLM.
Что такое MCP определено предельно четко. К MCP серверу есть зафиксированные в тексте требования.
Если ваше понимание MCP привело вас к действиям, которые помогли вам решить задачу - это отлично, но это не всегда значит, что вы сделали именно MCP.
Отмечу также, что текстовый файл скормленный в LLM также не будет являться тулом. Он может помочь вам ту же задачу, что и тул, но тулом (в его обычном определении) не станет.
Все таки у терминов есть свои определения и нередко подробное описание "как они устроены внутри" - когда мы говорим "это MCP сервер, а это не MCP сервер" следует описаться именно на них.
Мне, честно говоря, кажется, что в этой статье автор плохо раскрыл тему.
Среди примеров для 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. Это тоже предподготовленные промпты, но живущие не на сервере, а на клиенте и также доступные пользователю для "вызова".
Иначе говоря - я считаю что приведение примеров в таком виде, как приводит их автор статьи - дает либо неполное, либо ложное понимание. Но допускаю, что мои примеры в действительности не дают вообще никакого, сколь бы наглядными они мне не казались.
Цель 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, а остальные концепции я решил не раскрывать в этой статье.
Я раскрыл термин MCP с пользовательской точки зрения, а не с технической. Фраза "подключить mcp сервер к агенту" буквально значит "дать агенту пачку тулов, чтобы он мог что-то делать" (например создавать те же события в календаре).
То, что вы привели как определение MCP на мой взгляд скорее является определением для RAG базы знаний. Нарезали данные на кусочки (чанки), каждому дали свой вектор, сложили все в векторную БД и теперь по вводу слова "Doсker" быстро находим кусочки, которые близки по смыслу, обогащаем ими пользовательский промпт и модель генерит ответ чуть лучше.
Глобальная цель MCP - создать в индустрии некий стандарт (P это протокол)
1) разработчик MCP сервера дает некоторый инструментарий (набор тулов) пользователю и точно знает, что пользователь сможет им воспользоваться (потому что это стандарт индустрии)
2) пользователь MCP сервера абстрагируется от всего и просто получает готовый набор инструментов (тулов) для того, чтобы дальше строить свои более сложные сценарии (скиллы)
upd. Добавил пару предложений про MCP в качестве примеров
Tools и Skills действительно можно определить, как "атомарные действия" и "сценарии", и один из заключительных тейков статьи состоит в том, что если вы можете сделать "атомарным действием" сразу весь "сценарий", то так и следует поступить. Это и разгрузит контекстное окно, и повысит точность.
Если программист справляется с задачами мидла или сеньора, то он мидл или сеньор по факту, даже если справляется он в связке с гпт.
Не вполне с вами согласен Раньше скорость работы программиста и соответственно объем работы, который он способен выполнить без помощи других разработчиков очень сильно коррелировал с уровнем знаний. Рассуждение простое - если человек совершает работу быстро, то вероятно он совершал ее много раз в прошлом и скорее всего в этом самом прошлом успел набить себе много шишек и сделать выводы о том как писать код надо и как не надо.
Сейчас любой человек может сесть и создать сайт, не особо поняв что за что отвечает в его собственном коде (таких людей можно наблюдать даже в комментариях под этим постом). С таким подходом человек пишет много кода, но развивается очень слабо, либо не развивается вообще. На мой взгляд с точки зрения технических знаний и качества кода, которые можно получить от такого разработчика - мидлом или сеньором он скорее всего не является.
По сути сейчас человек без знаний может "справиться с задачами мидла или сеньора", но не потому, что ChatGPT сделал из него программиста этого уровня, а потому что ChatGPT сдвинул планку объема кода, которые может "написать" человек без знаний. Раньше столько кода мог написать только опытный специалист и как следствие код был качественным, теперь это может сделать кто угодно и качество кода получается соответствующее
Люди тоже пишут плохой код и все те же проблемы что описаны в статье будут актуальны для кода написанного командой джунов.
Раньше человек написав один проект набивал себе кучу шишек и сильно развивался и рос, а сейчас можно с помощью ИИ склепать с десяток проектов и так ничего и не понять. Из-за этого команда которая на бумаге состоит из сеньоров и мидлов по сути будет той же командой джунов, которая накрутит костылей и насажает багов.
Нейронками нужно уметь пользоваться (как и любым инструментом)
Согласен с вами и пишу об этом в конце статьи, возможно вы чутка не дочитали ее)
Ваше "классик vs prompt" — искусственная войнушка.
Частично согласен, но на крайнастях проблемы рассматривать проще - а именно это и была цель статьи - подсветить проблемы. Тоже думал о том, что рассуждения про крайности несколько искусственны, но все же решил оставить как есть
Многие разработчики используют ИИ как вспомогательный инструмент, сохраняя критическое мышление и контроль над процессом.
Согласен с вами и именно это я и пишу в конце статьи - именно так и нужно использовать ИИ
Буквально вчера увидел видео в котором идут похожие рассуждения
Там есть тейк про то, что на stackowerflow были сеньоры которые минусовали вопросы и говорили "иди разберись в теме, а не просто копируй код отсюда" Также видосе приводятся примеры, когда нейронка отвечает также)))
Разница в том, что ИИ отвечает так сильно реже, чем сеньоры. Если каждый такой ответ заставляет человека идти разбираться, что тот кто раньше "кодил через stackoverflow" ходил разбираться чаще, чем тот кто сейчас "кодит через ИИ"
Information
Rating
293-rd
Registered
Activity
Specialization
Бэкенд разработчик, Архитектор программного обеспечения
У меня его комментарий не вызвал подозрений до момента "вся логика уходит в Skills", но я решил не докапываться.
Ктож знал, ктож знал что это бот
Да, это mcp сервер, но от вас скрыта вся реализация, и видимо из-за этого и статьи на которую вы сослались выше и которая поверхностно и неточно раскрывает тему, мы и дискутируем.
Тут вы не передаете в модель текстовый файл.
Вместо этого вы при помощи готовой библиотеки подготавливаете набор тулов, а потом передаете его в LLM, чтобы она используя эти тулы могла при желании открыть текстовый файл.
Подготовить набор тулов в данном случае значит написать
@mcp.tool()перед некоторыми функциями, чтобы библиотекаfastmcpпо этим функциям самостоятельноПодготовила правильный промпт для модели
Рассказала вашему приложению как правильно эти функции вызвать
Так пример из документации
Превратится в
1) строчку в системном промпте к LLM: туда пропишется описание `Add two numbers` и подсказка что для этого действия нужно написать условное
add(...), а еще указание, что параметры у функции целые2) "связку" внутри вашего приложения (через которое вы общаетесь с LLM и в которое вы подключаете ваш MCP сервер)
если модель написала add(...) то вызови функцию add.То есть в вашем примере вы в LLM подсовываете не сам файл, а строчку `Если хочешь прочитать файл, то напечатай read_local_notes() и получишь содержимое файла`. Добавим к этому промпту факт, что приложение действительно этот запрос обработает - и теперь уже можем называть это тулом.
Довольно наглядно, что MCP в данном случае является объединением из большого количества тулов. Если вы напишете рядом еще одну функцию и добавите
@mcp.toolто добавите в этот набор еще один тул.Вот только если подсунуть LLM текстовый файл это не будет mcp сервер... Это будет просто текстовый файл подсунутый в LLM.
Что такое MCP определено предельно четко. К MCP серверу есть зафиксированные в тексте требования.
Если ваше понимание MCP привело вас к действиям, которые помогли вам решить задачу - это отлично, но это не всегда значит, что вы сделали именно MCP.
Отмечу также, что текстовый файл скормленный в LLM также не будет являться тулом. Он может помочь вам ту же задачу, что и тул, но тулом (в его обычном определении) не станет.
Все таки у терминов есть свои определения и нередко подробное описание "как они устроены внутри" - когда мы говорим "это MCP сервер, а это не MCP сервер" следует описаться именно на них.
Мне, честно говоря, кажется, что в этой статье автор плохо раскрыл тему.
Среди примеров для tools от приводит GitHub Server
А среди примеров для resources File System Server
На мой взгляд, тот факт, что автор приводит эти примеры говорит о его низком уровне понимания освещаемой темы. Из приведенных фрагментов (да и из статьи в целом) совершенно не понятно, например, чем отличаются tools от resources. Автор не упомянул ключевое отличие - что tools преднозначены для LLM, а resources для приложения (через которое пользователь взаимодействует с LLM).
Вынужден также признать, что когда я написал "ресурсы это существительные" я был неправ. Сам в этой части тоже пока разбираюсь (и потому решил в статье упомянуть эти концепции лишь вскользь). Понимание к которому я пришел в настоящий момент: ресурсом может быть и действие - например "сконвертировать валюту". Разница в том, что если пользователь нажимает на кнопку в приложении и приложение отправляет запрос на сервер, то это значит, что разработчик приложения использовал
resource(например - обычный REST запрос) при создании и теперь кнопка работает. А если это LLM пишетconvert(...), то же самое приложение это ловит и по ранее полученному описанию тула от сервера обращается на тот же сервер с тем же действием - это уже тул (связка "правильная инструкция для модели" + "правильно описание для приложения как запускать тул").А в качестве примера промтпа приведено следующее
И это еще нагляднее показывает, что автор на самом деле ничего не понял(
Я снова сошлюсь на спецификацию и приведу цитату - "Prompts are designed to be user-controlled <...> For example, as slash commands" (и ниже картинка из документации - что имеется ввиду).
Спецификация явно указывает, что промпты используются пользователем, а не моделью. А в примере из статьи говорится "Если пользователь запрашивает конвертацию валют", что явно указывает на то, что автор думает, что промпт от mcp сервера работает как skill (и буквально описывает тригер для этого скилла).
Ближайшей аналогией в данном случае являются
commandsдоступные в Claude Code. Это тоже предподготовленные промпты, но живущие не на сервере, а на клиенте и также доступные пользователю для "вызова".Иначе говоря - я считаю что приведение примеров в таком виде, как приводит их автор статьи - дает либо неполное, либо ложное понимание.
Но допускаю, что мои примеры в действительности не дают вообще никакого, сколь бы наглядными они мне не казались.
Пожалуй да, написал недостаточно понятно
Цель 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, а остальные концепции я решил не раскрывать в этой статье.
Я раскрыл термин MCP с пользовательской точки зрения, а не с технической. Фраза "подключить mcp сервер к агенту" буквально значит "дать агенту пачку тулов, чтобы он мог что-то делать" (например создавать те же события в календаре).
То, что вы привели как определение MCP на мой взгляд скорее является определением для RAG базы знаний. Нарезали данные на кусочки (чанки), каждому дали свой вектор, сложили все в векторную БД и теперь по вводу слова "Doсker" быстро находим кусочки, которые близки по смыслу, обогащаем ими пользовательский промпт и модель генерит ответ чуть лучше.
Глобальная цель MCP - создать в индустрии некий стандарт (P это протокол)
1) разработчик MCP сервера дает некоторый инструментарий (набор тулов) пользователю и точно знает, что пользователь сможет им воспользоваться (потому что это стандарт индустрии)
2) пользователь MCP сервера абстрагируется от всего и просто получает готовый набор инструментов (тулов) для того, чтобы дальше строить свои более сложные сценарии (скиллы)
upd. Добавил пару предложений про MCP в качестве примеров
Спасибо за отзыв!
Tools и Skills действительно можно определить, как "атомарные действия" и "сценарии", и один из заключительных тейков статьи состоит в том, что если вы можете сделать "атомарным действием" сразу весь "сценарий", то так и следует поступить. Это и разгрузит контекстное окно, и повысит точность.
Поделись, пожалуйста, названиями альтернативных проектов, которые считаешь стоящими
Не вполне с вами согласен
Раньше скорость работы программиста и соответственно объем работы, который он способен выполнить без помощи других разработчиков очень сильно коррелировал с уровнем знаний. Рассуждение простое - если человек совершает работу быстро, то вероятно он совершал ее много раз в прошлом и скорее всего в этом самом прошлом успел набить себе много шишек и сделать выводы о том как писать код надо и как не надо.
Сейчас любой человек может сесть и создать сайт, не особо поняв что за что отвечает в его собственном коде (таких людей можно наблюдать даже в комментариях под этим постом). С таким подходом человек пишет много кода, но развивается очень слабо, либо не развивается вообще. На мой взгляд с точки зрения технических знаний и качества кода, которые можно получить от такого разработчика - мидлом или сеньором он скорее всего не является.
По сути сейчас человек без знаний может "справиться с задачами мидла или сеньора", но не потому, что ChatGPT сделал из него программиста этого уровня, а потому что ChatGPT сдвинул планку объема кода, которые может "написать" человек без знаний. Раньше столько кода мог написать только опытный специалист и как следствие код был качественным, теперь это может сделать кто угодно и качество кода получается соответствующее
Люди тоже пишут плохой код и все те же проблемы что описаны в статье будут актуальны для кода написанного командой джунов.
Раньше человек написав один проект набивал себе кучу шишек и сильно развивался и рос, а сейчас можно с помощью ИИ склепать с десяток проектов и так ничего и не понять. Из-за этого команда которая на бумаге состоит из сеньоров и мидлов по сути будет той же командой джунов, которая накрутит костылей и насажает багов.
Согласен с вами и пишу об этом в конце статьи, возможно вы чутка не дочитали ее)
Частично согласен, но на крайнастях проблемы рассматривать проще - а именно это и была цель статьи - подсветить проблемы.
Тоже думал о том, что рассуждения про крайности несколько искусственны, но все же решил оставить как есть
Согласен с вами и именно это я и пишу в конце статьи - именно так и нужно использовать ИИ
Очень правильный тейк
Сейчас сформулирую и допишу в статью, спасибо
Буквально вчера увидел видео в котором идут похожие рассуждения
Там есть тейк про то, что на stackowerflow были сеньоры которые минусовали вопросы и говорили "иди разберись в теме, а не просто копируй код отсюда"
Также видосе приводятся примеры, когда нейронка отвечает также)))
Разница в том, что ИИ отвечает так сильно реже, чем сеньоры. Если каждый такой ответ заставляет человека идти разбираться, что тот кто раньше "кодил через stackoverflow" ходил разбираться чаще, чем тот кто сейчас "кодит через ИИ"