Инженеры постоянно сталкиваются с трудностями при использовании кодовых агентов с незнакомыми API, процесс, отмеченный ручной сборкой контекста, которая быстро устаревает. Основная проблема заключается в использовании прозаической документации в качестве механизма передачи контрактов API, что приводит к таким проблемам, как устаревание, повторные затраты на токены и отсутствие принудительного исполнения. Прозаическая документация предоставляет снимок, который быстро устаревает, заставляет повторно загружать одну и ту же информацию в каждом разговоре и не может проверить вызовы до возникновения ошибок во время выполнения.Структурное решение включает предоставление агенту контракта API в виде вызываемых инструментов через сервер MCP (Microservice Contract Protocol), сгенерированных непосредственно из документа OpenAPI. Этот подход преобразует каждую операцию API в инструмент с определенной схемой ввода, обеспечивая структурированное обнаружение и предварительную проверку. В отличие от прозы, инструменты MCP позволяют агенту немедленно исправлять ошибки, централизуют аутентификацию и гарантируют, что контракт обновляется в одном месте для всех подключенных агентов. Потоковые операции также становятся доступными, поскольку инструмент обрабатывает открытие потока и сбор событий.Локальная разработка использует локальный сервер MCP поверх файла спецификации, в то время как общие среды могут использовать размещенную конечную точку MCP с закреплением версий и токенами для каждого пользователя, подчеркивая область действия токенов для минимального доступа. MCP действительно выигрывает в сценариях, связанных с повторяющейся интеграционной работой с внутренними API, средами с множеством мелких операций, доменами с жестким принудительным исполнением, такими как биллинг, и быстро меняющимися спецификациями. Однако это не универсальная замена повествовательной документации или высокопроизводительным SDK.MCP менее подходит для разовых исследований, критически важных по производительности или пакетных клиентов, а также для операций, явно не определенных в спецификации OpenAPI. Хорошо поддерживаемый документ OpenAPI имеет решающее значение, поскольку инструменты так же точны, как и сама спецификация. Идеальная настройка включает поддержание единого документа OpenAPI, из которого получаются три различных представления: отрендеренная документация для обучения людей, сгенерированные SDK для производственного кода и сервер MCP для интеграции агентов и исследований. Этот подход предотвращает избыточные описания между различными командами и инструментами.