Model Context Protocol, или просто MCP, появился только в ноябре 2024 года, но вокруг него уже успели устроить привычный для индустрии аттракцион: если есть новый протокол, значит старый стек пора списывать. Материал The New Stack про MCP и API возвращает разговор на землю: APIs никуда не делись, а MCP полезен не вместо них, а поверх них. Для русскоязычной IT-аудитории это важный сигнал: не нужно ломать работающие интеграции ради модного аббревиатурного сезона.
Как пишет The New Stack, главный тезис здесь довольно приземленный и потому ценный: появление MCP не означает, что компании должны выкинуть существующие API, SDK и интеграционные шины. Протокол решает другую задачу. Если API остается контрактом между системами, то MCP становится прослойкой, через которую LLM-приложения и AI-агенты получают доступ к инструментам, данным и действиям в стандартизированном виде. Проще говоря, API нужен машине, MCP нужен агенту, который должен этой машиной пользоваться без очередного слоя самодельного glue code.
В этом и состоит развилка, которую рынок пока не всегда формулирует аккуратно. Обычный API проектируют под предсказуемого клиента: фронтенд, мобильное приложение, другой сервис, интеграционного партнера. Там важны версионирование, SLA, контроль доступа, лимиты, наблюдаемость, обратная совместимость. MCP работает в другом сценарии: клиентом становится модель, которой нужно не просто вызвать endpoint, а понять, какие инструменты вообще доступны, какие параметры они ждут и в каком контексте их стоит использовать. Поэтому сравнивать MCP и API как взаимоисключающие альтернативы примерно так же продуктивно, как спорить, нужен ли базе данных SQL, если у вас уже есть ORM.
Для разработчиков это означает неприятную, но здоровую вещь: магии не будет. Если у компании плохой API, небрежная схема данных, хаотичные права доступа и три исторических сервиса, которые разговаривают друг с другом на диалектах боли, MCP это не вылечит. Он не заменяет архитектурную дисциплину, а только делает доступ к существующим возможностям удобнее для агентного слоя. Если же базовые интерфейсы уже приведены в порядок, MCP может резко сократить объем ручной интеграционной работы. Вместо того чтобы для каждого copilot-подобного клиента отдельно описывать набор функций, команда получает более единый способ подключать инструменты к моделям.
Контекст у этой дискуссии понятный. После бума AI-ассистентов рынок быстро дошел до следующего этапа: мало сгенерировать текст, нужно дать модели право что-то делать во внешнем мире. Отсюда взрывной интерес к tool calling, function calling, агентным сценариям и, затем, к MCP как попытке стандартизировать этот слой. Но когда стандарт появляется на волне хайпа, ему начинают приписывать лишнее. В итоге у части команд возникает ложный выбор: либо мы остаемся в мире API, либо срочно бежим в MCP. The New Stack как раз спорит с этой постановкой вопроса и предлагает более взрослый взгляд: сначала определите, кто ваш клиент и какой контракт вы ему обязаны поддерживать.
Для бизнеса разница тоже не академическая. Внешние API остаются способом монетизации, партнерской интеграции и безопасного доступа к функциям продукта. Через них строятся экосистемы, продаются платформенные возможности и контролируется стабильность. MCP в этом смысле не заменяет продуктовый интерфейс, а добавляет новый канал потребления тех же возможностей, но уже для AI-сценариев. Это может быть полезно внутренним командам, support-операциям, аналитикам, инженерам сопровождения и любым процессам, где агент должен быстро сходить в несколько систем, собрать контекст и выполнить действие. Но если компания решит, что MCP сам по себе избавляет от необходимости поддерживать нормальный API-слой, она просто получит вторую интеграционную поверхность вместо первой.
Есть и организационный эффект, который часто недооценивают. Когда команды начинают обсуждать MCP и API, разговор быстро переходит из плоскости «какой стандарт моднее» в плоскость ownership. Кто описывает инструменты для модели? Кто отвечает за права доступа? Кто валидирует, что агент не получил слишком широкие полномочия? Кто следит за тем, чтобы tool description не превратился в новый источник неявной бизнес-логики? В мире классических API на эти вопросы уже есть привычные ответы: platform team, security, SRE, product engineering. В мире MCP ответы еще только собираются. Поэтому внедрение протокола почти неизбежно подталкивает компании к пересборке процессов вокруг AI-доступа, а не только к добавлению нового transport layer.
Отсюда и практический вывод для CTO, платформенных команд и фаундеров: не надо противопоставлять одно другому. Если у вас есть зрелые API, MCP может стать удобным адаптером для агентных продуктов, внутренних copilots и автоматизированных workflow. Если зрелых API нет, начинать с MCP как с волшебной двери в AI-автоматизацию рискованно: слишком велика вероятность, что агент просто унаследует хаос, который раньше хотя бы был спрятан за интеграционной командой. Следующий этап рынка, похоже, будет не про замену API, а про то, какие компании сумеют превратить свои API в нормальный слой действий для моделей, не потеряв контроль, безопасность и внятную продуктовую логику.