PRO то, зачем нам MCP 🤖
(часть 01).
По результатам опроса вот тут: ссылка 👆 была выбрана тема MCP. Поэтому на этой неделе ее и раскроем и продолжим рассматривать нашу ситуацию, когда мы что-то хотим получить из JIRA.
До этого мы подключали Jira к нашей модели вручную.
Описали функцию jira_get_issue, получили от модели function_call, сами вызвали Jira API и вернули результат обратно.
Для одного инструмента всё довольно просто.
Но теперь представим, что у нашего агента есть Jira, Confluence, GitLab, корпоративная БД и ещё несколько внутренних сервисов. Для каждого нужно описать инструменты, реализовать вызовы, разобраться с авторизацией, обработать ошибки и поддерживать всё это при изменениях внешних систем.
И здесь появляется MCP.
Model Context Protocol предлагает стандартный способ подключать модель к внешним источникам данных и инструментам. Вместо того чтобы для каждого агента отдельно писать интеграцию с Jira, можно иметь MCP-сервер Jira, который предоставляет набор доступных возможностей.
Наш агент подключается к MCP-серверу, получает описание доступных инструментов и дальше может работать с ними через единый протокол.
Получается следующая последовательность:
1⃣ модель →
2⃣ MCP-клиент →
3⃣ MCP-сервер (со списком инструментов) →
4⃣ внешняя система
При этом важно не перепутать MCP с самим инструментом.
jira_get_issue может оставаться инструментом.
MCP определяет, как этот инструмент предоставляется и как с ним взаимодействовать.
И это принципиальное отличие от того, что мы делали раньше.
➖до MCP мы сами проектировали контракт между нашим агентом и каждым внешним сервисом.
➖с MCP часть этой работы стандартизируется.
В следующем посте заглянем внутрь MCP и посмотрим что на самом деле происходит, когда агент подключается к MCP-серверу: как он узнаёт, какие инструменты доступны, и откуда берутся их описания.
——
Раньше агенту приходилось для каждой системы писать свою интеграцию с нуля: контракт, авторизация, обработка ошибок заново. MCP даёт готовый стандартный способ подключения, чтобы не изобретать велосипед на каждый новый сервис. Аналитик часто в похожей ситуации: под каждый навык свой курс, свой формат, собирает по кусочкам.
Практикум {НСА} 3.0 🎓 даёт тот же принцип: готовый путь вместо сборки с нуля
Уже вот-вот стартуем наш практикум {НСА} 3.0 🎓, который не просто поднял свою версию, а существенно обновил подход к обучению. Теперь кроме стандартной практики появляется возможность многократно отточить навыки в наших тренажерах:
✔️ тренажер по разработке требований
✔️ тренажер по работе с базами данных
✔️ тренажер по работе с интеграциями
✔️ тренажер по работе с нотациями
✔️ тренажер по работе с пользовательским интерфейсом
После работы в тренажерах вы будете ощущать себя еще более уверенными как на собеседованиях, так и на испытательном сроке. 😎
За информацией обращайтесь в личку или пишите под постом + и я напишу вам сам.
——
✌️ ПРО СА|🎓 НСА 3.0
(часть 01).
По результатам опроса вот тут: ссылка 👆 была выбрана тема MCP. Поэтому на этой неделе ее и раскроем и продолжим рассматривать нашу ситуацию, когда мы что-то хотим получить из JIRA.
До этого мы подключали Jira к нашей модели вручную.
Описали функцию jira_get_issue, получили от модели function_call, сами вызвали Jira API и вернули результат обратно.
Для одного инструмента всё довольно просто.
Но теперь представим, что у нашего агента есть Jira, Confluence, GitLab, корпоративная БД и ещё несколько внутренних сервисов. Для каждого нужно описать инструменты, реализовать вызовы, разобраться с авторизацией, обработать ошибки и поддерживать всё это при изменениях внешних систем.
И здесь появляется MCP.
Model Context Protocol предлагает стандартный способ подключать модель к внешним источникам данных и инструментам. Вместо того чтобы для каждого агента отдельно писать интеграцию с Jira, можно иметь MCP-сервер Jira, который предоставляет набор доступных возможностей.
Наш агент подключается к MCP-серверу, получает описание доступных инструментов и дальше может работать с ними через единый протокол.
Получается следующая последовательность:
1⃣ модель →
2⃣ MCP-клиент →
3⃣ MCP-сервер (со списком инструментов) →
4⃣ внешняя система
При этом важно не перепутать MCP с самим инструментом.
jira_get_issue может оставаться инструментом.
MCP определяет, как этот инструмент предоставляется и как с ним взаимодействовать.
И это принципиальное отличие от того, что мы делали раньше.
➖до MCP мы сами проектировали контракт между нашим агентом и каждым внешним сервисом.
➖с MCP часть этой работы стандартизируется.
В следующем посте заглянем внутрь MCP и посмотрим что на самом деле происходит, когда агент подключается к MCP-серверу: как он узнаёт, какие инструменты доступны, и откуда берутся их описания.
——
Раньше агенту приходилось для каждой системы писать свою интеграцию с нуля: контракт, авторизация, обработка ошибок заново. MCP даёт готовый стандартный способ подключения, чтобы не изобретать велосипед на каждый новый сервис. Аналитик часто в похожей ситуации: под каждый навык свой курс, свой формат, собирает по кусочкам.
Практикум {НСА} 3.0 🎓 даёт тот же принцип: готовый путь вместо сборки с нуля
Уже вот-вот стартуем наш практикум {НСА} 3.0 🎓, который не просто поднял свою версию, а существенно обновил подход к обучению. Теперь кроме стандартной практики появляется возможность многократно отточить навыки в наших тренажерах:
✔️ тренажер по разработке требований
✔️ тренажер по работе с базами данных
✔️ тренажер по работе с интеграциями
✔️ тренажер по работе с нотациями
✔️ тренажер по работе с пользовательским интерфейсом
После работы в тренажерах вы будете ощущать себя еще более уверенными как на собеседованиях, так и на испытательном сроке. 😎
За информацией обращайтесь в личку или пишите под постом + и я напишу вам сам.
——
✌️ ПРО СА|🎓 НСА 3.0