Год назад подключение внутренних систем компании к AI-ассистенту было научным проектом. Сегодня это тикет в Jira — Model Context Protocol превратил «подключи AI к нашей базе заказов» из кастомной интеграционной работы в то, что мидл-инженер может прототипировать за неделю. Если нужно объяснение самого протокола, разбор MCP закрывает эту тему.
Этот пост — другой разговор: тот, который я веду с CTO и платформенными лидами после того, как демо прототипа прошло хорошо. Потому что демо — лёгкая часть, а вопросы, которые следуют дальше («так можем мы это раскатить?»), — это вопросы архитектуры, безопасности и экономики в AI-костюме.
Что MCP на самом деле меняет для команды?
MCP стандартизирует сантехнику интеграции AI с системами, что смещает сложную работу с «как это подключить» на «что этому должно быть позволено делать». Один сервер, экспонирующий ваш трекер задач, работает в каждом MCP-совместимом клиенте, которым пользуется команда, — одна интеграция, написанная один раз. Это реальный рычаг: до стандарта каждая AI-поверхность требовала пересобирать каждую интеграцию.
Чего он не меняет: фактический контракт вашего внутреннего API, модель аутентификации и чувствительность данных проходят сквозь новую трубу без изменений. MCP-сервер — это слой представления над вашими системами для очень буквально мыслящего потребителя: если нижележащий API позволяет вызывающему читать заказы всех клиентов, MCP-сервер теперь предлагает эту возможность каждому разговору с AI. Протокол стандартизировал соединение, а не суждение.
Где должна проходить граница безопасности?
В самом MCP-сервере — и никогда не делегироваться хорошему поведению модели. Правило, которого я требую от команд: сервер обеспечивает ровно то, что может делать человек за сессией, используя ваш существующий auth (scoped-токены, права на уровне строк), так что даже полностью сбитая с толку модель не может запросить данные, к которым человек и так не имел доступа. «Модель обычно не запрашивает данные других клиентов» — это не позиция безопасности; «токен не может читать данные других клиентов» — вот она.
Три конкретных решения заслуживают проектного времени до раскатки. Разделение чтения и записи: read-only tools — иной класс риска, чем tools, мутирующие состояние, — начинайте с read-only, добавляйте записи tool за tool’ом с явными процессами одобрения. Реальность prompt injection: любой вывод tool, содержащий пользовательский контент (текст тикетов, письма, отзывы), может нести инструкции, которым модель может последовать, поэтому относитесь к выводам tools как к недоверенному вводу — ровно как в классической веб-безопасности. И логирование: каждый вызов tool, с аргументами, привязанный к сессии человека — потому что «что AI трогал в прошлый вторник» однажды спросит кто-то с комплаенс-должностью, и ответом не должно быть пожатие плечами.
Сколько на самом деле стоит раскатка MCP?
Сервер — дешёвая строка сметы; контрактная работа вокруг него — настоящий бюджет. Собрать первый read-only-сервер над хорошо задокументированным внутренним API — это действительно дни, а не месяцы: механику можно освоить в формате курса (создание MCP-серверов существует ровно для этого). Затраты, которые удивляют команды: проектирование tool-schema (описания настолько точные, чтобы модель выбирала правильный tool для правильной задачи, — плохие описания дают AI, уверенно ошибающийся насчёт ваших собственных систем), evals (тестовый набор, доказывающий, что tools используются правильно в реалистичных разговорах, а не просто возвращают 200) и постоянное владение — потому что у каждого изменения schema выше по течению теперь есть второй потребитель, которого можно сломать.
Стоимость самого рантайма следует экономике агентов: каждый результат tool попадает в контекстное окно модели и оплачивается, так что сервер, возвращающий 200 строк там, где хватило бы 5, тихо умножает ваш счёт за tokens. Формирование результата — фильтрация, суммаризация, пагинация внутри сервера — это решение одновременно про качество и про стоимость, и именно здесь дисциплина продакшен LLM-приложений окупает себя.
Строить своими силами или звать кого-то со стороны?
Стройте in-house, когда интеграция read-only, у нижележащего API есть ясный владелец, и у вас есть хотя бы один инженер, довозивший LLM-фичу до продакшена, — профиль, который знает, почему описания tools несущие и зачем нужен eval-набор. Знание накапливается: первый сервер учит команду паттернам, которые каждый следующий сервер переиспользует, и этим знанием стоит владеть, а не арендовать его.
Кейс за кейсом линия проходит примерно здесь:
| Ситуация | Строить in-house | Сначала звать ревью |
|---|---|---|
| Read-only-сервер над внутренним API с ясным владельцем | Да — дни работы, и команда оставляет паттерн себе | Не нужно |
| Ваш первый tool с возможностью записи | Рискованно в одиночку | Да — протестировать границы под давлением до того, как они станут продакшен-фактами |
| Регулируемые, клиентские или финансовые данные | Нет | Да — модель auth и защита от injection проревьюены до запуска |
| Проектирование tool-schema на большой поверхности | Выполнимо; ждите итераций | Полезно — расплывчатые описания дают AI, уверенно ошибающийся насчёт ваших систем |
| Eval-набор на корректное использование tools | Да, и владеть им долгосрочно | Опционально |
Зовите внешнее ревью, когда вовлечены записи, когда данные регулируемые или когда интеграция касается систем, чей отказ дорог, — не чтобы отдать сборку на аутсорс, а чтобы протестировать под давлением границы tools, модель auth и защиту от injection до того, как они станут продакшен-фактами. Именно такой формат «сначала дизайн-ревью» — наш консалтинг по AI-интеграции: второе мнение senior-уровня об архитектуре, пока её ещё дёшево менять, при этом сборка остаётся за вашей командой. Честная эвристика: демо заняло неделю, поэтому соблазн — поверить, что продакшен — это ещё две; команды, у которых это получается, закладывают разрыв «от демо до продакшена» как сам проект — тот самый разрыв, который призван закрыть context engineering.
Версия в один абзац для следующей встречи с руководством
MCP сделал соединение дешёвым. Он оставил безопасное, корректное, экономичное соединение ровно настолько же сложным, каким оно было всегда. Протокол теперь стандарт; суждение — всё ещё нет.
MCP сделал подключение AI к внутренним системам дешёвым; он оставил безопасное, корректное, экономичное подключение ровно настолько же сложным, каким оно было всегда, и перенёс эту сложность в дизайн tools, границы auth, evals и формирование результатов. Начинайте с read-only, обеспечивайте права в сервере учётными данными самого пользователя, относитесь к выводам tools как к недоверенным, логируйте всё и формируйте результаты так, будто tokens стоят денег — потому что они стоят. Первый сервер стройте in-house на низкорисковой системе; покупайте ревью до того, как выйдет первый пишущий или регулируемый. Протокол теперь стандарт. Суждение — всё ещё нет.
