Вы не представляете, как у меня горит с Playwright MCP

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

Но на самом деле эта проблема давно уже не проблема, и есть целых три варианта её решения:
1. Сделать скриншоты до и после. Подходит, чтобы показать модели, как должен выглядеть дизайн, какой-то визуальный баг или просто сказать «смотри сюда», чтобы долго и нудно не описывать, что конкретно модель должна увидеть.
2. Написать E2E-тест. Идеальный вариант, если нужно симулировать поведение в браузере, так как убивает двух зайцев одновременно: защищает от регрессии и позволяет автоматизированно, раз за разом проверять ваш сценарий без того, чтобы тратить контекст модели.
3. Дать доступ к браузеру. Это уже подключение тяжёлой артиллерии, и на самом деле зачастую этот подход совмещается с первым и/или вторым, чтобы дать браузеру ещё больше контекста. Также он может быть использован в отрыве от других подходов, чтобы, например, починить сломавшийся тест: гораздо проще дать модели понять, что сломалось самой, вместо того, чтобы объяснять ей что-то на пальцах.

И вот если с первыми двумя подходами проблем нет вообще, то последний, кроме как костыльным, назвать сложно.

У нас есть несколько вариантов, как мы можем научить модель общаться с браузером:
• Playwright MCP;
• MCP Chrome;
• Chrome DevTools MCP;
• Claude in Chrome MCP.

Если вы обратили внимание, то всё это MCP. Изначально сломанный протокол, который даже сами Anthropic (создатели MCP) признали таковым.

У MCP есть две фундаментальные проблемы:
1. Он всегда загружен в контекст, так что даже если вы его не вызываете, он будет занимать место в вашем контексте и ухудшать ответы;
2. Создатели MCP будто не знают о первой проблеме и добавляют десятки тулов в свои MCP, из-за чего многие MCP занимают 10-20% контекста, что безумно много.

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

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

И с другими инструментами из списка та же чехарда: они все работают примерно одинаково.

Меня вся эта ситуация так раздражала, что я уже собирался написать свой инструмент. Благо, я вовремя наткнулся на dev-browser. И, господи, мне даже смешно от того, насколько он просто и элегантно решает ту же самую проблему:
Во-первых, это скилл. А это значит, что в вашем контексте по умолчанию не будет жить слон, и вы сможете его вызывать тогда, когда сами посчитаете нужным;
Во-вторых, вместо того, чтобы на каждый чих иметь отдельный инструмент, dev-browser просто пишет Playwright-скрипты, которые тут же запускает в браузере. Это позволяет симулировать настоящее поведение пользователя, с чем Playwright MCP тоже очень сильно страдает, так как просто не успевает нажимать на всякие временные всплывающие окна или делать действия быстро, ведь он целую вечность раздумывает между действиями.

Так что, если вы используте Claude Code, Codex или Amp, рекомендую переехать на dev-browser — это топ!