Тест на оформление заказа нажимает «Оформить заказ» и видит зелёный тост. Хорошо. Но проверяет ли он, что строка действительно записалась в базу? Правильно ли добавлены позиции? Уменьшился ли инвентарь? UI может показать «подтверждено», но на уровне данных — произошёл сбой: откат транзакции, ошибка в очереди, проглоченное исключение.

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

Сейчас есть лучший путь. И в нём вы не пишете ни строчки SQL.

Представьте AI-агента, который сначала управляет браузером, оформляя заказ, а затем переключается в базу данных, чтобы проверить, что данные записаны корректно. Всё это — через два MCP-сервера.

Идея проста: один MCP-сервер управляет Playwright для автоматизации браузера, второй — предоставляет безопасный read-only доступ к базе данных. Агент последовательно использует оба. Он завершает заказ, извлекает order ID со страницы подтверждения и проверяет данные в базе — всё по одному промпту.

Что понадобится

• Веб-приложение с флоу оформления заказа (любой стек — автоматизация на уровне браузера)
• PostgreSQL или MySQL с данными приложения
• MCP-клиент (например, Claude Desktop, Claude Code или другой совместимый)
• MCP-серверы: для Playwright и для базы данных

Шаг 1: Настройка MCP-серверов

Добавьте оба сервера в конфигурацию MCP-клиента. Например, в claude_desktop_config.json.

Два ключевых момента:

• Подключение к базе — только через read-only пользователя. Это обязательно: AI-агент не должен иметь права на запись.
• Для MySQL замените @anthropic/mcp-postgres на @anthropic/mcp-mysql. Интерфейс инструментов идентичен.

Шаг 2: Браузерная автоматизация

Передайте агенту промпт с описанием действий:

Перейди на localhost:3000/products. Добавь «Wireless Charger» в корзину. Перейди к оформлению заказа. Заполни имя покупателя «Ada Lovelace» и email «ada@test.dev». Выбери «Credit Card» как способ оплаты и нажми «Place Order». Дождись страницы подтверждения и захвати order ID.

Агент использует Playwright MCP для выполнения шагов: навигация, клики, заполнение форм, ожидание результата.

Он читает снапшот страницы и извлекает: Order #10472.

Никаких переменных, фикстур или ручного управления состоянием. Агент просто запоминает ID и использует его дальше.

Шаг 3: Проверка базы данных — без SQL

Теперь — самое интересное. Добавьте вторую часть промпта:

Теперь проверь базу данных. Подтверди, что заказ 10472 существует в таблице orders и принадлежит ada@test.dev. Проверь, что в таблице line_items есть запись для «Wireless Charger» с количеством 1. Также проверь, что инвентарный остаток товара был уменьшен.

Агент переключается на PostgreSQL MCP. Сначала он изучает схему — не предполагает названия столбцов:

• Вызывает list_tables, чтобы найти нужные таблицы.
• Использует describe_table, чтобы узнать структуру: названия столбцов, типы, связи.

Затем агент строит и выполняет запросы автоматически. Если столбец называется qty вместо quantity, или product_title вместо name — он адаптируется, потому что сначала прочитал схему.

Результат — три проверки, выполненные без единой строки SQL с вашей стороны.

Полный промпт

Всё можно описать одним запросом:

Оформи заказ на «Wireless Charger» для Ada Lovelace (ada@test.dev), затем проверь, что заказ 10472 есть в базе, позиция добавлена, а инвентарь уменьшен.

Это весь тест. Один промпт. Два MCP-сервера. Полное покрытие стека — от UI до данных.

Как сделать production-ready

• Используйте только read-only доступ. Активным должен быть только инструмент read_query. Это исключает риск случайной модификации данных.
• Добавьте тайминг-гарды. Если приложение использует очереди или eventual consistency, агент может не найти запись сразу. Укажите: «Жди появления строки до 5 секунд с опросом каждые 500 мс».
• Делайте снапшоты до и после. Попросите агента выгрузить данные таблиц до и после действия. Сравнение покажет побочные эффекты: дубли, пропущенные audit-поля, нарушения внешних ключей.
• Расширяйте за пределы SQL. Тот же паттерн работает с другими MCP-серверами: Redis — для проверки кеша, Elasticsearch — для индексации, S3 — для загрузки файлов. Добавляйте столько слоёв, сколько нужно.

Почему это важно

Традиционная full-stack верификация требует сложной инфраструктуры: драйверы, ORM, SQL-запросы, которые ломаются при рефакторинге схемы. Это не критично, но создаёт постоянную нагрузку на поддержку.

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

Это не магия. Это перенос адаптационного слоя из кода в контекст агента. Для задач чтения и верификации — такой трейдоф почти всегда оправдан.

Ваш тест на оформление заказа нажимает «Оформить заказ» и видит зелёный тост. Хорошо. Но вот чего он не проверяет: реально ли записалась строка? Правильно ли записались позиции заказа? Уменьшился ли инвентарь? UI написал «подтверждено», но UI иногда врёт — проглоченная ошибка, откаченная транзакция, очередь, которая молча дропнула сообщение.

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

Сейчас есть паттерн лучше. И в нём ноль SQL с вашей стороны.

Что если один AI-агент сможет делать обе половины — управлять браузером при оформлении заказа и затем переключиться в базу данных для проверки записи — используя два MCP-сервера?

Именно это разбирается в статье:

• Playwright MCPуправляет браузерной автоматизацией (навигация, клики, заполнение форм, снапшоты).
• PostgreSQL MCPуправляет интроспекцией базы данных и read-only запросами.

Агент последовательно их использует. Завершает оформление заказа, получает order ID со страницы подтверждения, затем переключает контекст и использует инструменты базы данных для верификации. Весь сценарий описывается на обычном языке.

Что понадобится

• Работающее веб-приложение с флоу оформления заказа (любой стек — это работа на уровне браузера)
• PostgreSQL или MySQL с данными приложения
• MCP-клиент (Claude Desktop, Claude Code или любой MCP-совместимый клиент)
• Пакеты MCP-серверов для Playwright и базы данных

Шаг 1: Настройка двух MCP-серверов

Добавьте оба сервера в конфигурацию MCP-клиента. Вот как выглядитclaude_desktop_config.json:

Два важных момента. Первый: подключение к базе данных использует read-only пользователя. Это принципиально — вы даёте AI-агенту доступ к базе, поэтому он должен только читать, никогда не писать. Второй: если у вас MySQL, а не PostgreSQL, просто замените@anthropic/mcp-postgresна@anthropic/mcp-mysql. Интерфейс инструментов идентичен.

Шаг 2: Браузерная часть

Теперь вы даёте агенту промпт с описанием UI-флоу:

Перейди на localhost:3000/products. Добавь «Wireless Charger» в корзину. Перейди к оформлению заказа. Заполни имя покупателя «Ada Lovelace» и email «ada@test.dev». Выбери «Credit Card» как способ оплаты и нажми «Place Order». Дождись страницы подтверждения и захвати order ID.

Под капотом агент переводит это в последовательность вызовов Playwright MCP:

Агент читает снапшот страницы подтверждения и извлекает: Order #10472.

Никаких переменных, никаких тестовых фикстур. Агент просто запоминает order ID в своём контексте и несёт его дальше.

Шаг 3: Верификация базы данных — ноль SQL

Вот где становится интересно. Продолжаете тот же промпт (или добавляете вторую инструкцию):

Теперь проверь базу данных. Подтверди, что заказ 10472 существует в таблице orders и принадлежитada@test.dev. Проверь, что в таблице line_items есть запись для «Wireless Charger» с количеством 1. Также проверь, что инвентарный остаток товара был уменьшен.

Агент переключается на PostgreSQL MCP-сервер. Первым делом он изучает схему — не предполагает названия столбцов заранее:

Затем строит и выполняет запросы для верификации:

Эти запросы вы не писали. Агент составил их, изучив схемы таблиц черезlist_tablesиdescribe_table, а затем построил SQL на лету. Если у вас столбец называетсяqtyвместоquantityилиproduct_titleвместоname— агент адаптируется, потому что сначала прочитал схему.

Затем агент возвращает что-то вроде:

Три проверки, ноль строк SQL с вашей стороны.

Полный промпт

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

Это весь тест. Один промпт. Два MCP-сервера. Полное покрытие стека.

Как сделать это production-ready

Несколько паттернов, которые помогают при выходе за пределы демо.

Всегда используйте read-only учётные данные.Инструментread_queryдолжен быть единственным активным инструментом базы данных. Это защищает от случайной мутации данных во время верификации.

Добавьте тайминг-гарды для асинхронных записей.Если приложение использует очереди, event sourcing или eventual consistency, строка может ещё не существовать в момент запроса агента. Напишите: «Жди появления строки заказа до 5 секунд, опрашивая каждые 500 мс». Агент будет повторять запрос до разрешения или таймаута.

Делайте снапшоты до и после.Для регрессионного тестирования попросите агента запросить нужные таблицы до UI-действия и после, затем сравнить результаты. Это ловит непредвиденные побочные эффекты: дублирующие записи, пропущенные audit-столбцы, нарушения foreign key, которые были проглочены.

Расширяйте за пределы SQL.Тот же двухфазный паттерн работает с любым backend MCP-сервером. Redis MCP — для проверки инвалидации кеша. Elasticsearch MCP — для подтверждения индексации документа. S3 MCP — для проверки, что файл действительно загрузился. Добавляйте столько слоёв верификации, сколько нужно.

Почему это важно

Традиционный подход к full-stack верификации тестов требует поддержки параллельной тестовой инфраструктуры: драйверы баз данных, пулы соединений, конфигурации ORM, SQL-строки, которые ломаются при переименовании столбца. Это не тяжёлая работа, но постоянная — и она существует в странном нейтральной полосе между тестовым набором и кодом приложения.

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

Это не магия. Это просто перенос адаптационного слоя из вашего кода в контекст агента. Для задач верификации, где нужно читать, а не писать — этот трейдоф почти всегда оправдан.

Подписывайтесь на нашTelegram-канал.Там мы публикуем полезные подборки от инженеров и делимся инсайтами.