Arsitektur MCP Tanpa Status untuk Alur Kerja Agen Ponsel Android
Playbook arsitektur MCP 2026-07-28: server MCP tanpa status, aplikasi agent tetap stateful, dan cara FoneClaw menjaga status tugas Android, approval, retry, serta recovery.
- MCP 2026-07-28 memindahkan inti protokol ke model stateless: request membawa metadata yang cukup, dapat dirutekan ke instance server yang kompatibel, dan tidak bergantung pada handshake sesi wajib.
- Stateless di transport tidak menghapus state aplikasi; phone agent tetap perlu menyimpan conversation state, task state, device state, approval state, auth state, dan audit state di host yang tepat.
- MCP Tasks, MRTR, elicitation, dan explicit state handles membantu pekerjaan panjang, tetapi approval pengguna, izin Android, idempotency, dan verifikasi hasil tetap menjadi tanggung jawab aplikasi agent.
- Dari pengalaman membangun FoneClaw, workflow Android yang andal membutuhkan stateful host layer: tugas tetap terlihat, izin dapat dipulihkan, retry dibedakan, dan hasil tindakan diverifikasi setelah eksekusi.
Apa yang berubah di MCP 2026-07-28
Perubahan utama MCP 2026-07-28 adalah pemisahan yang lebih jelas antara protokol yang stateless dan aplikasi agent yang tetap stateful. Dalam rilis spesifikasi MCP 2026-07-28, inti protokol bergerak ke request yang self-describing, header routing, daftar yang dapat di-cache, MRTR, penguatan otorisasi, serta extension framework. Tasks juga hadir sebagai extension formal untuk pekerjaan yang berjalan lebih lama.
Makna praktisnya: server MCP dapat dirancang tanpa mengandalkan sesi transport tersembunyi. Request membawa metadata yang diperlukan agar instance server yang kompatibel dapat memprosesnya. SEP-2575 tentang MCP stateless menjelaskan penghapusan mandatory initialization handshake dalam model stateless-first dan mengganti asumsi yang sebelumnya dinegosiasikan melalui sesi dengan metadata per request.
Dari sisi FoneClaw, pelajaran arsitekturnya langsung terasa. Phone agent Android perlu dapat pulih ketika layar berubah, izin belum siap, pengguna berpindah dari Home ke floating assistant, atau suatu tool harus dicoba ulang. Transport yang stateless membantu deployment server lebih fleksibel, tetapi state tugas ponsel harus dimiliki oleh host agent yang memahami perangkat, izin, approval, dan hasil. Untuk konteks trust discovery dan verifikasi sumber kemampuan, Agentic Resource Discovery: ai-catalog.json, Verifikasi, dan Batas Otorisasi Phone Agent membahas lapisan penemuan resource yang berdampingan dengan keputusan eksekusi.
Cara siklus request MCP stateless bekerja
Dalam siklus MCP stateless, setiap request perlu membawa identitas, kapabilitas, versi, dan metadata yang cukup untuk diproses. Server dapat ditemukan melalui mekanisme discovery, daftar kemampuan dapat di-cache, dan routing dapat memakai header sehingga load balancer atau serverless runtime dapat mengirim request ke instance yang tersedia. Ini memperbaiki operasional: restart server, scale-out, dan round-robin menjadi lebih mudah.
Bagian pentingnya adalah explicit state reference. SEP-2567 tentang sessionless MCP melalui explicit state handles menjelaskan bagaimana state yang sebelumnya tersimpan implisit di sesi protokol dapat diganti dengan handle yang dibuat server dan diteruskan pada call berikutnya. Handle seperti ini membantu request selanjutnya merujuk pekerjaan yang sama tanpa memulihkan sesi transport tersembunyi.
Namun fitur nyata jarang selesai dalam satu request. Phone agent mungkin perlu membaca konteks, menanyakan klarifikasi, meminta approval, menjalankan tindakan Android, lalu memverifikasi hasil. Siklus request stateless membuat transport bersih, sementara aplikasi tetap merangkai state melalui task id, approval record, idempotency key, dan audit trail. Dengan kata lain, server MCP tanpa status mempermudah infrastruktur; AI agent stateful tetap dibutuhkan agar tugas ponsel memiliki memori kerja yang benar.
Ketika kami merancang alur FoneClaw, kami memisahkan “request dapat diproses ulang” dari “tindakan boleh diulang”. Membaca status perangkat bisa diulang. Mengirim SMS atau mengubah pengaturan membutuhkan idempotency, approval, dan verifikasi hasil. Pemisahan ini menjadi dasar seluruh playbook.
Enam jenis state yang perlu dimiliki phone agent
Phone agent yang andal membutuhkan peta kepemilikan state. Pengalaman kami membangun FoneClaw menunjukkan bahwa state yang salah tempat membuat retry berbahaya, approval membingungkan, dan recovery terasa seperti mulai dari nol. MCP stateless memberi jalur transport yang ringan; host phone agent menyimpan state aplikasi yang diperlukan.
| Jenis state | Pemilik yang tepat | Contoh dalam workflow Android |
|---|---|---|
| Conversation state | Host agen atau lapisan orkestrasi model | Niat pengguna, klarifikasi terakhir, bahasa, dan preferensi jawaban. |
| Task state | Phone-agent host | Status berjalan, menunggu approval, selesai, gagal, atau siap dipulihkan. |
| Device state | Perangkat Android, dibaca ulang saat dibutuhkan | Aplikasi aktif, layar saat ini, status DND, pilihan SIM, izin, dan kontrol UI. |
| Approval state | Host yang menampilkan keputusan pengguna | Persetujuan untuk mengirim SMS tertentu, mengubah setting tertentu, atau menjalankan action berdampak. |
| Auth state | Sistem identitas dan permission boundary | Akun, token, role, Android permission, dan akses layanan. |
| Audit dan recovery state | Host agent dengan catatan hasil | Idempotency key, correlation id, hasil eksekusi, retry, kompensasi, dan langkah pemulihan. |
Approval dan auth perlu dipisahkan. Auth menjawab apakah suatu principal memiliki akses. Approval menjawab apakah pengguna menyetujui tindakan tertentu pada konteks tertentu. Task handle juga memiliki peran sendiri: ia membantu merujuk pekerjaan, tetapi approval dan permission tetap membutuhkan record terpisah.
Untuk desain identitas, izin, dan audit yang lebih dalam, Identitas Agen AI: Izin, Persetujuan per Alat, dan Jejak Audit Phone Agent memberi kerangka yang melengkapi peta enam ledger ini. Dalam FoneClaw, prinsipnya sama: state yang menyentuh keputusan pengguna harus tetap terlihat, dapat diperiksa, dan dapat dipulihkan.
MCP Tasks, MRTR, elicitation, dan persetujuan
MCP 2026-07-28 membawa elemen yang berguna untuk aplikasi agent. MRTR membantu model meminta tool secara lebih terstruktur. Elicitation membantu sistem meminta input tambahan dari pengguna. Tasks memberi extension formal untuk pekerjaan yang berjalan lebih lama. Semua ini cocok dengan dunia phone agent, karena tugas Android sering melibatkan klarifikasi, izin, dan hasil bertahap.
Contoh sederhana: pengguna meminta “siapkan SMS ke Rina bahwa saya terlambat sepuluh menit.” Model dapat meminta tool untuk menyiapkan draf. Jika ada dua kontak Rina, elicitation meminta pengguna memilih. Jika proses menunggu konfirmasi atau aplikasi perlu dibuka, Tasks dapat memberi handle untuk merujuk pekerjaan yang sama. Setelah pengguna memberi approval, host menjalankan tindakan yang didukung dan mencatat hasil.
Yang membuat desain ini aman adalah pemisahan peran. Task handle membantu melacak pekerjaan. Approval record menyimpan keputusan pengguna untuk tindakan tertentu. Auth state menyimpan hak akses dan izin. Device state dibaca ulang sebelum eksekusi karena Android dapat berubah setelah approval dibuat: layar berpindah, aplikasi tertutup, SIM prompt muncul, atau izin dicabut.
Dalam FoneClaw, kami memakai prinsip reviewable action: tindakan berdampak membutuhkan target, alasan singkat, dan hasil yang terlihat. Saat workflow mengandalkan Tasks atau handle eksplisit di masa depan, prinsip yang sama tetap berlaku. Handle merujuk tugas; approval memberi keputusan; verification membuktikan hasil.
Workflow Android stateful di atas MCP stateless
Bayangkan arsitektur konektor stateless untuk workflow Do Not Disturb atau SMS. Pengguna memulai dari FoneClaw floating assistant dan berkata, “Aktifkan mode rapat selama satu jam,” atau “siapkan SMS ke Ibu bahwa saya pulang terlambat.” Host FoneClaw menangkap intent, membuat task id, menyimpan conversation state, lalu menyiapkan rencana. Request ke server MCP membawa metadata yang cukup, idempotency key, dan state reference yang eksplisit.
Untuk Do Not Disturb, server dapat membantu memilih tool atau memvalidasi parameter. Phone-agent host tetap membaca device state terbaru: apakah izin DND tersedia, apakah mode sudah aktif, dan apa durasi yang diminta. Pengguna melihat approval jika tindakan berdampak. Setelah approval, eksekusi berjalan melalui Android tool yang didukung. Host memverifikasi status akhir, mencatat result record, dan menutup task sebagai selesai.
Untuk SMS, stateful layer lebih penting. Host menyimpan penerima yang dimaksud, isi lengkap, aplikasi default, approval, dan idempotency key. Sebelum eksekusi, device state dibaca ulang: apakah aplikasi SMS default siap, apakah ada satu kontrol Kirim yang stabil, apakah dual SIM meminta pilihan, dan apakah draf terlihat benar. Jika kondisi berubah, task berpindah ke status menunggu tindakan pengguna atau recovery, bukan retry buta.
Berdasarkan informasi terbaru yang tersedia sejauh ini, FoneClaw memberi analogi host-side state yang sudah dapat dicoba: floating assistant, same-phone task continuity, permission recovery, dan quick actions. Kemampuan yang tersedia saat ini dapat diakses melalui halaman Download FoneClaw. Untuk melihat current-screen context dan continuity yang dipicu pengguna, Asisten AI Mengambang Android untuk Memahami Layar Saat Ini menjelaskan cara FoneClaw menjaga tugas tetap dekat dengan layar yang sedang digunakan.
Jika workflow menyentuh panggilan, pemilihan protokol juga penting. Detail call-specific tersedia di Panggilan Telepon oleh Agen AI: MCP Cloud Calling vs Dialer Android FoneClaw. Untuk artikel ini, pelajarannya adalah stateful Android host harus memegang task state dan device verification, sementara MCP stateless membuat konektor lebih mudah diskalakan.
Menskalakan server MCP tanpa kehilangan keandalan tugas ponsel
Transport stateless memudahkan deployment. Server dapat diskalakan horizontal, instance dapat restart, dan request dapat diarahkan lewat load balancer. Rilis MCP Go SDK v1.7.0 memberi contoh implementasi resmi untuk protocol 2026-07-28, termasuk metadata per request, discovery server, dan compatibility path untuk versi lama.
Keandalan phone-task membutuhkan lapisan tambahan. Retry perlu diklasifikasikan: membaca status dapat diulang; menyiapkan draf mungkin dapat diulang dengan idempotency; mengirim pesan, membuat panggilan, atau mengubah setting membutuhkan deduplication dan verifikasi. Idempotency key harus melekat pada tindakan eksternal agar satu permintaan tidak menghasilkan dua efek.
Correlation id dan audit record membantu operasi. Saat request diproses oleh instance berbeda, host agent tetap dapat menghubungkan percakapan, task id, tool call, approval, device state, result, dan recovery. Jika server gagal setelah approval tetapi sebelum eksekusi, host dapat memeriksa result state sebelum mencoba lagi. Jika Android menunjukkan efek sudah terjadi, task dicatat sebagai selesai. Jika belum terjadi, host dapat melanjutkan dengan idempotency yang sama.
Contoh recorder-to-action juga menunjukkan pola ini. Catatan rapat dapat berubah menjadi tugas ponsel, tetapi state harus mengikuti dari ringkasan ke approval dan aksi. Pembahasan khusus ada di MCP Perekam AI: Catatan Rapat Menjadi Tindakan Ponsel. Skalabilitas server berguna ketika state aplikasi tetap dimiliki di tempat yang tepat.
Batas keamanan dan checklist migrasi
Migrasi ke MCP stateless perlu dimulai dari pemisahan auth, approval, dan task handle. Auth menentukan siapa atau layanan apa yang boleh meminta kemampuan. Approval adalah keputusan pengguna untuk tindakan tertentu. Task handle merujuk pekerjaan. Audit mencatat apa yang diminta, disetujui, dijalankan, diverifikasi, dan dipulihkan. Release MCP 2026-07-28 juga mencakup authorization hardening, sehingga migrasi perlu memperbarui cara metadata, token, dan capability discovery dibaca.
Backward compatibility tetap perlu direncanakan. Go SDK v1.7.0 menunjukkan compatibility path untuk legacy protocol versions, tetapi setiap deployment perlu diuji menurut client, server, gateway, dan library yang dipakai. Jalur migrasi yang sehat adalah menegosiasikan versi, mencatat capability yang tersedia, menjalankan canary, dan menjaga fallback pada workflow yang berdampak sampai observability cukup kuat.
Checklist migrasi kami untuk phone agent:
- Pastikan setiap request membawa metadata versi, identitas, capability, dan correlation id.
- Simpan conversation, task, device, approval, auth, dan audit state di pemilik yang tepat.
- Gunakan explicit state handle untuk merujuk pekerjaan, bukan sebagai pengganti approval.
- Tambahkan idempotency key untuk tindakan eksternal.
- Baca ulang device state sebelum eksekusi Android.
- Catat hasil dan jalur pemulihan setelah pemanggilan alat.
- Uji percobaan ulang, pembatalan, kedaluwarsa, dan kompatibilitas versi lama.
Saat kami mengevaluasi desain konektor untuk FoneClaw, persyaratan dasarnya sama: voice dan current-screen context dipicu pengguna, tindakan sensitif tetap terlihat dan reviewable, permission recovery menjadi bagian dari flow, dan governed Android tools menjalankan action yang didukung. Cakupan produk yang tersedia saat ini dapat dilihat di halaman fitur FoneClaw, termasuk 100+ built-in tools untuk workflow Android terkelola.
Sumber: rilis spesifikasi MCP 2026-07-28, proposal SEP-2575 tentang MCP tanpa status, proposal SEP-2567 tentang MCP tanpa sesi dengan pegangan status eksplisit, rilis SDK Go MCP v1.7.0, halaman unduhan FoneClaw, dan halaman fitur FoneClaw.