MCP sampling vs direct LLM API: як мігрувати після deprecation

Фінальний реліз MCP 2026-07-28 підтвердив deprecation Sampling. Release-candidate guidance, що передувала фіналу, рекомендувала для нової server-owned model dependency прямий provider API або внутрішній model gateway; тому тут це migration guidance, а не нова normative вимога final spec. Sampling не треба аварійно вимикати: формальна deprecation policy дає щонайменше дванадцятимісячне вікно до можливого removal, але нову довгострокову залежність на deprecated primitive будувати слабко.

Рішення не зводиться до заміни одного SDK call іншим. Sampling делегує model choice, credentials і consent host/client; direct API переносить їх до server-side оператора. Отже, перед міграцією зафіксуйте owner, data boundary, allowed models, budget, retention, eval і failure policy. Elicitation не є заміною sampling: вона просить людину надати або підтвердити дані через client, а не генерує model completion.

• Нова production-функція → direct provider API або governed model gateway.
• Чинний sampling flow → inventory, compatibility tests і поетапна міграція.
• Потрібні дані або вибір людини → elicitation чи звичайний conversational turn.
• Потрібен rich review UI → оцініть MCP App, не маскуйте його під model call.
• Client не оголосив capability → deterministic fallback або контрольована відмова.

У sampling server надсилає `sampling/createMessage`, а client виконує model request у межах capability, policy та user controls host. Server може запропонувати messages, model preferences і ліміти, але не повинен вважати конкретний model або контекст гарантованим. Це давало portability без server-held provider credentials, проте робило результат залежним від підтримки client і непрямої policy boundary.

У direct integration server або окремий model gateway володіє provider credential, model routing, retry, budget і telemetry. Це спрощує явний runtime contract, але розширює відповідальність оператора: tenant isolation, legal basis, data minimization, key rotation, provider outage і cost control тепер не можна перекласти на host. MCP tool authority і model authority все одно розділяйте: completion не отримує права виконати side effect лише тому, що його запросив server.

Фінальне оголошення MCP 2026-07-28 відносить Roots, Sampling і Logging до deprecated primitives та фіксує формальну deprecation policy з мінімальним дванадцятимісячним вікном до найранішого removal. Це дає час на керовану міграцію, але не обіцянку безстрокової підтримки кожним SDK або host.

Створіть compatibility matrix за фактичними client, SDK і protocol version. Стани `supported`, `deprecated-but-tested`, `unsupported` і `unknown` не взаємозамінні. Перевіряйте negotiation у runtime, а не визначайте підтримку за назвою продукту. Version pin без тесту не доводить, що multi-round-trip request коректно проходить proxy, load balancer і timeout budget.

Elicitation дозволяє server попросити client показати людині form або іншу підтримувану interaction. Запит має бути пов’язаний з активним client-initiated request; server не повинен створювати prompt з нізвідки. Client чітко показує requester, дає accept, decline і cancel, а server обробляє всі три стани без припущення, що згода гарантована.

Form mode не використовуйте для passwords, API keys, access tokens або payment credentials. У draft-специфікації для sensitive interaction описаний URL mode, але його availability треба negotiated і versioned, а draft не слід подавати як універсально розгорнуту stable capability. Для простого missing parameter elicitation достатня; для складного preview або multi-item review використовуйте MCP App із server-side повторною валідацією.

• Accept → validate schema, identity, freshness і domain constraints повторно.
• Decline → запропонувати безпечний альтернативний шлях без pressure loop.
• Cancel → завершити або зберегти resumable state без трактування як відмови.
• Sensitive secret → поза form elicitation і model context.
• Consequential action → окремий exact-action confirmation та authorization check.

Спочатку запишіть current contract: originating tool, input schema, messages, дозволений context, очікуваний artifact, latency і token ceiling, human review, critical failures та downstream consumers. Потім створіть provider-neutral ModelRequest envelope з task type, data classification, model policy, output schema, deadline, budget і trace ID. Provider adapter не має бачити MCP session більше, ніж потрібно для цієї операції.

Нормалізуйте відповідь у ModelResult із provider/model revision, usage, finish reason, schema verdict, safety verdict і provenance. Не передавайте raw completion одразу у write tool. Спершу перевірте schema та domain invariants, а consequence-bearing proposal звірте з актуальним system of record. Sampling і direct path мають тимчасово повертати однаковий artifact contract, щоб downstream логіка не роздвоїлася.

Зберіть очищений eval corpus із нормальними, boundary і adversarial cases. На однакових inputs порівняйте sampling baseline та direct candidate за schema validity, supported claims, task acceptance, prohibited output, reviewer corrections, latency і full cost per accepted artifact. Model або provider version фіксуйте в кожному run; один aggregate score не приховує critical failure slice.

Не надсилайте production secrets у shadow path і не виконуйте side effects двічі. Для stochastic задач робіть повтори, але рішення про rollout прив'язуйте до acceptance thresholds, а не до красивого demo. Trace пояснює trajectory, проте correctness засвідчують незалежні checks і domain outcome. Жоден локальний pilot не перетворюйте на vendor-independent claim про найкращу модель.

Direct path має визначені timeout, bounded retry, rate-limit handling, circuit breaker і budget exhaustion state. Timeout після model call не є side effect, але повтор може подвоїти витрати; використовуйте request identity та reconciliation, якщо provider це підтримує. Якщо output schema або policy check не проходить, система fail-closed для action і повертає пояснюваний terminal state або human review.

Cutover робіть через per-tool feature flag: shadow, canary, cohort rollout, default direct, потім removal sampling dependency. Rollback повертає лише перевірений sampling path для clients, що ще оголошують capability; інакше переводить задачу у deterministic fallback. Відкликання server provider keys, очищення queued requests і звірка незавершених proposals входять до runbook, а не залишаються ручною імпровізацією.

Для кожного workflow збережіть рішення: чому потрібен model call, чому deterministic logic недостатня, current sampling dependencies, chosen provider boundary, allowed data classes, human control, cost owner, compatibility deadline і rollback owner. Окремо зафіксуйте protocol/spec version та джерело deprecation, щоб команда не сперечалася з переказом документації.

Переглядайте record при новій MCP specification, SDK major release, зміні provider retention, model retirement, інциденті або перевищенні budget. Мета міграції — не просто прибрати deprecated method, а зробити authority та operating responsibility видимими. Якщо команда не готова володіти credentials, data governance і eval direct path, безпечний вибір — звузити функцію або залишити контрольований compatibility mode до готовності.