Создатели MCP рассказывают о происхождении, преимуществах архитектуры и будущем MCP

Автор:FounderPark

Протокол MCP, выпущенный Anthropic в прошлом году, в этом году благодаря ажиотажу вокруг Manus и AI-агентов (Agents) внезапно стал самым популярным протоколом в сфере искусственного интеллекта. Крупные технологические компании, такие как OpenAI, Microsoft и Google, также активно поддержали данный протокол, а китайские платформы Alibaba Cloud (Bailian) и Tencent Cloud быстро присоединились, запустив собственные платформы для быстрой сборки.

Однако дискуссии не прекращаются: многие подвергают сомнению существенную разницу между MCP и API, указывают на недостаточную экспертизу инженеров Anthropic в области интернет-протоколов, а также поднимают вопросы безопасности, связанные с излишней простотой протокола.

Чтобы прояснить ситуацию, было бы уместно, чтобы создатели протокола MCP ответили на эти вопросы самостоятельно.

В недавнем эпизоде подкаста Latent Space они пригласили создателей протокола MCP от команды Anthropic — Джастина Спэр-Самерса (Justin Spahr-Summers) и Дэвида Сорию Парру (David Soria Parra), чтобы подробно обсудить истоки возникновения MCP, их взгляды на развитие протокола: причины запуска проекта, отличия от существующих API, способы более эффективного использования инструментов и многое другое. Материал содержит огромный объем информации, рекомендуется добавить его в закладки.

Информация о гостях:

• Алессио Фанелли (ведущий): партнер и CTO компании Decibel

• swyx (ведущий): основатель Small AI

• Дэвид Сория Парра: инженер Anthropic

• Джастин Спэр-Самерс: инженер Anthropic

Краткое содержание (TLDR):

• Искра вдохновения для концепции MCP пришла во время внутреннего проекта Anthropic LSP (Language Server Protocol). Два инженера, вдохновившись LSP, задумались о возможности создать аналогичный инструмент для стандартизации коммуникации между AI-приложениями и расширениями.

• Ключевой принцип дизайна MCP заключается в том, что концепция инструмента выходит за рамки просто инструмента: она тесно связана с клиентским приложением, а значит, и с пользователем. При использовании MCP пользователь должен сохранять полный контроль. Под формулировкой инструменты контролируются моделью понимается лишь их автоматический вызов самой моделью, а не ручное указание пользователем конкретного инструмента (за исключением случаев, связанных с промптами).

• Открытые API и MCP не являются взаимозаменяемыми или противостоящими форматами, они крайне взаимодополняющи. Ключ лежит в выборе инструмента, наиболее подходящего для конкретной задачи. Если цель состоит в обеспечении насыщенного взаимодействия между AI-приложениями, MCP подходит лучше; если же требуется, чтобы модель легко читала и интерпретировала спецификации API, открытые API окажутся предпочтительнее.

• Для быстрой сборки MCP-серверов отлично подходит программирование с помощью ИИ. На ранних этапах разработки эффективно помещать фрагменты кода MCP SDK в контекстное окно LLM и поручать модели помощь в построении сервера — результат получается отличным. Детали можно доработать позже. Это хороший метод для быстрого запуска базовой функциональности и ее итеративного улучшения. Кроме того, команда MCP в Anthropic уделяет особое внимание упрощению процесса сборки серверов, чтобы стимулировать участие LLM.

• Будущее направление развития AI-приложений, экосистем и агентов смещается в сторону Statefulness (сохранения состояния), что является одной из самых дискуссионных тем внутри ядра команды MCP Anthropic. После многочисленных обсуждений и итераций был сделан вывод: несмотря на позитивный прогноз относительно Statefulness, нельзя отказываться от существующей парадигмы; необходимо найти баланс между идеей сохранения состояния и сложностью практической реализации.

Founder Park формирует комьюнити для разработчиков, приглашая всех, кто активно экспериментирует с новыми моделями и технологиями. Отправьте заявку через QR-код, подробно заполнив данные о вашем продукте/проекте. После модерации администратор добавит вас в чат.

После присоединения вы получите возможность:

• Обмениваться опытом по разработке с популярными моделями (такими как DeepSeek и др.);

• Получить доступ к ресурсам и напрямую взаимодействовать с провайдерами API, облачными платформами и производителями моделей для обмена обратной связью;

• Пользоваться удобными и интересными продуктами и кейсами, которые Founder Park будет активно продвигать.

01 Как родился MCP?

swyx (ведущий): сначала, что такое MCP?

Джастин: Model Context Protocol, сокращенно MCP, по сути, это дизайн, который мы создали, чтобы помочь AI-приложениям расширять свои возможности или интегрировать экосистему плагинов. Конкретнее, MCP предоставляет набор протоколов связи, позволяющий AI-приложениям (мы называем их клиентами) и различным внешним расширениям (мы называем их серверами MCP) взаимодействовать друг с другом. Эти расширения могут быть плагинами, инструментами или другими ресурсами.

Цель MCP заключается в том, чтобы разработчикам было легко подключать внешние сервисы, функции или получать дополнительные данные при создании AI-приложений, наделяя их более широкими возможностями. В нашем названии есть понятие client-server, чтобы подчеркнуть режим взаимодействия, но по сути мы создаем универсальный интерфейс для легкой расширяемости AI-приложений.

При этом важно подчеркнуть, что MCP ориентировано именно на AI-приложения, а не на сами модели, что является распространенным заблуждением. Также мы полностью согласны с тем, чтобы сравнивать MCP с USB-C интерфейсом для AI-приложений, поскольку это универсальное соединение, связывающее всю экосистему.

swyx (ведущий): характеристики клиента и сервера означают, что это двунаправленный протокол, подобно USB-C. Это интересно. Многие пытаются проводить исследования или создавать опенсорсные проекты. Мне кажется, Anthropic проявляет бóльшую активность в привлечении разработчиков, чем другие лаборатории. Интересно, повлияло ли на это внешнее давление, или же это идея, возникшая у вас двоих в комнате благодаря внезапному озарению?

Дэвид: фактически, это действительно результат нашего обсуждения с Джастином в комнате. Это не часть какой-либо грандиозной стратегии. В июле 2024 года, вскоре после моего поступления в Anthropic, когда я отвечал преимущественно за внутренние инструменты разработчика, я начал размышлять о том, как сделать так, чтобы больше сотрудников глубже интегрировали наши текущие модели.毕竟 эти модели великолепны, и их перспективы еще лучше, поэтому логично хотеть, чтобы их использовали чаще. Работая в этой сфере и опираясь на свой опыт разработки инструментов, я довольно скоро почувствовал разочарование. С одной стороны, Claude Desktop имеет ограниченную функциональность и плохо масштабируется, а среды IDE лишены полезных функций Claude Desktop. Приходилось постоянно копировать контент туда и обратно, что со временем стало неудобным. Я осознал, что это классическая проблема M x N, то есть проблема интеграции множества приложений с множеством различных систем, которую идеально решает единый протокол. В то время я занимался внутренним проектом, связанным с LSP (Language Server Protocol), но без особых успехов. Объединив все эти идеи, через несколько недель у меня появилась мысль построить определенный протокол: можно ли создать что-то похожее на LSP и стандартизировать коммуникацию между AI-приложениями и расширениями?

Затем я рассказал об этой идее Джастину, и к счастью, его она заинтересовала, поэтому мы совместно начали работу над реализацией.

С момента появления идеи прошло примерно полтора месяца до создания самого протокола и первой интеграции. Джастин взял на себя большую часть работы по первичной интеграции в Claude Desktop, а я провел множество proof-of-concept в среде IDE, демонстрируя применение протокола там. Посмотрев соответствующие репозитории кода перед официальным релизом, можно обнаружить много деталей. Вот примерная история происхождения MCP.

Алессио (ведущий): а какова была хронология событий? Я знаю, что 25 ноября состоялась официальная дата публикации. Когда именно вы начали работу над этим проектом?

Джастин: где-то в июле, сразу после того, как Дэвид предложил идею, я с энтузиазмом присоединился к нему для создания MCP. Первые месяцы шли довольно медленно из-за огромного объема базовой работы по созданию коммуникационного протокола с клиентской, серверной частью и SDK. Но как только стало возможным передавать данные через протокол, проект оживился: можно было строить невероятные приложения.

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

swyx (ведущий): возвращаясь к процессу создания MCP, мы видим лишь финальный результат, который явно вдохновлен LSP, в чем вы оба признаетесь.想知道构建时的工作量如何？构建过程主要是大量编写代码，还是做大量设计工作？我感觉设计工作占比大，比如选用 JSON-RPC，借鉴 LSP 的程度如何？还有哪些部分难度较大 ？

Джастин: Из LSP мы черпали много вдохновения. Дэвид глубоко разбирается в LSP благодаря своему опыту в разработке инструментов, тогда как я занимаюсь продуктами или инфраструктурой, поэтому LSP для меня была новой темой.

С точки зрения принципов проектирования, LSP решал упомянутую Дэвидом проблему M x N. Раньше различные IDE, редакторы и языки программирования работали изолированно: невозможно было использовать отличную поддержку Java от JetBrains в Vim, или превосходную поддержку C от Vim в JetBrains. LSP создал универсальный язык для общения сторон, унифицировал протокол и позволил editor-language парам реализовать взаимодействие всего один раз. Наша цель была схожей, но сценарий изменился на integration AI-application-extension.

В конкретных деталях, приняв решения об использовании JSON-RPC и концепции двунаправленной связи, мы пошли разными путями. LSP ориентирован на представление функций, предоставляя различные фундаментальные элементы, а не семантические принципы. Мы перенесли этот подход и в MCP. Затем мы потратили много времени на анализ каждого базового элемента MCP и причин его отличий — это требовало масштабной дизайнерской работы. Изначально мы планировали поддерживать три языка: TypeScript, Python и Rust для интеграции с Zed, создать SDK для клиентов и серверов, запустить внутреннюю экспериментальную экосистему и отладить локальную концепцию MCP (включая запуск дочерних процессов и т.д.).

Мы изучили критику в адрес LSP и постарались исправить недочеты в MCP. Например, некоторые практики LSP поверх JSON-RPC были слишком сложными, поэтому мы реализовали более прямые методы. Поскольку при создании MCP мы chose to innovate in specific domains while borrowing mature patterns elsewhere (например, выбор JSON-RPC не так важен), концентрируясь на инновациях в базовых элементах, помощь в использовании чужих наработок оказалась весьма полезной.

swyx (ведущий): меня интересует проектирование протоколов. Здесь много материала для дискуссий. Вы уже упоминали проблему M x N, с которой сталкиваются все, кто работает с инструментами для разработчиков, — это проблема universal box.

Основные проблемы и решения инфраструктуры сводятся к необходимости подключения множества вещей к N разным системам, поэтому достаточно создать universal box. Аналогичные проблемы возникали в Uber, GraphQL, Temporal (где я работал ранее) и React. Интересует, решали ли вы проблему N x N во времена работы в Facebook?

Дэвид: отчасти да. Это отличный пример. Мне доводилось решать подобные задачи в системах контроля версий и прочем. Суть в том, чтобы собрать всё в единый читаемый и записываемый формат, создав universal box для решения проблемы. В сфере инструментов для разработчиков такие вопросы встречаются повсюду.

swyx (ведущий): Interestingly, builders of universal boxes face identical challenges: composability, remote vs local issues, etc. As Justin mentioned regarding functional representation, fundamentally identical things require clear conceptual separation to manifest differently.

02 Ключевые концепции MCP: инструменты, ресурсы и промпты равно важны

swyx (ведущий): когда смотрел документацию MCP, у меня возник вопрос: зачем разделять эти две вещи? Многие считают вызовы инструментов универсальным решением, однако типология вызовов различна: иногда это ресурсы, иногда выполнение операций, иногда иное назначение. Хотел узнать, какие концепции вы относите к близким категориям и почему подчеркиваете их значимость?

Джастин: Мы рассматривали каждый базовый элемент с позиции разработчиков приложений. При создании ПО будь то IDE, Claude Desktop или интерфейс агента взгляд становится яснее, когда смотришь на желаемую пользователем функциональность из интеграций. Конечно, вызовы инструментов необходимы, но важно разделять разные типы функций.

Таким образом, изначально ядро MCP включало следующие базовые концепции, позднее дополненные:

• Инструменты (Tools): основа. Прямое предоставление модели инструмента, позволяющее ей самой принимать решения о вызове. Для разработчиков это похоже на function calls, инициированные исключительно моделью.

• Ресурсы (Resources): в основном означают данные или контекст, которые можно добавить в окружение модели и контролировать через приложение. Например: модель может автоматически искать релевантные ресурсы и включать их в контекст; или в приложении можно настроить четкий UI-элемент, например выпадающее меню или скрепку, чтобы пользователь мог вручную включить определенную часть данных в запрос к LLM. Это примеры использования ресурсов.

• Промпты (Prompts): специально разработанная текстовая структура или сообщение, инициируемое пользователем или заменяемое им. Представьте среду редактора: это как slash-команды или автодополнение, где есть макрос, который пользователь хочет прямо вставить и использовать.

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

Я вижу два направления: первое — сейчас вызовы инструментов составляют более 95% в интеграциях, и я надеюсь, что клиенты активнее станут использовать вызовы ресурсов и промптов. Первым внедрили промпты, они оказались практичны: можно создавать backtrace-friendly серверы MCP. Это взаимодействие, управляемое пользователем, решающее проблему ожидания обработки модели. Также хочу видеть больше демонстраций применения инструментов через промпты.

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

Алессио (ведущий): Есть тенденция treating everything as a nail because we have a hammer, то есть решать всё через tool calls. Например, многие используют это для SQL-запросов вместо resources. Интересно узнать преимущества и недостатки использования tools и resources при наличии API (например, БД). Когда лучше применять tool для SQL, а resource для данных?

Джастин: Разница между инструментами и ресурсами определяется тем, что tools инициируются самим агентом, который сам определяет, какой инструмент применить. Если цель заставить LLM выполнять SQL-запросы, целесообразно задать это как tool.

Ресурсы предлагают большую гибкость, но пока ситуация усложняется отсутствием поддержки в некоторых клиентах. Идеально для описания схемы таблиц БД использовать resource call. Пользователь может передать эти данные при старте диалога или позволить AI приложению автоматически найти ресурсы. Любая потребность в перечислении сущностей и чтении подходит для ресурса. Уникальная идентификация URI делает ресурс общим конвертером. Например, сервер MCP может интерпретировать пользовательский ввод URI. В редакторе Zed есть библиотека промптов, взаимодействующая с MCP для автозаполнения; обе стороны должны договориться о формате URI и данных — прекрасный кросс-пример использования ресурса.

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

swyx (ведущий): Верно, когда я увидел символ @ в Claude Desktop, сразу понял, что это дублирует функционал Cursor, теперь остальные пользователи тоже могут воспользоваться. Это отличная целевая установка: функция уже существует, и людям легко её понять и использовать. Я показал диаграмму, уверен, вы одобряете её ценность. Считаю её крайне полезной и рекомендуемой для размещения на первой странице документации. Отличная подсказка.

Джастин: Готовы отправить PR? Нам очень нравится эта рекомендация.

swyx (ведущий): Хорошо, я отправлю.

Как специалист по developer relations, я всегда стремлюсь давать четкие инструкции: сначала выдать ключевые тезисы, затем углубиться. Одна диаграмма, охватывающая суть, невероятно помогает. Ценю фокус на промптах. На ранних стадиях ChatGPT и Claude многие пытались создать библиотеки управления промптами вроде GitHub-репозиториев, но ничего массового из этого не вышло.

Действительно, требуется больше инноваций в этой нише. Ожидается динамичность промптов, и вы даете такую возможность. Полностью поддерживаю концепцию multi-step prompts: иногда для корректной работы модели требуются пошаговые промпты или преодоление ограничений. Промпт — это не однократный ввод, а цепь диалоговых процессов.

swyx (ведущий): Именно здесь концепции ресурсов и инструментов пересекаются. Иногда требуется контроль пользователя или приложения, иногда передача управления модели. Сейчас мы выбираем лишь подмножество tools?

Дэвид: Да, справедливое опасение. Фундаментально, core design principle MCP гласит: concept tool actually extends beyond the tool itself, tightly coupling it to the client app и user. Through MCP, user should maintain complete control. Under tool control by model, подразумеваем исключительно автономный вызов моделью, а не ручной выбор пользователем (за исключением использования в целях промптинга, что не должно становиться стандартным UI-паттерном).

В то же время считаю абсолютно оправданным фильтрацию и оптимизацию контента от MCP-серверов клиентскими приложениями. Клиент может загружать описания инструментов и оптимизировать их отображение. Согласно парадигме MCP, клиент обладает полным контролем. Также есть предварительная идея добавить в протокол функцию логической группировки базовых элементов (промптов, ресурсов, инструментов). Такие группы рассматриваются как отдельные серверы MCP, комбинируемые пользователем по мере необходимости.

03 MCP против OpenAPI: конкуренция или комплементарность?

swyx (ведущий): Давайте обсудим сравнение MCP и открытых API (OpenAPI), ведь это явно один из острых вопросов.

Джастин/Дэвид: По сути, спецификация open API чрезвычайно мощна, регулярно использую её при разработке API и клиентов. Однако для сценариев LLM она избыточно детализирована, не отражая высокоуровневых AI-specific концепций, таких как рассмотренные нами базовые элементы MCP и мышление разработчика. Модель получает больше пользы от специально созданных tools, resources, prompts, нежели от голого REST-API, предоставленного на её усмотрение.

С другой стороны, проектируя MCP, мы намеренно заложили statefulness. AI-взаимодействия изначально склонны к Statefulness. Хотя Stateless остается актуальным, по мере роста сложных паттернов (видео, аудио и пр.) Statefulness становится критически важным, соответственно, протокол сохраняет состояние крайне полезен.

Фактически, open API и MCP не противопоставляются, а взаимодополняют друг друга. Оба сильны и отлично работают вместе. Ключ в выборе инструмента под задачу: для rich interactions между AI-приложениями лучше подходит MCP; если модель должна легко читать и интерпретировать spec API, open API предпочтительнее. Ранее уже создавались мосты между ними, существуют инструменты трансформации specs, что замечательно.

Алессио (ведущий): Я со-вел хакатон в AGI Studios. Как разработчик personal agent, видел создание персонального агента, генерирующего MCP-сервер: достаточно ввести URL spec API, и он выдаст соответствующий сервер. Как оцениваете этот феномен? Означает ли это, что большинство серверов — лишь обертки поверх существующих API без уникального дизайна? Будет ли так всегда (полагаясь на AI для сопряжения legacy API) или появятся принципиально новые уникальные опыт MCP?

Джастин/Дэвид: Существовать будут оба варианта. С одной стороны, потребность importing data via connectors всегда ценна. Пока доминируют tool calls, в будущем other базовые концепции лучше подойдут для таких задач. Даже оставаясь adapter layer, адаптация под разные концепции добавляет ценности.

С другой стороны, точно появятся интересные сценарии построения MCP-серверов, выполняющих роли не просто адаптеров. Например, memory server позволяет LLM запоминать контекст across conversations; sequential-thinking server улучшает логические способности модели. Они не интеграцируют внешние системы, а дают модели новые паттерны мышления.

В любом случае использование AI для построения серверов абсолютно жизнеспособно. Даже если функционал не связан с обертками API, модель обычно находит пути реализации. Да, множество MCP-серверов станут API-обертками, что разумно и эффективно для быстрого прогресса. Но мы все еще в стадии exploration. По мере совершенствования client-side support базовых концепций涌现утся богатые experience. Например, server summarizing Reddit threads пока не создан, но протокол позволяет это. Когда спрос трансформируется из просто connect my interests to LLM into real workflows with rich interactive experiences, увидите born these innovative apps. Сейчас действует classic chicken-and-egg problem между client capabilities и server developers ambitions.

04 Быстрая сборка MCP-серверов: использование AI для кодирования

Алессио (ведущий): Еще одна малодискутируемая сторона — build servers. Что посоветуете начинающим? Как найти баланс между детальным описанием (для понимания модели) и отдачей raw data (для последующей автообработки)?

Джастин/Дэвид: Вот мои рекомендации. Плюс MCP: легко собрать базовый функционал за ~30 минут, чего хватит для старта. Лучший старт: выбрать язык с готовым SDK, создать tool для interaction, поднять сервер MCP, добавить tool, кратко написать description, подключить через stdin/stdout к вашему приложению, посмотреть как модель его использует.

Разработчики любят мгновенно видеть модель в действии с интересующими объектами. Это мотивирует погружаться глубже, размышлять о новых tools/resources/prompts, оценивать результаты и оптимизировать. Процесс непрерывный, но начинать с простого и наблюдать interaction невероятно увлекательно. MCP делает dev fun, quickly putting models to work.

Предпочитаю leverage AI assisted coding. Уже на старте обнаружили, что помещение фрагментов SDK MCP в контекст LLM значительно ускоряет сборку сервера. Детали правятся позже. Это быстрый путь к MVP и итерациям. С первого дня мы фокусируемся на simplification server setup для участия LLM. Запустить сервер раньше стоило 100-200 строк, проще не бывает. Если нет SDK, давайте спеки или другие SDK модели, пусть поможет. Tool calls в любимых языках обычно тривиальны.

Алессио (ведущий): Заметил, что server builders определяют формат/содержимое ответа. Пример: Google Maps, какие атрибуты вернуть, решает билдер. Без нужного атрибута пользователь не сможет override/modify. Похоже на мой дискомфорт с некоторыми SDK: пропустили новый параметр API, и фича недоступна. Как смотрите на это? Какова степень вмешательства пользователя или полная власть дизайнера?

Джастин/Дэвид: По примеру Google Maps, возможно, частично наша вина, так как это референсный сервер. Пока intentfully design tool outputs not necessarily structured JSON или matching schemas, returning messages like text/images directly consumable by LLM. То есть prefer returning massive data trusting LLM filter extract what matters. Много усилий затрачено на flexible access, ведь это сила LLM. Думать как раскрыть потенциал LLM rather than constrain specify rigidly избегая tech debt при развитии моделей. Поэтому в референсах ideal state pass through results type direct from invoked API automatically.

Алессио (ведущий):划定界限 действительно сложное решение.

Дэвид: Нужно немного emphasize роль AI. Многие example servers written by Claude unsurprisingly. Currently accustomed to traditional SE approaches relearn building systems trust LLM abilities. LLM improving yearly offloading data handling擅长 models wise decision. Means abandoning decades old traditional SE practices.

Viewing MCP anew AI development speed amazing both exciting slightly worrying. Biggest bottleneck next wave capabilities possibly external interaction capacity reading sources taking actions Statefulness. At Anthropic prioritize secure interactions controls calibration. As AI evolves people expect these connecting models external boost productivity key. MCP our bet future direction importance.

Алессио (ведущий): Согласен, любые API attributes formatted removed. Get raw data interfaces. Why pre-format? Models intelligent format addresses info themselves. Should end user decide.

05 Как улучшить MCP для большего количества вызовов инструментов?

swyx (ведущий): Еще вопрос: сколько related functions поддерживает одна реализация MCP? Вопрос глубины/ширины, связан с вложенностью MCP.

В апреле 2024 Claude продемонстрировал пример с million token context supporting 250 tools, practically models struggle effective utilization.某种程度上 это breadth issue, tool calling tool situations absent flat hierarchy easy confuse. Similar functionality leads wrong calls suboptimal results. Suggestions max enabled MCP servers simultaneously?

Джастин: Честно, absolute answer exists. Depends model tool naming descriptions clarity accurate understanding avoid confusion. Ideal feed LLM everything handle autonomously, MCP envisioned future reality clients supplement filtering toolsets using small fast LLM filter relevance pass large model additionally proxy routing MCP servers filter.

At least Claude supports hundreds safely. Other models unclear improves over time cautious limits prevent hindering growth. Supported count largely depends description overlap different functionalities unique names descriptions allow more than similar servers (simultaneously connecting GitLab GitHub).

Also relates AI application type highly intelligent applications reduce questioning configurability conversely IDE chat apps reasonable allow users select feature sets specific moments instead enabling always fully.

swyx (ведущий): В конце focus Sequential Thinking MCP Server branching提供更多编写空间功能有趣此外 Anthropic 上周发布新的工程博客介绍思考工具社区疑惑顺序思维服务器思考工具重叠实际上不同团队以不同方式做类似事情实现方法多样。

Джастин/Дэвид: Sequential Thinking servers Anthropic thinking tools direct common origins reflects普遍现象使 LLM think comprehensively reduce hallucinations achieve other goals exists many strategies multidimensional comprehensive reliability showcase这正是 MCP 强大之处可构建不同服务器或同一服务器内设置不同 product/tool实现多样化功能让 LLM 应用特定思维模式获得不同结果不存在规定理想 LLM 思考方式.

swyx (ведущий):认为不同应用场景需要不同用途 MCP 允许实现多样性对吗？

Джастин/Дэвид: Верно. MCP-серверы填补了模型当时能力空白模型训练准备研究耗时漫长逐步提升能力顺序思维服务器看似简单实际复杂短短几天搭建若内置复杂思考功能绝非几日能成打个比方模型可靠性不足或整体输出不满意设想 MCP 服务器生成三次查询结果挑选最优借助 MCP 实现递归组合 LLM 交互方式.

06 复杂 MCP 与 Agent 有什么区别？

Алессио (ведущий): Следующий вопрос о composability. Взгляд на引入 another MCP into MCP concepts plans? Build summarizing Reddit thread MCP likely调用对应 Reddit API MCP + summarization MCP 构建 super MCP 如何操作？

Джастин/Дэвид: Интересная тема двумя角度审视.

一方面考虑构建总结类组件虽调用 LLM 希望保持 model agnostic 涉及 MCP 双向通信功能 Cursor 管理 LLM 交互循环 server 开发者可通过 Cursor 向 client(用户应用)请求执行任务如使用当前选定模型总结返回结果选择取决于 Cursor 无需额外 SDK/API Keys 实现 truly model agnostic build.

另一方面利用 MCP 构建复杂系统完全可能设想 MCP 服务器为 Cursor/Windsurf 提供服务自身作为 MCP client 调用其他 MCP 服务器创造更丰富体验体现 recursive trait 规范授权体现模式串联既是 server 又是 client 应用甚至利用 MCP 服务器构建 DAG(Directed Acyclic Graph) 实现复杂交互流程智能 MCP 服务器甚至可利用整个生态能力已有相关实验自动选择安装等功能存在更多可能性目前 SDK 仍需补充细节方便开发者构建既是 client 又是 recursive MCP server 的应用或更方便复用行为未来完善内容目前展示可行尚未广泛采纳场景.

swyx (ведущий):听起来令人兴奋相信许多人从中获取灵感/启发既是 server 又是 client MCP 算是一种 Agent 吗某种程度上 Agent 是你发出请求它会执行你可能不完全清楚底层操作你和最终原始数据来源间存在一层抽象你们对 Agent 有何见解？

Джастин/Дэвид:确实可通过 MCP 构建 Agent 区分单纯 Agent MCP server plus client 真正 Agent 区别例如 MCP 服务器内部借助 client sample loop 丰富体验让模型调工具直接构建 true agent 相对直接.

MCP 与 Agent 关系几种思考方向:

其一 MCP 可能是表达 Agent 能力的绝佳方式或许缺某些提升交互体验特性功能应纳入 MCP 协议.

其二 MCP 可作为构建 Agent 或不同 Agent 间组合基础通信层当然存在其他可能性如认为 MCP 更应专注 AI 应用集成不过度聚焦 Agent 概念本身仍在探讨各方权衡回到之前 universal box 类比设计协议管理生态系统需特别小心避免功能繁杂不能让协议试图包罗万象否则各方面表现不佳关键问题在于 Agent 多大程度自然融入现有模型范式框架抑或作为独立实体存在仍是未解之谜.

swyx (ведущий):认为实现双向通信 client/server 合一委托工作给其他 MCP 服务器更像 Agent 欣赏始终牢记简洁性重要不试图解决所有问题.

07 MCP 下一步：如何让协议更可靠？

swyx (ведущий):近期从有状态到无状态服务器更新引人关注选择 SSE 作为发布协议传输方式并支持 pluggable 传输层背后原因受 Jared Palmer 推文影响早筹备之中？

Джастин/Дэвид:数月前进 GitHub 公开讨论过 Statefulness Stateless 难题权衡.我们认为AI应用生态系统及 Agent 未来发展方向倾向 Statefulness这是 MCP 核心团队最具争议话题之一历经多次迭代讨论结论尽管看好 Statefulness 未来不能背离现有范式必须在 Statefulness 理念与实际操作性复杂度之间找到平衡若要求 MCP 服务器长期持续连接部署运营难度极大最初 SSE 传输设计理念基本构想部署 MCP 服务器后客户端接入近乎无限期连接对大规模运营人士极高要求非理想部署运营模式.

因此思考平衡 Statefulness 重要性操作维护简便性推出的可流式 HTTP 传输包括 SSE 思路循序渐进服务器可为普通 HTTP 服务通过 HTTP POST 获取结果逐步增强支持结果流式传输甚至允许服务器主动发起请求只要双方支持 Session Resumption 兼顾 Statefulness 交互同时实现便捷扩展更好应对网络不稳定状况.

Алессио (ведущий):是的还包括会话 ID 关于未来身份验证计划目前部分 MCP 只需命令行粘贴 API 密钥 未来发展方向如何出现 MCP 专属配置文件管理类认证信息？

Джастин/Дэвид:协议下一版修订草案已纳入 authorization specification 当前关注用户到服务器授权采用 OAuth 2.1 或其现代子集效果不错大家以此为基础构建解决不少问题肯定不希望用户随意粘贴 API 密钥尤其多数服务器将是远程安全授权必要.

本地环境下授权定义传输层意味着需数据帧封装设置请求头标准输入输出 stdin/stdout 无法直接实现本地运行 stdin/stdout 程序操作灵活甚至打开浏览器处理授权流程关于本地是否使用 HTTP 授权内部尚未完全确定贾斯汀倾向于支持我个人不太赞同存在争议.

授权设计理念协议其他内容力求精简解决实际痛点功能先简化根据实际需求痛点逐步扩展避免过度设计设计协议需极其谨慎一旦犯错几乎不可挽回破坏向后兼容性只接受添加经过充分考量验证内容先让社区通过 extension mechanism 临时尝试直到广泛共识表明某些功能确应加入核心协议且有能力未来持续支持做法更容易稳健.

以授权 API 密钥为例大量头脑风暴当前授权方式(OAuth 2.1 子集)已满足 API 密钥使用场景 MCP 服务器可作为 OAuth 授权服务器添加功能访问其 /authorize 网页可能仅文本框输入 API 密钥虽非最理想但符合现有模式当下可行担心添加过多选项客户端服务器需考虑实现更多情况增加复杂性.

Алессио (ведущий): 有没有考虑 scopes 概念昨天与 Agent.ai 创建人 Dharmesh Shah 节目他举电子邮件例子拥有所有邮件希望能更细粒度 Scopes 控制只能访问这类邮件只能访问发给某人如今大多数 scope 基于 REST API 设计即你能访问哪些特定端点 未来模型有可能理解并利用 Scopes 层动态限制传输数据吗？

Джастин/Дэвид:认识到 Scopes 潜在需求讨论过将其加入协议需谨慎标准首要找到当前实现无法解决实际问题然后在 MCP 结构可扩展性基础上原型构建证明带来良好用户体验考虑正式纳入协议 Authorization 情况不同更多自顶向下(town-down)设计.

每次听到 Scopes 描述觉得有理但需具体端到端用例明确当前实现不足才能进一步展开讨论考虑到 composability logical grouping 设计理念通常建议 MCP 服务器小巧大量不同最好由独立离散服务器实现应用层组合也有反对意见不让单个服务器承担多服务授权任务认为服务本身对应各自独立服务器应用层组合.

08 MCP 服务器分发的安全问题

Алессио (ведущий): MCP 出色设计编程语言无关性了解 Anthropic 无官方 Ruby SDK OpenAI 也没有尽管 Alex Rudall 等开发者构建工具包出色有了 MCP 不再需为各语言分别适配 SDK 创建被 Anthropic 认可标准接口非常棒.

swyx (ведущий): 关于 MCP Registry 已出现五六家官方最初宣布注册中心停止运营服务模式提供下载量点赞数评价信任机制等让人联想到传统软件包仓库(npm/PyPI)但这觉得不太可靠即使有 social proof 下次更新也可能让信赖软件包面临安全威胁滥用信任体系感觉建立信任体系反因信任体系损害更倾向鼓励使用 MCP Inspector 只需查看通信流量许多安全问题或许借此发现解决你们如何看待注册中心安全问题供应链风险？

Джастин/Дэвид:说得完全正确所有注册中心都可能面临典型供应链安全问题行业有不同解决方案类似苹果 App Store 严格审核组建自动化人工审核团队完成这项工作确实是解决途径之一特定场景可行但我认为开源生态系统不太适用通常采用去中心化或社区驱动方式类似 MCP Registry npm package manager PyPI.

swyx (ведущий): 这些仓库本质都面临供应链攻击问题目前已在官方代码库发布一些核心服务器特别是内存服务器推理/思考服务器特殊类型似乎不仅是简单封装现有 API 使用起来可能比直接操作 API 更便捷.

以内存服务器为例市场专注内存功能初创公司不少使用此 MCP 内存服务器代码约 200 行非常简单当然复杂扩展需成熟方案只想快速引入内存功能它提供极好实现可能不需依赖公司产品对这些非 API 封装型特殊服务器你们有什么特别故事分享？

Джастин/Дэвид:其实没太多特别故事很多源于此前黑客松当时人们对 MCP 想法感兴趣 Anthropic 内部想要实现内存功能或尝试相关概念工程师借助 MCP 快速搭建以往难实现原型不再需要成为某领域端到端专家无需特定资源私有代码库即可为应用服务添加内存等功能很多服务器由此诞生同时发布时也考虑要展示多大范围功能可能性.

swyx (ведущий): 完全同意这在一定程度上成就了发布成功提供丰富示例供人们直接复制粘贴基础上扩展还想重点提文件系统 MCP 服务器提供编辑文件功能记得此前播客 Eric 展示出色 bench 项目社区对其中开源文件编辑工具非常感兴趣市面上有关联库方案将文件编辑能力视为核心知识产权你们直接开源功能真的非常酷.

Джастин/Дэвид:文件系统服务器个人最爱功能之一解决我当时实际限制业余游戏项目非常希望它与云服务及大卫此前提到的 artifacts 关联起来云服务与本地机器交互意义重大非常喜欢此功能.

典型例子服务器诞生于创建 MCP 过程中挫折及对这种功能需求从遭遇问题开发 MCP 及该服务器清晰直接演进脉络 Justin 感触尤其深心中占特殊地位可被视为协议精神起源点.

09 MCP 现在已是多家公司参与的大型项目了

swyx (ведущий): 关于 MCP 讨论热烈人们想参与辩论讨论该通过什么渠道直接在规范代码库讨论页面吗？

Джастин/Дэвид:在互联网发表意见容易付诸实践需付出努力我和 Jason 传统开源理念支持者认为开源项目中实际贡献至关重要如果你通过实际工作用具体例子展示成果并为 SDK 中想要的扩展功能投入精力想法更可能采纳仅停留意见层面声音可能被忽略当然重视各种讨论考虑有限时间精力优先关注投入更多实际工作者.

关于 MCP 相关讨论通知数量庞大需找到更具扩展性架构与社区互动确保讨论有价值成效运营成功开源项目有时需做出可能让部分人不满意艰难决定作为维护管理者必须明确实际愿景坚定朝既定方向推进即使有人不认同也没关系总可能存在更适合他们理念项目.

以 MCP 为例只是解决通用领域问题众多方案之一若不认可核心维护者选择方向开源优势就在于有更多选择可选择 fork 项目我们确实期望社区反馈努力让反馈机制更具扩展性但同时凭直觉做出我们认为正确抉择这可能在开源讨论引发很多争议这也正是此类开源项目尤其是快速发展领域项目本质所在.

swyx (ведущий): 幸运的是你们对做出艰难决定似不陌生 Facebook 开源项目提供了不少经验可借鉴即使未直接参与也能了解参与者做法我深度参与 React 生态系统之前成立工作组讨论过程公开成员都有发言权且有实际工作与重要贡献这种模式一段时间内很有帮助关于 GraphQL 发展轨迹早期热度与现在 MCP 有些相似经历 GraphQL 发展过程最终 Facebook 将其捐赠给开源基金会.

引出问题 MCP 是否也应这样做？问题并非简单是与否中存在权衡目前大多数人 Anthropic MCP 上工作满意毕竟是创造管理当发展到一定规模可能遇瓶颈意识到是公司主导项目人们最终期望真正开放标准由非营利组织推动具备多方利益相关者良好治理流程例 Linux 基金会 Apache 基金会管理项目知道现在讨论为时尚早想听听看法？

Джастин/Дэвид:开源领域治理确实有趣复杂一方面全力致力于 MCP 打造成开放标准开放协议开放项目欢迎所有人参与目前进展顺利例可流式传输 HTTP 很多想法来自 Shopify 等不同公司跨公司合作非常有效但我们确实担忧官方标准化尤其是通过传统标准化机构或相关流程 AI 这样快速发展领域流程可能显著拖慢项目发展速度因此需找平衡点如何在保持现有各方积极参与贡献同时解决治理模式可能存在的顾虑问题找对未来方向无需经历反复组织架构变动.

真心希望 MCP 真正开放项目虽由 Anthropic 发起我与 David 都在 Anthropic 工作但不希望仅仅视为 Anthropic 的协议.希望各个 AI 实验室公司参与或利用极具挑战性需努力平衡各方利益避免陷入委员会决策导致停滞困境开源领域存在多种成功管理模式我认为大部分微妙之处围绕企业赞助企业在决策过程中话语权妥善应对相关问题绝对希望 MCP 最终成为真正社区项目.

实际上目前很多非 Anthropic 员工拥有 MCP 代码提交管理权限例 Pydantic 团队 Python SDK 拥有提交权限 Block 等公司对规范做出诸多贡献 Java C# Kotlin 等语言 SDK 分别由 Microsoft JetBrains Spring AI 等不同公司负责完成且拥有完全管理权限所以仔细观察实际已是多家公司共同参与大型项目许多人贡献力量不止是我们两人对项目拥有提交权限相关权利.

Алессио (ведущий): 对未来 MCP 服务器或客户端有什么特别的愿望清单吗？有哪些特别希望人们构建但目前还没实现功能？

Джастин/Дэвид:希望看到更多 Support for Sampling 客户端也希望有人构建特定服务器总结 Reddit 讨论线程内容获取《星战前夜：晨曦》(EVE Online)上周动态特别前者(Sampling Client)与模型无关并非不想用 Claude 之外其他模型(Claude 目前最好纯粹希望有个 Support for Sampling 客户端框架.

更广泛说若有更多支持完整 MCP 规范客户端更好设计考虑了逐步采用可能性如果精心设计基本概念得到广泛应用将非常棒回想最初参与 MCP 工作动机及文件系统服务器兴奋点.

业余时间游戏开发者非常希望看到与 Godot 引擎集成 MCP 客户端服务器当时就用 Godot 开发游戏这样一来将 AI 集成到游戏中极其轻松或让 Claude 运行测试我的游戏比如让 Claude 玩宝可梦游戏现在已有实现基础更进一步从现在开始让 Claude 用 Blender 为你构建 3D 模型怎么样？

swyx (ведущий):坦白说甚至着色器代码(shader code)之类理论上都可实现确实超出专业领域但给予开发者支持与工具后他们能做到事情惊人正与 David Hersh 筹备一场「Claude 玩宝可梦」黑客马拉松本来并无将 MCP 融入计划现在看来或许可以考虑.