Ваш тест на оформление заказа нажимает «Оформить заказ» и видит зелёный тост. Хорошо. Но вот чего он не проверяет: реально ли записалась строка? Правильно ли записались позиции заказа? Уменьшился ли инвентарь? 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:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@anthropic/mcp-playwright"]
    },
    "postgres": {
      "command": "npx",
      "args": [
        "@anthropic/mcp-postgres",
        "postgresql://readonly:****@localhost:5432/shop"
      ]
    }
  }
}

Два важных момента. Первый: подключение к базе данных использует 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:

browser_navigate({ url: "http://localhost:3000/products" })
browser_click({ selector: "text=Wireless Charger" })
browser_click({ selector: "button:has-text('Add to Cart')" })
browser_click({ selector: "a:has-text('Checkout')" })
browser_fill({ selector: "#name", value: "Ada Lovelace" })
browser_fill({ selector: "#email", value: "ada@test.dev" })
browser_click({ selector: "text=Credit Card" })
browser_click({ selector: "button:has-text('Place Order')" })
browser_snapshot()

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

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

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

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

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

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

list_tables()
→ orders, line_items, products, customers ...

describe_table({ table: "orders" })
→ id, customer_email, status, total, created_at ...

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

read_query({
  sql: "SELECT * FROM orders WHERE id = 10472"
})

read_query({
  sql: "SELECT * FROM line_items WHERE order_id = 10472"
})

read_query({
  sql: "SELECT name, stock FROM products
        WHERE name = 'Wireless Charger'"
})

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

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

Full-Stack Verification — Order #10472
───────────────────────────────────────
✓ строка orders существует
    customer_email: ada@test.dev
    status: confirmed
    total: $34.99
✓ строка line_items найдена
    product_name: Wireless Charger
    quantity: 1
    unit_price: $34.99
✓ products.stock уменьшен
    было: 48 → стало: 47
3/3 ассертов прошли

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

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

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

## Full-Stack Checkout Verification

Используй Playwright MCP-сервер:
1. Перейди на localhost:3000/products
2. Добавь «Wireless Charger» в корзину
3. Оформи заказ как «Ada Lovelace» (ada@test.dev),
   оплата — Credit Card
4. Захвати order ID со страницы подтверждения

Затем переключись на Postgres MCP-сервер и проверь:
- Строка заказа существует с правильным email
- Запись line_item для «Wireless Charger» (qty 1) присутствует
- Инвентарный остаток товара уменьшен на 1

Выведи результат pass/fail для каждого ассерта.

Это весь тест. Один промпт. Два 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-канал. Там мы публикуем полезные подборки от инженеров и делимся инсайтами.