Я подключил 6 MCP-серверов к вайбкодингу — реально ускорили работу два

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

Он не видит вашу базу, не знает вашего дизайна, не читает ваши задачи в трекере — и уверенно выдумывает всё это за вас.

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

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

И вот здесь агент слепой. Он не может открыть вашу таблицу в базе, посмотреть макет в Figma или прочитать тикет. Он знает только то, что вы вручную скопировали в чат. Поэтому он додумывает: придумывает названия полей, берёт случайные отступы, чинит не тот баг.

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

MCP (Model Context Protocol) — открытый стандарт от Anthropic (modelcontextprotocol.io), «переходник» между агентом и внешним инструментом. Один раз подключаете сервер — например, к базе данных или к трекеру задач — и агент получает возможность сам туда сходить: прочитать структуру таблицы, забрать текст задачи, сделать запрос.

Каталоги готовых серверов, откуда я брал: github.com/modelcontextprotocol/servers (референсные), mcpservers.orgи реестр registry.modelcontextprotocol.io.

Важно понимать разницу:

Последний пункт я понял не сразу — и заплатил за это неделей тормозов.

Я не стал подключать «всё полезное». Взял единственную задачу, которая бесила сильнее всего: агент не знал структуру моей базы. Проект на Supabase, поэтому подключил официальный Supabase MCP(supabase.com/docs/guides/getting-started/mcp). Для чистого Postgres есть референсный сервер @modelcontextprotocol/server-postgres (репозиторий).

Подключение в Claude Code — одна команда:

claude mcp add supabase -- npx -y @supabase/mcp-server-supabase@latest --read-only

Агент сразу увидел реальные таблицы и перестал выдумывать названия колонок. Одна боль — один сервер.

Ошибка новичка здесь — подключить сразу десять серверов «на будущее». Работает обратное: один сервер под понятную задачу даёт предсказуемый результат, а пачка серверов превращает каждый ответ агента в лотерею.

Сервер к базе я подключил в режиме «только чтение» (флаг --read-only выше — он не случайный). Агент видит структуру и данные, но не может ничего изменить или удалить. Это не паранойя — это защита от того, что агент в процессе «починки» уронит вам продакшн-таблицу. Право на запись добавляется потом, точечно и осознанно.

Второй сервер, который реально изменил процесс, — Playwright MCP от Microsoft (github.com/microsoft/playwright-mcp). Альтернатива — Chrome DevTools MCP от команды Chrome (github.com/ChromeDevTools/chrome-devtools-mcp).

claude mcp add playwright -- npx -y @playwright/mcp@latest

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

Третьим я добавил официальный Figma Dev Mode MCP (help.figma.com — Dev Mode MCP Server). Он поднимается прямо в десктопном приложении Figma (Preferences → Enable Dev Mode MCP Server), агент цепляется к http://127.0.0.1:3845/mcp.

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

Дальше я по инерции подключил ещё три:

Через неделю честно признал: агент стал заметно медленнее, чаще выбирал не тот инструмент и уходил в сторону от задачи. Больше инструментов в контексте — больше шансов, что агент выберет не тот. Реальной пользы в вайбкодинге эти три не приносили. Я их отключил — и скорость вернулась.

Из шести серверов реально в плюс сыграли два:

Figma MCP — условный третий: помогает на старте экрана, но не закрывает вопрос точности. Linear, Gmail и Filesystem в контексте вайбкодинга оказались балластом.

Отдельно: если у проекта уже есть боевой прод, стоит посмотреть Sentry MCP (mcp.sentry.dev) — агент подтягивает реальные ошибки со стектрейсами. Мне на стадии сборки он был не нужен, но это следующий очевидный сервер.

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

Человек из цикла не ушёл. Но я подключаюсь не на каждой итерации, а только там, где нужно решение, а не проверка.

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

Если вы пробовали вайбкодинг и бросили на второй итерации — скорее всего, дело было не в агенте, а в том, что ему не хватало контекста. Напишите в комментариях, где именно у вас ломался процесс: на подключении базы, на дизайне или на отладке — разберу типовые случаи в следующем посте.

Проверь перед публикацией: ссылки на Supabase/Linear/Figma docs и точные npm-пакеты я привёл по актуальным на август 2026 данным — открой пару штук и убедись, что живые.