Pi.dev передумал и добавил поддержку MCP

Респект команде не только за то, что они изменили своё мнение, которого твёрдо придерживались, но и за то, что сделали это очень публично и не скрывали, что это разворот.

Ссылка на пост Армина — золото:

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

(https://lucumr.pocoo.org/2016/11/5/be-careful-about-what-you...)

И это из 2016 года! В наши дни, если вы спорите с позиции, которую заняли хотя бы неделю назад, вы уже можете быть не в синхроне.

Это было самое лёгкое решение, и многие, как и я, приняли его в марте[0] на фоне всей анти-MCP волны инфлюенсеров, объявлявших его мёртвым (многие-многие видные люди в техе, включая Garry Tan). Буквально каждый тех-инфлюенсер в каждой соцсети в марте называл MCP мёртвым и короновал CLI как победителя (полностью игнорируя все разумные аргументы о безопасности, наблюдаемости/телеметрии, простоте развёртывания и эксплуатации и т.д.)

Прямая цитата из марта 2026[1]:

> Если вас всё ещё не убедили, что большая часть этого дискурса [о смерти MCP] лишена нюансов и является просто хайпом, поздравляю с покупкой в текущий цикл FOMO от AI-инфлюенсеров; увидимся через 6 месяцев, когда инфлюенсеры перейдут к следующему откровению момента, чтобы оставаться релевантными и получать ваши просмотры и доллары.

Было довольно очевидно, зачем MCP понадобится, как только AI-инжиниринг и его внедрение выйдут за пределы соло-разработчика и стека с одной обвязкой "что работает для меня" против "что работает для моей команды", особенно в корпоративном контексте. Ключевая ошибка людей была в том, что они думали в терминах своих собственных рабочих процессов и своих локальных стеков, а не рабочего процесса команды и операционного стека команды. Также было незнание безсостоятельного HTTP-режима MCP (да, он уже существовал в марте; редакция спецификации от 2026-07-28 просто делает его приоритетным основным направлением на будущее) в противовес локальному `stdio`.

Моя самая большая претензия сейчас в том, что OpenAI всё ещё отказывается реализовывать спецификацию MCP Prompts[2] и в g […]

Я ценю их нежелание использовать MCP, но /что-то/ лучше, чем ничего.

Это неоптимально по причинам, которые излагает автор: но USB-C тоже. NVME тоже. HDMI тоже.

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

Вот почему MCP везде. Он может быть не производительным, не надёжным и не единообразным, но он СТАНЕТ лучше со временем.

И я гораздо предпочту широкую экосистему MCP, которая у нас есть сейчас, семи-восьми разным "оптимальным" способам подключить LLM к чему-то полезному.

Я чувствую то же самое насчёт необходимости поддержки суб-агентов, они кажутся мне довольно основополагающими.

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

Лично я немного запутался в том, что у Pi большая часть всего этого сделана плагинами, так как помню, каким бардаком был Eclipse, где многое было просто плохо подогнанными друг к другу плагинами, и просто выбрал OpenCode, поскольку он покрывает большинство моих потребностей из коробки. Полагаю, это также может быть признаком того, что я старею, потому что мои IDE и рабочие окружения тоже всё ближе к стоковым.

Нам нужно перестать называть компании в честь лора Властелина колец.

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

OpenAPI — это и есть "интеллектуальное обнаружение инструментов" (что бы это ни значило). OpenAPI буквально "возвращает структурированные данные" и "обнаруживается по их документации и описанию".

Хоть раз я хотел бы увидеть, как кто-то объясняет MCP в терминах, которые намекают, что он хоть немного понимает, о чём говорит.

Я использую mcporter[0] для потребления MCP, когда подходящие CLI недоступны. Он предоставляет MCP как shell-команды. Агенты компонуются, используя стандартные shell-примитивы. Инструмент возвращает json? Пайп в jq.

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

[0] https://mcporter.sh/

Я всё ещё не понимаю MCP? Что MCP может такого, чего не может skill + cli? Я использую hax (https://usehax.dev) и, честно говоря, совсем не скучаю по skills.

Я понятия не имел, что pi не поддерживает MCP! Я новый пользователь, только начал с ним возиться. Я настраивал свой инструментарий и попытался заставить работать один из моих MCP для базы данных (что, оглядываясь назад, показалось немного болезненным — но, полагаю, я исходил из предположения, что это моя ответственность — строить и поддерживать эти подключения).

Ещё одно замечание задним числом: "No MCP", похоже, была первой иконкой на их главной странице — не уверен, как я это пропустил.

Представьте моё удивление, когда я прочитал это!