عملیات طولانی در MCP چگونه مدیریت می‌شوند؟

همه Tool Callها در چند ثانیه تمام نمی‌شوند. Import هزاران رکورد، تولید گزارش سنگین، پردازش فایل یا Deploy ممکن است دقیقه‌ها زمان ببرد و در میانه به ورودی کاربر نیاز داشته باشد.

نگه‌داشتن یک HTTP Request برای مدت طولانی شکننده است. MCP Tasks Extension یک Task پایدار ایجاد می‌کند تا Client وضعیت را Poll کند و نتیجه را بعداً دریافت کند.

در زمان نگارش، سند جزئیات Tasks Extension با شناسه io.modelcontextprotocol/tasks در وضعیت Draft منتشر شده است؛ بنابراین قبل از Production باید نسخه Client و Server بررسی شود.

Task چه زمانی لازم است؟

• پردازش طولانی یا Batch
• Import و Export
• گزارش چندمنبعی سنگین
• Job بیرونی با API غیرهم‌زمان
• عملیاتی که ممکن است منتظر ورودی کاربر بماند
• کاری که باید پس از Restart قابل پیگیری باشد

تفاوت Task با MRTR

MRTR برای گرفتن ورودی در همان جریان منطقی Request است و Client Request اصلی را با پاسخ‌ها تکرار می‌کند. Task برای کاری است که State پایدار و نتیجه Deferred دارد. داخل Task نیز می‌توان input_required داشت.

Capability Negotiation

Client پشتیبانی Extension را در Capabilityهای هر Request اعلام می‌کند. Server فقط در این حالت اجازه دارد به‌جای نتیجه معمولی CreateTaskResult برگرداند. اعلام Capability به معنی اجبار Server به ساخت Task نیست.

ایجاد Task

Server برای tools/call می‌تواند نتیجه‌ای با resultType برابر task برگرداند. Task ID باید قبل از پاسخ به‌صورت پایدار ایجاد شده باشد تا tasks/get بلافاصله آن را پیدا کند.

{
  "resultType": "task",
  "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
  "status": "working",
  "createdAt": "2026-09-19T10:30:00Z",
  "lastUpdatedAt": "2026-09-19T10:30:00Z",
  "ttlMs": 3600000,
  "pollIntervalMs": 5000
}

وضعیت‌های Task

• working: کار در حال اجراست
• input_required: Server به ورودی Client نیاز دارد
• completed: نتیجه نهایی آماده است
• failed: اجرای Request با خطای JSON-RPC شکست خورده
• cancelled: Task لغو شده است

Polling با tasks/get

Client با Task ID وضعیت را می‌خواند و باید pollIntervalMs پیشنهادی را رعایت کند. Poll بیش‌ازحد می‌تواند Rate Limit شود. Task ID باید در Storage پایدار Client نگهداری شود تا بعد از Restart ادامه پیدا کند.

ورودی میان اجرای Task

در وضعیت input_required، Server درخواست‌های معوق را در inputRequests می‌فرستد. Client پاسخ‌ها را با tasks/update ارسال و دوباره وضعیت را دنبال می‌کند.

لغو با tasks/cancel

لغو Cooperative است. Server درخواست لغو را Ack می‌کند، اما ممکن است کار قبل از اعمال لغو تمام شود یا امکان توقف نداشته باشد. نتیجه Cancel قطعی نباید بدون مشاهده وضعیت فرض شود.

TTL

ttlMs مدت نگهداری Task را مشخص می‌کند. Client نباید نتیجه را برای همیشه قابل بازیابی فرض کند. Server می‌تواند پس از پایان TTL Task را Failed یا حذف کند.

Notification اختیاری

علاوه بر Polling، Server می‌تواند از notifications/tasks روی subscriptions/listen استفاده کند. Notification شیء کامل وضعیت را می‌فرستد، اما Client همچنان باید رفتار قطع ارتباط و Resume را طراحی کند.

Routing Header

برای tasks/get، tasks/update و tasks/cancel روی Streamable HTTP، Mcp-Name با Task ID تنظیم می‌شود تا لایه میانی بتواند Requestهای یک Task را به State درست Route کند.

طراحی Server

• Task را قبل از برگرداندن Handle پایدار کنید.
• Status Transitionها را اتمیک کنید.
• نتیجه و Error را محدود و قابل سریال‌سازی نگه دارید.
• Poll Interval و Rate Limit تعریف کنید.
• TTL و Cleanup Job داشته باشید.
• Cancellation Token را به Worker منتقل کنید.
• ورودی‌های تکراری tasks/update را Deduplicate کنید.
• Audit را با Task ID و Request ID پیوند دهید.

Idempotency

ایجاد Task و عملیات داخل آن باید Idempotent باشند. Retry یک tools/call نباید دو Job مالی یا دو Import بسازد. Idempotency Key باید از Task ID جدا و در لایه Business بررسی شود.

امنیت

• مالک Task باید در هر get/update/cancel بررسی شود.
• Task ID به‌تنهایی مجوز نیست.
• Result نباید داده خارج از Scope کاربر را نمایش دهد.
• input_required باید همان Trust Model درخواست مستقیم را داشته باشد.
• لغو یا Update باید Audit شود.
• Secret در statusMessage یا Result قرار نگیرد.

نمونه کاربرد در وصلک

Import محصولات، گزارش تطبیق چندماهه، پردازش فایل حسابداری یا عملیات طولانی سرور می‌توانند Task باشند. عملیات کوتاه مانند خواندن یک سفارش نباید بی‌دلیل به Task تبدیل شود.

تجربه کاربری مناسب

• وضعیت قابل فهم به کاربر نشان داده شود.
• درصد پیشرفت فقط در صورت داده واقعی نمایش داده شود.
• زمان تقریبی حدس‌زده‌شده با برچسب تخمینی باشد.
• دکمه Cancel انتظار واقع‌بینانه ایجاد کند.
• نتیجه نهایی و خطا قابل بازیابی باشد.

منابع رسمی

MCP Tasks Extension

MCP 2026-07-28 Specification Release

جمع‌بندی

Task یک Promise ساده در حافظه نیست؛ یک State Machine پایدار، مجاز و قابل بازیابی است.

برای عملیات طولانی باید Lifecycle، Ownership، Polling، TTL، Cancel، Input و Audit از ابتدا طراحی شوند. استفاده از Task فقط برای طولانی‌بودن زمان نیست؛ برای قابل اعتمادکردن اجرای Deferred است.