MCP чи REST API: що обрати для AI-інтеграції

REST API доцільний, коли застосунки або сервіси мають викликати стабільні domain operations через явні HTTP endpoints. MCP доцільний, коли AI-host має виявляти й використовувати agent-facing tools, resources і prompts через спільний протокол. MCP не замінює бізнес-API автоматично: production MCP server часто є тонким policy-aware adapter над уже наявними REST, gRPC, database або queue interfaces.

Починайте з consumer і control contract. Якщо consumer — відомий application client, а sequence визначає ваш код, залишайте REST/OpenAPI baseline. Якщо consumer — кілька сумісних AI hosts, яким потрібні discovery, machine-readable tool schemas і протокольні semantics, додайте MCP. Не створюйте MCP лише для того, щоб перейменувати один POST endpoint на tool: додатковий protocol surface виправданий переносимістю між hosts, кращим capability catalog або керованою agent interaction model.

OpenAPI Specification описує HTTP API: servers, paths, operations, parameters, request bodies, responses, callbacks, webhooks, reusable schemas і security requirements. Це сильний контракт для code generation, documentation, gateway policy та integration tests. Він не визначає, коли мовна модель повинна побачити operation, як AI-host формує context або як user-controlled prompt і application-controlled resource співіснують із model-controlled tool.

MCP задає client-host-server interaction model і семантичні primitives. Tools дають моделі дозволені actions, resources — application-controlled context, prompts — user-invoked templates. У версії 2026-07-28 core став stateless request/response, а method і tool name можуть передаватися в HTTP headers для routing та policy enforcement; cache hints підтримують каталог capabilities. Це все ще не визначає ваші domain invariants, transaction boundaries чи authoritative record — їх зберігає underlying service.

• REST/OpenAPI: domain endpoints, HTTP semantics, responses і application clients.
• MCP: agent-facing discovery, context primitives та сумісність AI hosts.
• Domain service: остаточні permissions, invariants, transactions і system of record.
• Adapter: перекладає вузькі MCP contracts у дозволені domain operations без розширення authority.

Обирайте REST API як єдиний public surface для mobile/web backend, service-to-service integration, partner API, deterministic batch job або webhook producer. У цих сценаріях callers відомі, operations версіонуються як domain contract, а standard HTTP tooling уже покриває gateway, caching, quotas і observability. LLM може викликати такий API через application-owned function tool без окремого MCP server, якщо інтеграція живе в одному продукті.

Додавайте MCP, коли один capability provider має працювати з кількома MCP-compatible hosts; catalog tools/resources повинен бути discoverable; host керує consent і context; або вам потрібна стандартна agent-facing boundary замість vendor-specific tool wrapper. Обирайте обидва, коли enterprise API лишається canonical backend, а MCP adapter публікує невеликий task-oriented subset. Не обирайте жоден як orchestration engine: retries, approvals, durable workflow і compensation можуть потребувати application workflow runtime.

• Один контрольований AI application і кілька functions → спочатку direct API tool wrapper.
• Кілька сумісних AI hosts і спільний capability catalog → перевірте MCP adapter.
• External developers або service clients → REST/OpenAPI лишається основним контрактом.
• Long-running business process → окремо визначте workflow state; протокол сам його не надає.
• Наслідкові writes → однакові policy, approval та reconciliation controls для обох surfaces.

Розмістіть business rules у domain service, а не в MCP handler. Tool `create_refund_request` приймає task-oriented schema, перевіряє actor і tenant, викликає вузьку API operation та повертає structured status із evidence reference. Він не повинен копіювати refund eligibility, самостійно формувати privileged downstream token або перетворювати model text на довільний URL. Така межа дозволяє REST clients і MCP hosts отримувати однакові invariants та audit outcome.

Не генеруйте production MCP tools механічно з усього OpenAPI document. API може містити admin, bulk, debug і low-level CRUD operations, непридатні для model-led selection. Побудуйте allowlist task contracts, зменште argument space, додайте descriptions із preconditions, позначте read/write risk і повертайте мінімальний result. Version MCP adapter і API окремо; compatibility test має довести, що кожен tool усе ще мапиться на дозволену backend operation.

OpenAPI може задекларувати API key, HTTP, OAuth 2 або OpenID Connect schemes та required scopes для operations. Remote MCP має власний authorization profile: protected resource metadata, authorization-server discovery, resource indicators і audience-bound access tokens. Поточна MCP специфікація також забороняє token passthrough до upstream API. MCP server, який викликає backend, є окремим OAuth client або workload identity й отримує окремий downstream credential.

Identity propagation робіть явною: authenticated user/service, tenant, requested action, approved scopes, risk tier, expiry та delegation chain. MCP tool description не є policy, а підтвердження моделі не є consent. Перед side effect adapter повторно авторизує конкретний resource/action, для high-impact action показує людині точний diff, використовує idempotency key та після call читає authoritative postcondition. Ці controls потрібні й direct API tool wrapper, і MCP integration.

MCP tool catalog полегшує discovery, але велика кількість схожих tools погіршує selection і збільшує prompt surface. OpenAPI schema також може бути syntactically valid, але надто низькорівневою для агента. Хороший agent-facing contract має distinct intent, коротку назву, bounded arguments, enums замість free text там, де це можливо, explicit error taxonomy і результат, який можна перевірити без читання prose.

Проводьте eval на representative tasks: correct-tool selection, argument validity, prohibited-action rate, unnecessary-call rate, recovery after 401/403/409/429, prompt-injection resistance та verified task outcome. Окремо тестуйте catalog changes: перейменований tool, нове required field, stale cached list і несумісний host. Якщо direct wrapper дає однакову якість при меншій operational complexity, MCP не створює достатньої information gain для цього продукту.

Пов’язуйте host request, MCP method/tool, adapter decision і downstream API call одним correlation/trace context. Лог має містити protocol та adapter version, actor/tenant pseudonymous ID, policy verdict, tool schema version, backend operation, latency, retry, terminal status і verified outcome. Не записуйте access tokens, raw secrets або повні prompts за замовчуванням. Метрики catalog discovery та tool call не замінюють business success.

Adapter додає latency, deployment, compatibility і incident surface. Бюджет включає host/client variance, MCP SDK upgrades, API quotas, schema tests, authorization operations, redaction і on-call ownership. Для read-heavy resources використовуйте дозволені cache hints із tenant-aware scope; для writes — idempotency і reconciliation. Rollback вимикає MCP capability через registry/feature flag, зупиняє нові calls, звіряє in-flight side effects і залишає canonical REST API працездатним.

Оберіть один read tool і один reversible або approval-gated write. Зафіксуйте однаковий task contract, test corpus і backend API. Реалізуйте direct function wrapper baseline та MCP adapter, після чого запустіть їх через потрібні hosts. Перевірте discovery, schema adherence, auth із правильним і неправильним audience, expired consent, timeout після backend commit, duplicated request, malicious resource content і incompatible catalog change.

Рішення приймайте за verified task success, prohibited-action rate, integration effort, p95 time-to-outcome, recovery success, operator burden і cost per accepted outcome — без вигаданого універсального порогу. Rollout: offline replay, read-only shadow, canary, bounded writes. Якщо portability або catalog governance не дають виміряного виграшу, залиште direct API wrapper; якщо дають — розширюйте allowlist по одному intent, не експонуючи весь backend.

• Визначити consumer, task, authority і authoritative outcome.
• Зберегти domain API єдиним власником invariants.
• Порівняти direct wrapper і мінімальний MCP adapter на однакових tasks.
• Інжектувати auth, timeout, duplicate і schema-version failures.
• Задокументувати capability flag, reconciliation та rollback owner.