MCP Tasks vs synchronous tool calls: як виконувати довгі операції

Залишайте звичайний tools/call, коли операція вкладається у bounded request timeout, результат можна повернути одразу, а розрив з'єднання не вимагає окремого відновлення. Розглядайте MCP Task, коли робота триває довго, має пережити один request, потребує polling, deferred result, cancellation або проміжного input_required. У специфікації MCP 2025-11-25 Tasks входять до протоколу, але позначені experimental: це причина ізолювати функцію за capability gate, а не вважати її універсальним baseline.

Task не є чергою, workflow engine чи гарантією exactly-once. Він стандартизує видиму клієнту оболонку тривалої операції: receiver створює task ID, повідомляє стан, а requestor перевіряє status і забирає результат. Business operation усе одно потребує власного operation ID, authorization, idempotency, durable state та reconciliation із системою-власником. Якщо процес можна безпечно завершити за один короткий call, Task лише додає стани та cleanup.

• Коротке читання або bounded compute → звичайний tools/call.
• Тривала робота з deferred result → кандидат на Task.
• Потрібне додаткове рішення користувача → Task зі станом input_required.
• Наслідкова дія → domain operation ledger незалежно від protocol wrapper.
• Peer не оголосив capability → не надсилайте task augmentation.

Підтримка Tasks узгоджується під час initialization. Для task-augmented tool call server оголошує tasks.requests.tools.call; без цієї capability client не повинен запускати tool як Task. Далі конкретний tool уточнює execution.taskSupport: forbidden є default, optional дозволяє обидва режими, required вимагає Task. Перевіряйте обидва рівні на кожній сесії та не кешуйте висновок лише за назвою server або версією SDK.

Створіть capability manifest із protocol version, server implementation version, session evidence, task operations list/get/result/cancel і tool-level mode. Router порівнює manifest із вимогами workflow до першого виклику. Якщо потрібна функція відсутня, fallback має бути явним: короткий synchronous path, окремий job API, human handoff або контрольована відмова. Мовчазне перетворення required Task на довгий HTTP request створює іншу timeout і recovery semantics.

MCP Task починається у working і може перейти в input_required, completed, failed або cancelled за дозволеними переходами специфікації. taskId генерує receiver; TTL визначає, коли запис може бути видалений; pollInterval підказує частоту перевірки. requestor отримує фактичний результат через tasks/result лише після terminal completion. Збережіть last observed status, lastUpdatedAt, correlation ID і наступний дозволений poll, щоб reconnect не починав роботу заново.

Паралельно ведіть DomainOperation зі стабільним idempotency key, actor, tenant, object version, intended effect, downstream receipt і authoritative outcome. completed у Task означає, що protocol result готовий, але не доводить, що зовнішня система прийняла платіж, publish або deployment. cancelled також не гарантує компенсацію вже виконаного effect. UI показує окремо transport/task state і підтверджений domain outcome, а unknown outcome спрямовує на reconciliation до retry.

• Task state → що повідомляє receiver про виконання request.
• Domain state → що підтверджує system of record про бізнес-наслідок.
• Cancellation → запит зупинити подальшу роботу, не автоматичний rollback.
• TTL expiry → lifecycle protocol record, не право забути audit evidence.

Client поважає pollInterval, додає jitter, обмежує загальну тривалість і припиняє polling після terminal state. Частий poll не прискорює job, але збільшує навантаження та ризик rate limit. Progress notification може покращувати UX, проте не скидає абсолютний deadline безмежно. Після network loss client відновлює спостереження за відомим taskId, а не повторює originating tool call.

Визначте окремі бюджети для create, status reads, result retrieval і business reconciliation. Зберігайте лише мінімально необхідний response envelope: status, version, timestamps, sanitized message та evidence handles. Помилка tasks/get може означати expiry, authorization failure або server loss; вона не перетворює unknown domain outcome на failed. Для великих artifacts result краще повертати bounded metadata та авторизоване посилання, а не необмежений payload у model context.

Специфікація вимагає прив'язувати Tasks до authorization context, коли він доступний. tasks/get, list, result і cancel повторно перевіряють actor, tenant та дозволену operation; знання taskId саме по собі не є permission. Якщо peer не може ідентифікувати requestor, потрібні криптографічно непередбачувані IDs, коротший TTL і обмеження discovery; server без надійного context binding не повинен відкривати task listing.

Не записуйте token, sensitive elicitation data або повний downstream result у statusMessage чи logs. URL mode elicitation корисна для out-of-band credential або payment flow, але accept означає лише згоду перейти за URL, а не завершення зовнішньої дії. Для input_required фіксуйте requested field class, expiry і redaction rule; після зміни identity чи відкликання scope продовження Task проходить authorization заново.

Contract suite покриває initialize, відсутню capability, кожне значення taskSupport, create, get, list, result, cancel, invalid transition, expired TTL і pagination. Fault injection розриває transport до та після CreateTaskResult, між completed і result retrieval, під час input_required і після cancel request. Assertions перевіряють, що originating call не повторюється автоматично, status переходить лише дозволеним шляхом, а duplicate delivery не створює другий domain effect.

Security cases намагаються прочитати або скасувати Task іншого tenant, вгадати ID, отримати result після втрати scope, підмінити related-task metadata і вставити prompt injection у status чи result. Load test вимірює bounded concurrent jobs, polling amplification, cleanup і backpressure на downstream. Model-in-the-loop eval потрібен лише там, де модель вирішує запустити tool або інтерпретує result; protocol conformance і authorization лишаються deterministic gates.

• Hard gate → cross-tenant access, invalid transition, duplicate effect або secret leakage.
• Recovery gate → reconnect продовжує відомий Task без повторного start.
• Cancellation gate → terminal semantics і domain reconciliation перевірені окремо.
• Compatibility gate → fallback працює з peer без Tasks capability.

Почніть з одного read-only або reversible workflow, де Task дає вимірювану operational benefit: переживає request timeout, зменшує ручне відновлення або робить довгу операцію спостережуваною. Зафіксуйте protocol і SDK versions, capability manifest, allowed tools, max TTL, concurrency, status retention, owners та kill switch. Shadow mode може порівняти state projection із чинним job API, але не запускає бізнес-операцію двічі.

Canary просувають лише після contract, security, load і recovery gates. Rollback блокує нові task-augmented starts, залишає watcher для вже створених Tasks, reconcile-ить in-flight domain operations і повертає перевірений synchronous або job-API path. Retest запускають після зміни MCP specification, task experimental status, SDK, transition schema, authorization context, transport або downstream idempotency. Це локальний verdict для конкретної сумісності, а не твердження, що Tasks кращі для всіх MCP server.