Belajar MCP - MCP Tasks (Extension)

#Pendahuluan

Di episode 11 kalian melihat MCP Apps — tool yang mengembalikan UI resources interaktif yang dirender host di dalam sandboxed iframe. Sekarang giliran pasangannya yang naik status di versi yang sama: MCP Tasks. Masalah yang dijawabnya sederhana tapi mengganggu: bagaimana model menangani pekerjaan yang butuh waktu lama — deploy, migrasi database, render video — tanpa membuat satu request JSON-RPC menggantung selama menit-an?

Episode ini membedah perjalanan Tasks dari eksperimen di spec 2025-11-25 menjadi official extension di spec 2026-07-28, primitive tasks/get, tasks/update, tasks/cancel, siklus hidup task lengkap dengan state dan progress-nya, serta cara pola ini menyatu dengan agentic workflow yang kalian bangun.

#Dari Eksperimen ke Official Extension

Sebelum 2025-11-25 tidak ada cara standar untuk memodelkan pekerjaan panjang di MCP. Developer membuat polling sendiri-sendiri, atau menyalahgunakan stream SSE untuk menahan koneksi. Di spec 2025-11-25, Tasks pertama kali diusulkan sebagai fitur eksperimental — boleh dipelajari, belum boleh dijadikan fondasi produksi.

Perubahan besar terjadi di spec 2026-07-28: Tasks dipindah keluar dari dokumen core dan diresmikan sebagai official extension. Konsekuensinya penting untuk kalian pahami:

• Kontrak Tasks tidak lagi bagian dari inti protokol yang dijamin setiap server memahami.
• Server yang ingin memakai Tasks harus menyatakan dukungannya dan mengikuti dokumen extension secara eksplisit.
• Client harus mendeteksi dukungan itu dulu sebelum mengirim request task — ini membuat fitur tambahan tidak merusak interop.

Status sebagai extension juga berarti batas dukungan lebih tegas: host yang tidak mendukung Tasks cukup mengabaikan method-nya, dan server tetap bisa berfungsi normal untuk tool dan resources biasa.

#Primitive Tasks: get, update, cancel

Extension Tasks menambahkan tiga method JSON-RPC di sisi server. Kalian sudah terbiasa dengan pola tools/list dan resources/read dari episode 4 dan 5; Tasks mengikuti idiom yang sama:

• tasks/get — server mengambil snapshot status sebuah task berdasarkan ID. Dipakai client untuk polling atau mengecek hasil saat task selesai.
• tasks/update — dipanggil oleh server (sebagai notifikasi) untuk mengabarkan perubahan state atau progress task yang sedang berjalan.
• tasks/cancel — meminta server membatalkan task yang belum selesai. Bersifat best-effort: server yang sudah di tengah operasi yang tidak bisa dihentikan boleh menolak.

Request tasks/get terlihat seperti ini:

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tasks/get",
  "params": {
    "taskId": "task_7f3a91c2"
  }
}

Responsnya membawa status task: state saat ini, progress (berupa angka dan pesan yang bisa ditampilkan user), serta hasil jika sudah selesai. tasks/cancel mirip dengan tasks/get — hanya mengirim taskId — dan mengembalikan task yang dibatalkan beserta alasan pembatalannya.

#Siklus Hidup Task & Progress

Setiap task memiliki state yang berpindah sepanjang hidupnya. Alur yang umum:

created --> running --> completed
   |           |
   |           +--> failed
   +-----------+--> cancelled

• created — task baru diterima server, belum mulai dieksekusi.
• running — eksekusi berlangsung; server mengirim notifikasi tasks/update berkala.
• completed — hasil tersedia dan bisa diambil lewat tasks/get.
• failed — task gagal; pesan error menjelaskan penyebabnya.
• cancelled — dibatalkan, baik oleh client lewat tasks/cancel maupun oleh server sendiri.

Progress dikirim lewat notifikasi tasks/update dengan struktur ringan: taskId, state, progress (misalnya persentase), dan pesan singkat berbahasa manusia seperti "Membuat kluster di region ap-southeast-1". Host menampilkan ini kepada user sebagai indikator. Notifikasi adalah satu arah — client tidak perlu membalas — sehingga beban streaming di transport jauh lebih kecil dibanding pola konfirmasi berbalik arah.

#Integrasi dengan Agentic Workflow

Tasks adalah tempat alami bagi agent untuk meminta hal yang berjalan lama sambil tetap responsif. Bayangkan alur: user meminta "deploy aplikasi ke staging". Agent memanggil tool deploy, server langsung membuat task dan mengembalikan taskId, lalu agent bisa:

1. Mengirim tasks/get berkala atau menunggu notifikasi tasks/update terakhir.
2. Tetap menjawab pertanyaan user lain sambil task berjalan di latar.
3. Jika user berubah pikiran, memanggil tasks/cancel dan menyampaikan pembatalan.

Ini komplementer dengan MRTR dari episode 8: MRTR menangani percakapan balasan di tengah satu panggilan (misalnya konfirmasi user), sementara Tasks menangani pekerjaan panjang yang hidupnya jauh melampaui satu request. Kombinasinya memungkinkan alur interaktif yang tidak menggantung — kuncinya pada desain: task harus checkpointable (state tersimpan), idempotent (aman dipanggil ulang), dan cancellable (mau berhenti di titik aman).

#Implementasi Praktis dengan SDK

SDK resmi TypeScript (dan Python) telah mengekspos helper Tasks. Contoh server dengan extension Tasks sederhana:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
 
const server = new McpServer({ name: "deploy-server", version: "1.0.0" });
 
server.task("deploy", {
  description: "Deploy aplikasi ke environment tertentu"
}, async (params, { task }) => {
  task.update("Menyiapkan artefak", 10);
  await build(params.artifact);
  task.update("Upload ke registry", 55);
  await upload(params.artifact);
  task.update("Rolling deploy", 90);
  await rollingDeploy(params.env);
  return { message: "Deploy selesai" };
});

Klien memanggil tool deploy biasa; di balik layar SDK menciptakan task, memancarkan notifikasi tasks/update lewat hook task.update, dan mengembalikan hasil sebagai content. Yang kalian harus jaga: jangan menyimpan state task dalam memori proses saja — kalau server restart, task kehilangan riwayat. Simpan state di penyimpanan persisten bila task bisa hidup lebih lama dari satu proses.

#Penutup

Episode 12 memindahkan kalian dari dunia tools sinkron ke dunia pekerjaan berdurasi panjang. Kalian melihat Tasks beranjak dari eksperimen di spec 2025-11-25 menjadi official extension di 2026-07-28, mengenal primitive tasks/get, tasks/update, dan tasks/cancel, memahami state machine created sampai cancelled, serta bagaimana pola ini berdampingan dengan MRTR untuk membangun agentic workflow yang interaktif tanpa menggantung.

Inti yang harus dibawa pulang:

• Tasks kini official extension, bukan bagian core spec — server harus menyatakan dukungan, client harus mendeteksi dulu.
• Tiga method inti: tasks/get untuk mengambil status, tasks/update untuk notifikasi progress, tasks/cancel untuk pembatalan best-effort.
• Lifecycle task bergerak dari created menuju completed, failed, atau cancelled, dengan progress yang disiarkan lewat notifikasi satu arah.
• Tasks melengkapi MRTR: MRTR untuk percakapan di tengah panggilan, Tasks untuk pekerjaan panjang yang melampaui satu request.
• Jangan simpan state hanya di memori — task yang hidup lama butuh penyimpanan persisten agar tahan restart.

Episode 13 berikutnya kita turun ke level transport: Transport Deep Dive — membandingkan Streamable HTTP dengan stdio, kapan memilih masing-masing, dan bagaimana lifecycle proses berjalan. Sampai jumpa!