#mcp #thoughts #architecture
🔄 MCP: Текущие проблемы и варианты решения
Коллеги, добрый вечер! 👋
Я думаю, что многие уже успели попробовать подключение внешних инструментов к text2code агентам вроде Cursor/Windsurf/Cline/etc
Это достаточно удобно (даже для Windows уже появились вполне себе рабочие конфигурации на https://smithery.ai/), но в этой заметке я бы хотел подсветить существующие проблемы MCP, о которых стоит знать 🧐
🤔 В чем основная проблема MCP?
MCP — stateful протокол с долгоживущим соединением между клиентом и сервером. Это означает, что:
- 🔌 Требуется постоянное соединение между клиентом и сервером
- 🏗 Нельзя развернуть MCP в бессерверной (serverless) среде
- 🔄 Необходимо поддерживать SSE (Server-Sent Events) или WebSockets
Данный факт может стать серьезным барьером для разработчиков 😱
Вместо того, чтобы быстро развернуть функцию в AWS Lambda (у нас аналогом может выступать Yandex Cloud Functions) или Vercel, приходится разворачивать и настраивать выделенные серверы или кластеры Kubernetes (могут потребоваться DevOps скиллы).
🧩 Почему MCP спроектировали как stateful протокол?
Разработчики MCP выделяют несколько killer фич, ради которых MCP был спроектирован как statefull:
- 📢 Уведомления от сервера в сторону клиента об изменениях ресурсов или инструментов
- 🤖 Возможность сервера инициировать сэмплинг (sampling) в любой момент
- 📝 Передача логов сервера клиенту
- 🔮 Потенциальные будущие возможности
Одна из основных причин — сэмплинг (sampling), который позволяет серверу запрашивать у клиента выполнение запросов к LLM. Однако:
- ⚠️ Это создает потенциальные проблемы безопасности (сторонний MCP сервер, который вы подключили к своему агенту как инструмент, может получить доступ к приватным данным агента, например, к API-ключам)
- 🚫 Скорее всего поэтому сейчас ни один из клиентов MCP не поддерживает сэмплинг (см. здесь)
- 💰 Нет стимула для клиентов тратить свои токены на запросы от сервера
🛠 Возможные решения
В сообществе обсуждаются три основных варианта:
1️⃣ Добавить токены состояния/сессии
- Инкапсулировать состояние в токен, который передается между клиентом и сервером
- ✅ Простая эволюция текущего MCP
- ❌ Сложно для реализации серверами
2️⃣ Реализовать Stateless и Stateful варианты протокола
- Поддерживать оба варианта, позволяя разработчикам выбирать
- ✅ Простые серверы могут быть stateless
- ✅ Обратная совместимость
- ❌ Усложнение спецификации и SDK
3️⃣ Реализовать только stateless MCP
- Отказаться от функций, требующих режима stateful
- ✅ Простота для всех участников
- ❌ Потеря возможностей для агентных взаимодействий
- ❌ Несовместимость с текущей версией
🌟 Прогрессивное улучшение как компромисс
Интересный подход предложил инженер из Shopify — "MCP Lite" и прогрессивное улучшение:
1. 🔄 Базовый уровень: простой JSON-RPC для вызова инструментов
2. 📡 Опциональные уведомления через SSE/WebSockets для серверов, которые хотят их поддерживать
3. 🔄 Короткоживущие SSE-соединения только на время запуска инструмента
Это позволит:
- 🚀 Упростить внедрение MCP
- 🔧 Поддерживать сложные сценарии для тех, кто в них нуждается
- 📱 Работать в serverless-окружении
🔮 Альтернативы MCP
Существуют и более простые альтернативы, например, agents.json от Wild-Card-AI:
- 📄 Простой JSON поверх OpenAPI-спецификации
- 🔗 Использует существующие технологии
- 🧠 Не требует разворачивания выделенного сервера под AI tools
🔮 Будущее MCP
Для широкого принятия MCP необходимо:
- 🧪 Добавить поддержку stateless взаимодействий
- 🔄 Сделать stateful функции опциональными
- 🔑 Улучшить безопасность двунаправленной коммуникации при использовании sampling
- 📚 Решить проблему перегрузки контекстного окна при большом количестве инструментов
💭 Вывод
MCP имеет потенциал стать стандартом взаимодействия между AI-агентами и их инструментами, но нужно преодолеть существующие ограничения. Будем надеяться, что сообщество найдет компромисс между функциональностью и простотой использования! 🙏
А что вы думаете о том, в каком направлении должен развиваться MCP? Поделитесь в комментариях! 👇
#AI #MCP #ModelContextProtocol #Development
🔄 MCP: Текущие проблемы и варианты решения
Коллеги, добрый вечер! 👋
Я думаю, что многие уже успели попробовать подключение внешних инструментов к text2code агентам вроде Cursor/Windsurf/Cline/etc
Это достаточно удобно (даже для Windows уже появились вполне себе рабочие конфигурации на https://smithery.ai/), но в этой заметке я бы хотел подсветить существующие проблемы MCP, о которых стоит знать 🧐
🤔 В чем основная проблема MCP?
MCP — stateful протокол с долгоживущим соединением между клиентом и сервером. Это означает, что:
- 🔌 Требуется постоянное соединение между клиентом и сервером
- 🏗 Нельзя развернуть MCP в бессерверной (serverless) среде
- 🔄 Необходимо поддерживать SSE (Server-Sent Events) или WebSockets
Данный факт может стать серьезным барьером для разработчиков 😱
Вместо того, чтобы быстро развернуть функцию в AWS Lambda (у нас аналогом может выступать Yandex Cloud Functions) или Vercel, приходится разворачивать и настраивать выделенные серверы или кластеры Kubernetes (могут потребоваться DevOps скиллы).
🧩 Почему MCP спроектировали как stateful протокол?
Разработчики MCP выделяют несколько killer фич, ради которых MCP был спроектирован как statefull:
- 📢 Уведомления от сервера в сторону клиента об изменениях ресурсов или инструментов
- 🤖 Возможность сервера инициировать сэмплинг (sampling) в любой момент
- 📝 Передача логов сервера клиенту
- 🔮 Потенциальные будущие возможности
Одна из основных причин — сэмплинг (sampling), который позволяет серверу запрашивать у клиента выполнение запросов к LLM. Однако:
- ⚠️ Это создает потенциальные проблемы безопасности (сторонний MCP сервер, который вы подключили к своему агенту как инструмент, может получить доступ к приватным данным агента, например, к API-ключам)
- 🚫 Скорее всего поэтому сейчас ни один из клиентов MCP не поддерживает сэмплинг (см. здесь)
- 💰 Нет стимула для клиентов тратить свои токены на запросы от сервера
🛠 Возможные решения
В сообществе обсуждаются три основных варианта:
1️⃣ Добавить токены состояния/сессии
- Инкапсулировать состояние в токен, который передается между клиентом и сервером
- ✅ Простая эволюция текущего MCP
- ❌ Сложно для реализации серверами
2️⃣ Реализовать Stateless и Stateful варианты протокола
- Поддерживать оба варианта, позволяя разработчикам выбирать
- ✅ Простые серверы могут быть stateless
- ✅ Обратная совместимость
- ❌ Усложнение спецификации и SDK
3️⃣ Реализовать только stateless MCP
- Отказаться от функций, требующих режима stateful
- ✅ Простота для всех участников
- ❌ Потеря возможностей для агентных взаимодействий
- ❌ Несовместимость с текущей версией
🌟 Прогрессивное улучшение как компромисс
Интересный подход предложил инженер из Shopify — "MCP Lite" и прогрессивное улучшение:
1. 🔄 Базовый уровень: простой JSON-RPC для вызова инструментов
2. 📡 Опциональные уведомления через SSE/WebSockets для серверов, которые хотят их поддерживать
3. 🔄 Короткоживущие SSE-соединения только на время запуска инструмента
Это позволит:
- 🚀 Упростить внедрение MCP
- 🔧 Поддерживать сложные сценарии для тех, кто в них нуждается
- 📱 Работать в serverless-окружении
🔮 Альтернативы MCP
Существуют и более простые альтернативы, например, agents.json от Wild-Card-AI:
- 📄 Простой JSON поверх OpenAPI-спецификации
- 🔗 Использует существующие технологии
- 🧠 Не требует разворачивания выделенного сервера под AI tools
🔮 Будущее MCP
Для широкого принятия MCP необходимо:
- 🧪 Добавить поддержку stateless взаимодействий
- 🔄 Сделать stateful функции опциональными
- 🔑 Улучшить безопасность двунаправленной коммуникации при использовании sampling
- 📚 Решить проблему перегрузки контекстного окна при большом количестве инструментов
💭 Вывод
MCP имеет потенциал стать стандартом взаимодействия между AI-агентами и их инструментами, но нужно преодолеть существующие ограничения. Будем надеяться, что сообщество найдет компромисс между функциональностью и простотой использования! 🙏
А что вы думаете о том, в каком направлении должен развиваться MCP? Поделитесь в комментариях! 👇
#AI #MCP #ModelContextProtocol #Development
smithery.ai
Smithery - Model Context Protocol Registry
Extend your agent's capabilities with Model Context Protocol servers.