«Машина может пересчитать все звёзды на небе, но не может понять, зачем человек смотрит на них».
— Айзек Азимов
В одну из пятниц у нас была обычная онлайн‑встреча. Еженедельный обмен знаниями, так сказать. Коллега решил показать что‑то «интересное про MCP» — и началось всё безобидно, с классического объяснения теоретической части. Но спустя час было очень тихо на звонке. Никто не перебивал, не шутил, не задавал вопросов, просто все слушали и пытались осознать происходящее. Тема оказалась куда глубже, чем мы ожидали, и, как выяснилось, напрямую касается того, чем мы занимаемся каждый день.
Если говорить проще, то классическое тестирование строится на предположении, что система ведёт себя предсказуемо: одинаковые входные данные — одинаковый результат. Но с искусственным интеллектом (AI) всё иначе. Здесь ответы могут быть разными, даже если вопрос тот же. Контекст живёт своей жизнью, а инфраструктура вокруг AI порой важнее самих моделей.
И вот тут на сцену выходит MCP — Model Context Protocol. Это стандарт, который позволяет AI‑агентам общаться с внешними инструментами. От того, насколько аккуратно и продуманно построен MCP‑сервер, зависит не только стабильность, но и тестируемость всей AI‑системы.
Что такое AI и зачем его тестировать?
Когда говорят «искусственный интеллект», многие представляют себе нечто магическое — но по сути это просто система, которая учится решать задачи, раньше доступные только человеку: анализировать, рассуждать, принимать решения.
Современный AI — это в основном большие языковые модели (LLM), которые умеют не только отвечать на вопросы, но и писать код, работать с данными, планировать действия.
С точки зрения QA это, конечно, кошмар и восторг одновременно.
Во‑первых, модель ведёт себя недетерминированно — один и тот же запрос может дать разные ответы. Во‑вторых, у неё нет привычных спецификаций: попробуй заранее описать, что считать «правильным ответом». И в‑третьих, важно не просто проверить, что она «что‑то делает», а убедиться, что не врёт, не галлюцинирует и не нарушает правила, особенно если это продакшен.
В итоге тестировать приходится не только саму модель, но и всё, что её окружает — API, пайплайны, контексты, протоколы взаимодействия. И здесь MCP становится буквально сердцем системы: без него модель не понимает, как общаться с остальным миром.
MCP и зачем он вообще нужен?
Model Context Protocol, или просто MCP — это стандарт, который описывает, как большие языковые модели (LLM) могут взаимодействовать с внешним миром через специальные MCP‑серверы. Если говорить совсем по‑простому, то: MCP‑сервер — это как «переводчик» между моделью и инструментами. Он публикует функции (их называют tools), например find_products, create_task, run_sql. А AI‑агент (то есть сама модель) может эти функции находить и вызывать. С помощью MCP модель не просто «болтает» — она начинает делать вещи: запускать процессы, получать данные, выполнять команды. Именно это делает современные AI‑системы похожими на настоящих «агентов», а не просто умные чаты. Но вот в чём загвоздка — чем сложнее MCP‑сервер, тем труднее его тестировать и тем выше риск, что модель «потеряется» в инструментах. Поэтому архитектура MCP — это не только про функциональность, но и про качество. От того, как спроектирован сервер, зависит, будет ли AI надёжным помощником или хаотичным экспериментом.
MCP как язык и универсальный мост между AI и QA
Когда мы говорим «протокол», воображение сразу рисует что‑то сухое и формальное. Но MCP — это не просто набор правил передачи данных. Это скорее язык общения между моделью и инструментами. Через MCP искусственный интеллект не просто вызывает функции — он «понимает», что умеет система, какие у неё есть возможности, и в каком контексте их можно применить. Каждый инструмент описан словами, понятными и человеку, и машине: что делает, какие параметры принимает, какой результат возвращает. Создание MCP‑сервера в этом смысле — это не кодинг в чистом виде, а дизайн коммуникации. Мы буквально учим модель разговаривать с софтом на понятном обоим языке.
Addy Osmani описывает это очень наглядно: в музыкальном приложении LLM через MCP может управлять треками — включать, останавливать, редактировать MIDI‑клипы. Перенеси эту идею в бизнес‑приложения — и получишь аналогию с QA‑инфраструктурой. Как пример, агент может создавать задачи, формировать отчёты, логировать шаги, работать с валютами или профилями клиентов.
Таким образом, MCP превращает хаотичные действия модели в набор понятных, контролируемых шагов, которые можно тестировать, документировать и развивать. Но, как и в любом языке, здесь легко перестараться. Если словарь становится слишком большим, смысл теряется. MCP с сотнями сгенерированных инструментов превращается в шум: агент не понимает, что выбрать, и начинает «тонуть» в собственном контексте. Поэтому в основе хорошего MCP лежит курирование — тщательно отобранный набор инструментов, кажд��й из которых реально нужен.
Меньше — значит лучше: меньше контекста → быстрее обработка; меньше двусмысленностей → стабильнее ответы; меньше инструментов → проще тестировать. Именно здесь появляется первая серьёзная проблема: соблазн использовать автоматическую генерацию MCP‑серверов.
Когда магия автогенерации оборачивается хаосом?
Как только MCP стал набирать популярность, появилось множество инструментов, обещающих «всё сделать за вас». Один из самых известных — FastMCP«s OpenAPI Converter. Он действительно умеет превратить любой REST API в MCP‑сервер буквально в одну строку кода. Звучит как магия, правда?
Вот только на практике всё оказалось не так волшебно. API, которые разрабатываются для людей, и API, с которыми работает агент, — это совершенно разные миры. Человеку удобно, когда есть десятки эндпоинтов, тонкие настройки, параметры и фильтры — всё под рукой. А для AI‑агента такое изобилие превращается в головоломку: каждый вызов — это не просто запрос, а целый reasoning‑цикл с тратой токенов и контекста.»
FastMCP решает задачу быстро, но зашивает в неё фундаментальную проблему: модель утопает в деталях. Она вынуждена читать описания сотен инструментов, выбирать между почти одинаковыми действиями (например, create_invoice, generate_invoice, get_invoice_details) и бесконечно «размышлять», какой именно вариант подойдёт. В итоге агент перестаёт быть полезным помощником и превращается в нерешительного библиотекаря, который тратит больше времени на выбор книги, чем на её чтение. ��оэтому подход «заверни всё и отправь модели» работает только для быстрых прототипов. Если говорить о продакшене, MCP нужно не генерировать, а курировать — вручную выбирать, переименовывать, упрощать и адаптировать инструменты под реальное поведение агента.
Таким образом, MCP требует другого подхода к проектированию API, чем мы привыкли. Чтобы увидеть это на практике, рассмотрим конкретный пример.
Neon MCP Server: красиво, удобно… и немножко страшно
После всех разговоров о теории MCP хотелось увидеть, как это выглядит вживую. И тут на горизонте появился Neon MCP Server — очень эффектный пример того, как протокол может работать на практике. Если коротко, это штука, которая позволяет управлять базой данных Postgres через естественный язык. Хочешь создать базу? Просто скажи.
Нужно выполнить SQL‑запрос? Тоже можно словами. Neon MCP выступает посредником между LLM и их API — и делает это почти магически.
То есть агент буквально может сказать: — «Создай новую базу и добавь туда таблицу клиентов.»
И всё произойдёт. Без ручного SQL, без REST‑запросов, без CLI. Удобно? Безумно. Безопасно? Не совсем. Потому что как только модель получает доступ к MCP‑серверу, она получает и реальную власть.
— «Удалить базу? Запросто.»
— «Переписать схему? Легко.»
И если вы не добавили уровни защиты, то даже дружелюбный AI может случайно сделать то, о чём потом пожалеет весь отдел.
Разработчики из Neon это прекрасно понимают, поэтому прямо в документации написано: «Используйте MCP‑сервер только для локальной разработки или тестов. В продакшене — категорически нет». Neon MCP поддерживает два режима: локальный (через npm и API‑ключ), и удалённый preview с авторизацией через OAuth. По сути, это идеальный инструмент, чтобы поиграться и понять, как MCP‑сервер работает под капотом. Но если вынести его наружу — то он превращается в отличный пример того, почему QA и безопасность тут не просто важны, а критичны.
Безопасность MCP: та самая часть, которую все откладывают “на потом”
После примера с Neon становится очевидно: MCP — штука мощная, но с ней нельзя шутить. Когда AI получает доступ к инструментам, он реально может что‑то сделать — не просто сгенерировать текст, а изменить данные, вызвать API, удалить таблицу. И если вы думаете: «Да ладно, что он там может натворить», — поверьте, натворить может много. Разработчики MCP это тоже поняли и добавили в спецификацию целый раздел под названием Security Best Practices. Там прямо говорится: MCP‑сервер — это фактически OAuth Resource Server. То есть он обязан защищать свои токены, авторизовывать клиентов и проверять, кто к нему стучится.
Среди ключевых мер:
использовать Resource Indicators (RFC 8707) — чтобы токен нельзя было применить не по адресу;
включать контекстно‑чувствительный доступ — решения об уровне прав должны зависеть от того, кто и зачем обращается;
и, конечно, ACL по умолчанию — никаких «все доступы всем», даже на тестовых средах.
Но этим всё не ограничивается. Исследователи уже описали целый зоопарк атак: Tool Squatting, Rug Pull, контекстные внедрения, подмена инструментов, цепочки вызовов.
В одном из обзоров (август 2025) даже нашли 31 тип атаки на MCP — и это только начало.
Чтобы противостоять этому, появились эксперименты вроде ETDI (Extended Tool Definition Integrity) — с криптографической проверкой инструментов и версионированием. А ещё — MCPSecBench, набор тестов, который позволяет проверить, насколько безопасен ваш MCP‑сервер и выдержит ли он атаки в духе «а что, если модель решит поиграть в администратора?». Всё это звучит серьёзно, но главный вывод простой: безопасность в MCP нельзя прикрутить потом. Она должна проектироваться сразу — на том же этапе, где вы решаете, какие инструменты вообще давать модели.
MCP Tools: меньше — лучше (и спокойнее для QA)
Если безопасность MCP — это про не дать модели случайно снести прод, то инструменты — это уже про здравый смысл. Каждый MCP‑сервер состоит из tools — это такие функции, с помощью которых AI что‑то делает: ищет, создаёт, обновляет, удаляет. В теории, чем их больше, тем мощнее система. На практике — чем их больше, тем больнее QA.
Спецификация MCP от 2025 года прямо говорит: «инструмент должен иметь понятное имя, описание и схему параметров.» Но тут есть подвох. Модель, конечно, может автоматически «обнаруживать» все эти инструменты, только чем их больше — тем больше токенов уходит на размышления, какой выбрать. Это как если бы вам дали 200 кнопок «Сохранить» — вы бы и сами зависли. Поэтому курирование MCP — это уже не пожелание, а часть тестируемости.
Хороший QA знает: чем проще названия инструментов, тем меньше ошибок. Чем меньше параметров, тем меньше вариантов всё сломать, а если инструмент не нужен — лучше его вообще не давать.
Тестировать MCP стоит не только на предмет «работает/не работает», но и на то, понятен ли он модели. Потому что если агент начнёт гадать между get_user_info и fetch_user_details, тесты быстро превратятся в сеанс экстрасенсорики.
В итоге роль QA тут меняется: мы проверяем не просто поведение, а понятность и предсказуемость интерфейса для модели. И это, пожалуй, новая ветка тестирования, которая только начинает формироваться — тестирование взаимодействия AI и инструментов.
Практика: как подружить QA и MCP
После всей этой теории возникает закономерный вопрос: а как всё это тестировать на практике? На первый взгляд, MCP выглядит как что‑то из области магии — куча инструментов, агент, reasoning, токены… Но если разобраться, тестирование здесь строится на тех же принципах, что и всегда: ясность, предсказуемость и здравый смысл.
Прежде всего стоит обратить внимание на несколько вещей. Инструменты должны быть понятными — с короткими и однозначными названиями, без дублей вроде find_products и search_products. Параметров должно быть ровно столько, сколько нужно модели для работы, лишнее только запутает. Безопасность важна даже на тестовых стендах — никакого «DELETE /everything» в списке инструментов. Эффективность сценариев тоже имеет значение: если для одного действия агент делает десять вызовов подряд, значит, где‑то что‑то не так. И, конечно, стабильность — повторный запуск должен давать тот же результат, а ошибки обязаны возвращаться корректно, без сюрпризов.
Давайте немножечко практики добавим.
Пример 1. Практически в каждом сервисе есть поиск. Проверка поиска:
Возьмём простой инструмент — find_products(keyword: str).
Если вызвать find_products("eco"), должны вернуться только товары с пометкой «eco». Повторный запуск должен дать тот же список — иначе где‑то нарушена идемпотентность. А если отправить пустую строку, сервер должен вернуть аккуратную ошибку, например 422 Unprocessable Entity, а не рухнуть. Этот пример хорошо показывает базовые принципы тестирования MCP: мы проверяем не только, что инструмент работает, но и насколько предсказуемо он себя ведёт, если его использовать неправильно.
Пример 2. Работа с задачами
Теперь чуть сложнее — инструменты create_task и list_tasks.
Создаём новую задачу: create_task("Написать отчёт") — сервер возвращает ID.
Проверяем list_tasks(), чтобы убедиться, что задача добавилась. Затем пробуем создать такую же задачу снова — ожидаем либо новую запись с другим ID, либо ошибку о дубликате, в зависимости от бизнес‑логики. Этот кейс показывает, как важно для MCP‑сервера сохранять согласованность состояния. Агент не видит внутренней логики — он доверяет тому, что инструменты действуют последовательно и не противоречат друг другу.
Пример 3. Работа с базой через Neon MCP Server
И, наконец, любимая часть — базы данных. С помощью Neon MCP Server можно сказать агенту:create_database("qa_test") — база создаётся.
Затем выполнить run_sql("SELECT 1") — получаем [1].
И напоследок намеренно вносим ошибку: run_sql("SELEC 1").
Если сервер отвечает понятным сообщением «syntax error», а не просто вываливается в 500 — тест можно считать успешным. Этот сценарий — пример проверки устойчивости и прозрачности ошибок. AI может ошибиться в синтаксисе, и MCP должен быть готов к этому, возвращая внятный ответ, а не ломая сессию.
Да, MCP можно тестировать вручную, но это быстро превращается в игру «найди баг с шестого раза». Поэтому лучше автоматизировать. Даже простенький клиент с базовыми тестами сильно упрощает жизнь — и спасает от сюрпризов после релиза.
def test_find_products(mcp_client):
resp = mcp_client.call("find_products", {"keyword": "eco"})
assert all("eco" in p["tags"] for p in resp["products"])
def test_task_creation(mcp_client):
task = mcp_client.call("create_task", {"title": "Написать отчёт"})
tasks = mcp_client.call("list_tasks", {})
assert task["id"] in [t["id"] for t in tasks]
def test_sql_error(mcp_client):
resp = mcp_client.call("run_sql", {"query": "SELEC 1"})
assert resp["status"] == "error"
assert "syntax" in resp["message"].lower()
Такие проверки можно добавить в CI/CD, и тогда каждый коммит будет проходить «контроль MCP». Это не избавит от всех проблем, но даст уверенность, что хотя бы базовые сценарии у агента под контролем.
Подведём итоги.
В заключении хочу сказать, что тестирование AI‑систем — это уже не просто «проверить, что кнопка нажимается и всё работает как в ТЗ». Теперь мы тестируем то, что само по себе может принимать решения, строить гипотезы и взаимодействовать с другими системами.
MCP — это как раз тот мост, который связывает модели с реальным миром. Он делает их не просто умными, а действенными. Но вместе с этим добавляет и новую ответственность: за предсказуемость, безопасность и чистоту контекста.
Для QA это новая территория. Здесь важно не только поймать баг, но и понять, как думает агент — какие инструменты он видит, как принимает решения и где может ошибиться. Пожалуй, впервые за долгое время мы тестируем не просто интерфейс, а взаимопонимание между человеком и машиной. И если MCP спроектирован грамотно — всё работает как слаженный диалог. Если нет — начинается хаос из бесконечных reasoning‑циклов, токенов и галлюцинаций. Так что, когда в следующий раз кто‑то скажет «ну это просто ещё один API», улыбнитесь и вспомните ту самую тишину после «Hello world». Потому что MCP — это уже не просто технологии. Это то, с чего начинается новая эра тестирования.
Источники и материалы, которые были полезны мне и, возможно, будут интересны и полезны вам:
Addy Osmani — MCP: What it is and why it matters
https://addyo.substack.com/p/mcp‑what‑it‑is‑and‑why‑it‑mattersFastMCP: OpenAPI Converter
(обсуждение автогенерации MCP‑серверов и её проблем)
https://github.com/modelcontextprotocol/fastmcpNeon Docs — MCP Server for Postgres
https://neon.com/docs/ai/neon‑mcp‑serverModel Context Protocol Specification:
— Security Best Practices (2025-06-18):
https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices
— Server Tools (2025-06-18):
https://modelcontextprotocol.io/specification/2025-06-18/server/toolsMCPSecBench — Benchmarking MCP Security
https://github.com/protectai/mcpsecbenchAcademic Research
Обзор угроз и атак на MCP (2025-08-18): arXiv
Исследования по Tool Squatting и Rug Pull атакам: arXiv