Всё, что нужно знать о Model Context Protocol (MCP)

«Даже самые продвинутые модели ограничены своей изоляцией от данных — они заперты в информационных силосах и легаси-системах».
Anthropic о важности интеграции контекста

Сегодняшние большие языковые модели (LLM) невероятно умны, но находятся в вакууме. Как только им требуется информация вне их «замороженных» обучающих данных, начинаются проблемы. Чтобы AI-агенты действительно были полезны, им нужно получать актуальный контекст в нужный момент — будь то файлы, базы знаний, инструменты — и даже уметь совершать действия: обновлять документы, отправлять письма, запускать пайплайны.

Так сложилось, что подключение модели ко всем этим внешним источникам данных было хаотичным и нестабильным: разработчикам приходилось писать кастомные интеграции или использовать узкоспециализированные плагины под каждый API или хранилище. Такие «сделанные на коленке» решения были хрупкими и плохо масштабировались.

Чтобы упростить это, Anthropic представила Model Context Protocol (MCP) — открытый стандарт, предназначенный для того, чтобы связать AI-ассистентов с данными и инструментами, подключая любые источники контекста. MCP был анонсирован в ноябре 2024 года. Тогда реакция была сдержанной. Но сегодня MCP — на волне: он уже обогнал LangChain по популярности и, по прогнозам, скоро обойдёт OpenAPI и CrewAI.

Крупные игроки AI-индустрии и open source-сообщества начали активно поддерживать MCP, видя в нем потенциально революционный инструмент для построения агентных систем на базе LLM.

Почему?

В этой статье мы глубоко погрузимся в тему MCP: разберёмся, почему вокруг него сейчас такой ажиотаж, как MCP ускоряет переход к более интегрированному и контекстно-осведомленному AI, какое место он занимает в агентных пайплайнах и какие малозаметные, но важные детали стоит знать разработчикам, исследователям, AI-инженерам и техническим руководителям. Мы также рассмотрим несколько инновационных сценариев использования MCP, которые пока реализовали немногие.

Это отличное введение в тему для тех, кто только начинает, и в то же время — полезный материал для тех, кто уже экспериментировал с MCP и хочет углубиться дальше.

Поехали!

Почему MCP на слуху именно сейчас (а не в ноябре прошлого года)?

MCP был впервые представлен и выложен в открытый доступ компанией Anthropic в конце ноября 2024 года. На тот момент это выглядело как многообещающая идея, но всерьёз её восприняли немногие. Лишь в начале 2025 года MCP по-настоящему ворвался в сознание AI-сообщества. Причины этого резкого всплеска интереса — весомые:

1. Решение проблемы интеграции

AI-агенты и agentic workflows стали модными терминами ещё в 2023–2024 годах, но у них был ахиллесов путь — подключение к реальным бизнес-системам и данным. Первоначально внимание концентрировалось на самих моделях и техниках prompt-инжиниринга, а не на интеграции.

MCP четко решает именно эту проблему, формализуя, как можно подключать существующие источники данных (файловые системы, базы данных, API и т. д.) в агентные AI-пайплайны. По мере того как сообщество осознавало это, MCP начали воспринимать как недостающее звено для серьёзных, продакшн-готовых AI-систем.

(Один из выводов конференции HumanX: «Последние годы мы фокусировались на создании отдельных моделей, заточенных под конкретные задачи. Но по мере роста сложности задач начинается переход к интегрированным системам — композициям из нескольких специализированных моделей, API, компонентов и интерфейсов, работающих как единое целое».)

2. Комьюнити и активное внедрение

Всего за несколько месяцев MCP превратился из концепта в полноценную экосистему. Одними из первых его внедрили такие компании, как Block (Square), Apollo, Zed, Replit, Codeium и Sourcegraph, начав интеграцию MCP в свои платформы.

К началу 2025 года всё взорвалось: к февралю сообщество создало более 1000 MCP-серверов (коннекторов). MCP явно попал в нерв времени — индустрия движется к более интегрированному и контекстно-осведомлённому AI, и стандарт, позволяющий это унифицировать, оказался крайне востребован.

Эффект сети делает MCP ещё привлекательнее: чем больше MCP-интеграций, тем выше мотивация у остальных присоединяться к стандарту.

3. Укрепление позиций в качестве де-факто стандарта

В отличие от очередного проприетарного SDK или фреймворка-однодневки, MCP — это открытый, модель-независимый стандарт, поддерживаемый серьёзным игроком в AI. Это значит:

– MCP можно использовать с любой моделью — Claude, GPT-4, открытые LLM
– Любой разработчик или компания может создать MCP-интеграцию без разрешений или лицензий

Сегодня многие в сообществе уже воспринимают MCP как наиболее вероятного кандидата на статус индустриального стандарта подключения AI к внешним данным — как USB, HTTP или ODBC в своих сферах.

4. Быстрая эволюция и образовательные усилия

Anthropic не просто выложила MCP в open source и ушла. Они продолжают активно развивать протокол и обучать сообщество. На недавнем AI Summit Махеш Мураг из Anthropic провел воркшоп по MCP, который стал вирусным и дал мощный импульс к его внедрению.

Так что же такое MCP и как он работает?

MCP задает четкие правила того, как AI может находить, подключаться и использовать внешние инструменты — будь то выполнение запроса к базе данных или запуск команды. Это позволяет моделям выходить за пределы своих обучающих данных, делая их более гибкими и осведомленными о внешнем мире.

Технический обзор MCP:

Протокол использует сообщения JSON-RPC 2.0 для установления связи между:

  • Hosts (Хосты): приложения LLM, инициирующие соединения

  • Clients (Клиенты): коннекторы внутри хост-приложения

  • Servers (Серверы): сервисы, предоставляющие контекст и функциональность

MCP частично вдохновлен Language Server Protocol, который стандартизирует добавление поддержки языков программирования во всей экосистеме инструментов разработки.

Аналогично этому, MCP стандартизирует способы интеграции дополнительного контекста и инструментов в экосистему AI-приложений.

Одна из ключевых особенностей MCP — динамическое обнаружение: AI-агенты автоматически определяют доступные MCP-серверы и их возможности без четко прописанных интеграций. Например, если вы запускаете новый MCP-сервер (например, CRM-систему), агенты сразу могут распознать его и начать использовать через стандартизированный API — гибкость, недоступная в традиционных подходах.

Как на практике начать работать с MCP?

Что нужно для старта — так это официальная документация и репозиторий MCP. Anthropic открыла спецификацию и предоставила SDK (на таких языках, как Python и даже Java). Типичный порядок действий выглядит так:

  1. Запустите или установите MCP-сервер для нужного вам инструмента или источника данных.

  2. У Anthropic есть open-source-репозиторий с готовыми MCP-серверами для популярных систем: Google Drive, Slack, Git, базы данных и т.д. Установить их просто — зачастую достаточно выполнить одну команду и передать креденшлы или API-ключи.

  3. Настройте MCP-клиент в вашем AI-приложении.
    Если вы используете приложение Claude, можно добавить сервер через UI. Если вы пишете собственного агента — подключайтесь через MCP SDK, указав адрес и порт сервера.

  4. После активации MCP в клиенте, он автоматически распознает дополнительную функциональность: новые инструменты, ресурсы и prompt-шаблоны.

  5. Вызывайте и итеративно используйте.
    Теперь модель или агент может вызывать действия через MCP-сервер по мере необходимости. Следите за логами, чтобы убедиться, что вызовы корректны — вы будете видеть входящие запросы и ответы от MCP-сервера.

Для быстрого старта Anthropic рекомендует интеграцию с Claude Desktop (если у вас есть доступ), либо запуск примеров из официального quickstart-гайда. Сообщество также очень активно: каталог MCP-серверов стремительно растёт. Среди популярных коннекторов — интеграции с  Google: (Drive, Gmail, Calendar), Slack (доступ к чатам и файлам), Git/GitHub (взаимодействие с репозиториями), Базы данных, например, PostgreSQL, Браузеры: через WebDriver или Puppeteer и многие другие.

Многие MCP-серверы публикуются в каталогах, созданных участниками сообщества, а в официальном GitHub-репозитории MCP можно найти множество примеров и готовых реализаций. Если у вас есть специфический инструмент, для которого нет готового сервера, вы можете создать свой MCP-сервер с помощью SDK — зачастую это всего лишь тонкая обёртка над существующим API, экспортирующая его функции в MCP-формате.

Благодарим Уилла Шенка за разъяснения по поводу MCP и того, как начать с ним работать. Он поделился кратким практическим walkthrough, в котором демонстрирует работу MCP на примере сервиса мониторинга Tesla от Tezlab.

Как AI-системы работали с контекстом и доступом к инструментам до появления MCP?

Давайте кратко рассмотрим традиционные подходы к предоставлению AI внешних знаний и возможности действия, и чем MCP отличается от них:

  • Кастомные API-интеграции (одноразовые коннекторы). Самый распространённый метод — написание кастомного кода или использование SDK для каждого сервиса. Например, если вы хотите, чтобы AI-агент получил доступ к Google Drive и SQL-базе, вам нужно вручную интегрировать API Google и драйвер для базы данных, настраивая каждую аутентификацию, формат данных и бороться с «особенностями» каждой системы. Это неприятно. MCP, напротив, даёт один «ключ» (протокол), которым можно открыть множество дверей — и вы можете подключить новый MCP-сервер без необходимости менять клиент.

  • Плагины для LLM (например, OpenAI Plugins). В 2023 году появился подход с плагинами, использующими стандартизированное описание (чаще всего OpenAPI schema), чтобы модель могла обращаться к внешним API. Система плагинов ChatGPT, Bing Chat и других — пример такой интеграции. Хотя идея схожа с MCP (стандартизированный доступ к инструментам), плагины оказались ограниченными и проприетарными: Каждый плагин нужно было разрабатывать и хостить отдельно. Работают только в рамках конкретной платформы. Взаимодействие в основном однонаправленное (запрос → ответ), без полноценной сессии.

    MCP принципиально отличается. Это открытый стандарт, независимый от конкретного AI-провайдера.  Поддерживает двустороннее, интерактивное взаимодействие, ближе к диалогу между моделью и инструментом.

  • Использование инструментов через фреймворки (инструменты LangChain, агенты): Библиотеки оркестрации агентов, такие как LangChain, популяризировали идею предоставления моделям «инструментов» (функций) с описаниями. Например, у вас может быть инструмент search() или calculate(), и агент (через LLM) сам решает, когда их вызывать. Это мощный подход, но каждый инструмент всё равно требует кастомной реализации «под капотом» — библиотека LangChain выросла до 500+ инструментов с единым интерфейсом, но разработчикам всё равно приходилось вручную подключать эти инструменты и проверять, подходят ли они под конкретные задачи. MCP здесь можно рассматривать как дополнение: он предлагает стандартизированный интерфейс для реализации инструментов. Фактически, MCP-серверы можно воспринимать как библиотеку готовых инструментов, доступных любому агенту. Разница в том, где происходит стандартизация: LangChain создал стандарт, ориентированный на разработчиков (через интерфейс класса Tool) для интеграции инструментов в код агента. MCP, напротив, предлагает стандарт, ориентированный на модель — запущенный AI-агент сам может обнаружить и использовать любой инструмент, реализованный через MCP, прямо во время выполнения. Это значит, что даже если вы не прописали в коде агента конкретный инструмент, модель сможет подключить его «на лету». На практике эти подходы начинают сближаться: например, команда LangChain, заметив рост интереса к MCP, выпустила адаптер, который позволяет обращаться ко всем MCP-серверам (коннекторам) как к обычным инструментам LangChain. Таким образом, агент, построенный на LangChain или другом фреймворке, может вызывать MCP-инструменты наравне с любыми другими, используя развивающуюся MCP-экосистему.

  • Retrieval-Augmented Generation (RAG) и векторные базы данных: Распространённый способ предоставления контекста LLM — использовать retriever, который ищет по базе знаний (документы, эмбеддинги) и вставляет релевантные результаты в промпт. Это частично решает проблему ограничений по обучающим данным и памяти модели. Однако RAG в основном работает с статичными фрагментами текста и не даёт модели возможности выполнять действия или делать запросы, выходящие за рамки проиндексированных данных. MCP может работать в связке с RAG — например, MCP-сервер может выступать интерфейсом к векторной базе данных или поисковому движку, позволяя модели выполнять запросы как инструмент, а не полагаться на retrieval внутри промпта. Можно утверждать, что MCP — это более общий механизм: если RAG даёт пассивный контекст, то MCP позволяет модели активно получать и использовать контекст через формализованные каналы. В сценариях, где важны актуальные или интерактивные данные (например, запрос к живой базе данных или отправка обновления), MCP выходит за рамки простого извлечения текста — он позволяет запускать операции.

Является ли MCP волшебной таблеткой и универсальным решением?

Разумеется, MCP — это не волшебная таблетка, а скорее чрезвычайно удобный слой интеграции. Но, как и любая новая технология, он привносит собственные сложности и вызовы, которые разработчикам и организациям следует учитывать перед масштабным внедрением.

Один из ключевых вопросов — это дополнительная нагрузка, связанная с управлением множеством серверов инструментов. Запуск и поддержание соединений с этими локальными серверами может быть обременительным, особенно в продакшене, где критичны аптайм, безопасность и масштабируемость. Изначально MCP был ориентирован на локальное и десктопное использование, что вызывает вопросы относительно его применимости в облачных архитектурах и многопользовательских сценариях. Разработчики предлагают сделать MCP более стабильным и адаптивным к распределенным средам, но это по-прежнему остается вызовом.

Еще одна проблема — удобство использования инструментов. То, что MCP расширяет набор доступных моделью инструментов, вовсе не означает, что модель будет эффективно ими пользоваться. Опыт работы с предыдущими агентными фреймворками показал, что модели ИИ испытывают трудности с выбором и использованием инструментов. MCP пытается нивелировать этот недостаток, предоставляя структурированные описания и спецификации инструментов, однако успех по-прежнему зависит от качества этих описаний и способности модели их корректно интерпретировать. Подход, ориентированный на сообщество, о котором говорит, например, Харрисон Чейз (основатель LangChain), подразумевает, что хорошо задокументированные инструменты повышают юзабилити — но это область, которая всё ещё активно дорабатывается.

Помимо сложностей внедрения, стоит учитывать зрелость самой технологии. MCP остаётся относительно новой разработкой, подверженной быстрым изменениям и изменяющимся стандартам. Это может приводить к breaking changes, требующим регулярных обновлений как серверов, так и клиентов. Хотя базовая концепция MCP выглядит достаточно стабильной, разработчикам следует быть готовыми к обновлениям версий и эволюции best practices.

Еще один ограничивающий фактор — совместимость. В настоящий момент MCP имеет полноценную поддержку в экосистеме Anthropic (например, в Claude), но более широкое принятие остаётся под вопросом. Другие поставщики ИИ могут не поддерживать MCP из коробки, что потребует написания адаптеров или кастомных интеграций. Пока MCP не получит широкую поддержку на уровне AI-платформ, его применимость будет ограниченной.

Для более простых случаев применения MCP может быть даже избыточным. Если модели ИИ достаточно обращаться к одному-двум простым API, прямые вызовы могут оказаться более эффективным решением, чем разворачивание инфраструктуры с MCP. Крутая кривая обучения, связанная с системой сообщений MCP и настройкой серверов, означает, что выгоды от его использования должны быть соотнесены с уровнем сложности.

Отдельный пласт — безопасность и мониторинг. MCP, будучи посредником, требует надежной аутентификации и контроля доступа, чтобы исключить несанкционированное использование. В ответ на эти вызовы появились open-source инициативы вроде MCP Guardian, обеспечивающие логирование запросов и применение политик, однако обеспечение безопасности MCP в условиях enterprise всё ещё остается незавершенной задачей.

В целом, ни одно из этих ограничений не является критичным, но разумно начинать с экспериментальных или неприоритетных сценариев, чтобы оценить технологию в действии. Одно из главных достоинств MCP — активное сообщество. Поскольку технология открыта, возникающие проблемы можно обсуждать и решать совместными усилиями.

MCP в агентной оркестровке и его роль в агентном пайплайне

В предыдущих статьях мы рассматривали строительные блоки автономных агентов: профилирование (идентичность и контекст), знание, память, рассуждение/планирование, рефлексию и действие. Агенту необходимо наблюдать и понимать среду (профиль/знания), запоминать прошлые взаимодействия (память), планировать свои шаги, выполнять действия (вызов инструментов или генерация выходных данных), а затем — рефлексировать и учиться. Где здесь место MCP?

MCP сам по себе не является "агентным фреймворком" — он выступает как стандартизированный интеграционный слой для агентов. MCP отвечает именно за часть Action — точнее, за предоставление агентам стандартизированного способа выполнять действия с вовлечением внешних данных или инструментов. Он обеспечивает инфраструктуру ("plumbing"), которая подключает агента к внешнему миру безопасным и структурированным образом. Без MCP (или чего-то подобного) всякий раз, когда агенту нужно совершить внешнее действие — будь то загрузка файла, SQL-запрос или вызов API — разработчикам пришлось бы делать кастомную интеграцию или использовать ad-hoc решения. Это как собирать робота и вручную вытачивать каждый палец под конкретный предмет — трудоемко и непригодно для масштабирования.

Важно снова подчеркнуть: MCP не является движком оркестрации или "мозгом" агента. Это именно интеграционный слой внутри агентной архитектуры. Он дополняет инструменты оркестрации агентов, такие как LangChain, LangGraph, CrewAI или LlamaIndex, выступая как унифицированный "набор инструментов", из которого агент может вызывать внешние действия. Вместо того чтобы заменять оркестрацию — которая отвечает за то, когда и почему агент применяет инструмент — MCP определяет как осуществляется вызов и передача данных.

По сути, это стандартизованный API-шлюз для агентов, который снижает сложность интеграции с уровня «N×M» до «N+M», обеспечивая универсальную совместимость между клиентами (агентами) и серверами (инструментами). В конечном итоге MCP упрощает интеграцию внешних функциональностей, делая агентов более универсальными, адаптивными и способными выполнять сложные задачи в разнообразных контекстах.

Новые возможности, открываемые MCP

MCP — технология новая, и её потенциал лишь начинает раскрываться. Первая волна use-case’ов очевидна: подключение enterprise-данных к чат-ассистентам, расширение возможностей coding-агентов за счет доступа к репозиториям. Но появляются и более перспективные сценарии, способные вывести агентные системы на новый уровень.

Многошаговые workflows с кросс-системной координацией

Агентным системам часто приходится работать сразу с несколькими платформами. Допустим, AI планирует мероприятие: проверяет календарь, бронирует площадку, рассылает письма гостям, организует поездку и обновляет бюджетную таблицу. Сейчас это требует ручной связки API. MCP позволяет выполнять все эти действия через единый интерфейс. Агент вызывает серию MCP-инструментов (по одному на каждую задачу), сохраняя общий контекст — без потерь данных и без необходимости писать кастомные интеграции.

Агенты, понимающие своё окружение (включая робототехнику)

Помимо доступа к инструментам, MCP может использоваться для построения агентов, встроенных в умные среды — от smart home до операционных систем. AI-ассистент может взаимодействовать с сенсорами, IoT-устройствами или функциями ОС через стандартизированные MCP-серверы. Вместо работы в изоляции, агент получает реальное восприятие среды, что открывает возможности для более естественного и проактивного взаимодействия.

Кооперация агентов (Agent Societies)

Этот сценарий особенно интересен — MCP может стать общим рабочим пространством для мультиагентных систем. Специализированные агенты — один для ресерча, другой для планирования, третий для исполнения — смогут использовать MCP для обмена данными и динамической координации задач. При этом каждому агенту не нужно иметь прямую интеграцию с каждым инструментом — они просто работают с общим MCP-интерфейсом.

Персональные AI-ассистенты с глубокой интеграцией

MCP позволит пользователям конфигурировать собственных агентов, безопасно взаимодействующих с личными данными и приложениями. Локальный MCP-сервер может давать AI-доступ к письмам, заметкам, умным устройствам — без передачи чувствительной информации третьим сторонам. Это создаёт возможность построения по-настоящему персонализированного AI-ассистента без зависимости от облачных сервисов.

Корпоративное управление и безопасность

Для бизнеса MCP стандартизирует доступ AI к внутренним инструментам, снижая затраты на интеграции. Кроме того, он вводит слой governance: взаимодействия можно логировать, мониторить и контролировать, предотвращая нежелательные действия и одновременно сохраняя эффективность.

Это лишь первые намёки на потенциал MCP. Благодаря поддержке гибких, контекстно-зависимых, многошаговых взаимодействий он приближает AI-агентов к действительно автономному исполнению сложных workflow.

Заключение

MCP стремительно превращается в мощный стандартный протокол, который делает из AI не просто изолированный "мозг", а универсального "исполнителя". Упрощая взаимодействие агентов с внешними системами, он прокладывает путь к более мощным, интерактивным и удобным AI-воркфлоу.

Ключевые фичи, которые появятся в ближайшее время (на основе воркшопа от Mahesh Murag, Anthropic)

Удалённые сервера и OAuth

  • Прозрачный запуск на удалённых хостах с использованием SSE.

  • Встроенная поддержка OAuth 2.0 для безопасной интеграции (например, со Slack).

Официальный MCP-реестр

  • Централизованный механизм обнаружения и верификации серверов.

  • Поддержка enterprise-сценариев: возможность развёртывания приватных реестров.

Well-Known Endpoints

  • Стандартизированные .well-known/mcp-файлы для автоматического обнаружения first-party MCP-серверов.

Дополнительные улучшения

  • Поддержка стриминга, stateless-соединений, проактивного поведения серверов и более гибкое namespacing.

  • Каждое обновление делает MCP более устойчивым и пригодным для глубокой интеграции AI-агентов в реальные производственные воркфлоу.

Это совместно развиваемая инициатива, так что следите за roadmap’ом, участвуйте в обсуждениях и помогайте формировать будущее на стыке AI и софта.

Комментарии (8)


  1. jakobz
    11.07.2025 04:16

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

    Вот если всякие confluence сделают у себя mcp по http с авторизацией, чтобы работать от имени пользователя - может быть и поедет.

    И, было бы лучше, если бы клиентов научили подключать Open API с oauth. Без странной обертки того же самого, с json rcp, которую весьма нетривиально реализовать.


    1. tokarev
      11.07.2025 04:16

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

      тоже сейчас столкнулись с этой проблемой. Уже есть какое-то более-менее "стандартное" решение или надо свой велосипед придумывать?


      1. jakobz
        11.07.2025 04:16

        Хороших решений пока не видно.

        Десктопные клиенты можно авторизовать в http mcp по oauth - какие-то нативно, какие-то через прокладку mcp-remote. Но сделать mcp-сервер с авторизацией через oauth на сервере под такое - весьма нетривиально. Мы сделали прокси, которая логинит тот же cursor через наш sso, и выставляет внутренние rest api - в которые ходит bearer-токеном.

        Веб-клиенты у нас свои, и из них можно ходить bearer-токеном сразу, без хитрого oauth-flow из mcp-стандарта. Это завелось, но там - честно говоря - проще было подключить тулы через oauth, mcp там непонятно зачем.

        Ни одного сочетания из готового mcp-клиента (типа cursor), и стороннего http mcp-сервера (хотелось бы jira, confluence, gitlab, figma, и т.п) - не обнаружено пока. Даже через какие-либо готовые прокси.

        Т.е. несмотря на весь вой в интернетах, ни один llm-чатик пока не подключается ни к одному популярному saas/on-prem решению, нативно и с авторизацией. Только через на скорую руку слепленные консольные mcp-прокладки, куда надо пихать токен руками, и только в десктопные клиенты.


        1. FifthLeg
          11.07.2025 04:16

          Хороших решений пока не видно

          Судя по тому что эти компании бросились свои браузеры клепать, то это будет решение. Т е. Собственный браузер это и будет "десктоп".

          Но тогда гугл им просто не переплюнуть.


    1. titan_pc
      11.07.2025 04:16

      Так а в чём проблема консольные истории в докер запихать?

      Засунул в докер, подмазал, подкрасил, подшпаклевал. Навешал метрик. И готово.

      Опенсорс же. Он всегда такой был.


    1. sidewinder1
      11.07.2025 04:16

      В это же время Google вслед за Anthropic выпускает консольные инструменты - Gemini CLI, Claude Code, и они действительно хороши для определённых задач, и в числе прочих могут сами тестировать написанный ими код и сами же его исправлять. И очень хорошо дружат с консольным MCP-решением task-master.dev


  1. Elaugaste
    11.07.2025 04:16

    В текущем виде mcp это баловство. Ставить питон, node и возиться с конфигом для подключения.. Плюс все это еще может быть несовместимо между собой, потому лучше все это в докер, а у юзера винда. Значит что докер в wsl а он тормозной..

    В общем, жизнеспособны только mcp не требующие установки каких то зависимостей. Работающие на винде и мак, и настраивающие "подключение" к условному claude desktop самостоятельно (не ломая то что уже настроено).


  1. FifthLeg
    11.07.2025 04:16

    В конце концов сделают что-то типа okta, где провайдеры и сервиса будут коммуницировать с друг другом, вся эта децентрализованная хрень в энтерпрайзе не взлетит, слишком много головняка.

    Тот сделает этот центр, с биллингом, разгранечением доступа и т.п. будет в выйгрыше.

    По MCP надо и сами AI модели выставить, пусть с друг другом взаимодействие, тип проверок, преобразование неструктуированных данных и т.п.