Pi Akhirnya Dukung MCP: Alasan Berubah dan Apa Itu Codemode

Selama ini Pi dikenal karena sikapnya yang tegas menolak MCP. Situs pi.dev pernah memuat pernyataan bangga bahwa Pi tidak mendukung Model Context Protocol, dan tim di baliknya beberapa kali menyampaikan pandangan yang meremehkan protokol tersebut, termasuk sebuah tulisan dari Mario Zechner yang berjudul kurang lebih apakah Anda benar-benar butuh MCP. Jadi cukup mengejutkan ketika pembaruan Pi ternyata membawa MCP sebagai bagian dari fungsionalitas inti.

Apa yang Berubah

Alasan pertama yang disebut tim Earendil sederhana: dunia tidak statis. Mereka mengamati MCP selama setahun terakhir dan menyimpulkan bahwa MCP hari ini bukan MCP tahun lalu. Namun perubahan pada protokol saja, menurut mereka, bukan alasan yang cukup untuk memasukkannya ke inti. Pi punya ekosistem extension yang mapan, dan MCP sebenarnya sudah ada sebagai extension lewat proyek pi-mcp-adapter.

Yang membuat MCP akhirnya masuk ke inti bukan sekadar bagaimana MCP berubah, melainkan karena perubahan yang dibutuhkan untuk mengakomodasinya ternyata berguna secara umum. Salah satu contohnya: perubahan yang mereka buat untuk MCP juga memudahkan penggunaan Jev di dalam Pi. Pada dasarnya, kebutuhan Pi dan kebutuhan MCP ternyata mirip, yaitu sebuah sandbox untuk bereksperimen dalam bentuk interpreter.

Masalah Komposisi yang Belum Selesai

Meski banyak hal membaik pada MCP, tim mengakui beberapa hal belum. Masalah terbesar MCP tetap sama: sulit dikomposisi. Bahkan dengan codemode, yang mereka sebut sebagai sandbox kecil yang rapi untuk memungkinkan komposisi pemanggilan tool, MCP belum sepenuhnya memenuhi harapan itu. Menurut mereka, ini kini lebih menjadi masalah server MCP yang beredar dan pendekatan harness yang berbeda-beda, bukan lagi masalah protokolnya sendiri.

Banyak server MCP masih dibangun untuk harness yang sekadar menumpahkan daftar tool ke dalam konteks. Server semacam itu berusaha mengoptimalkan efisiensi token dari sisi mereka dengan mengembalikan teks. Cara pandang tim Earendil sekarang berbeda: MCP seharusnya jauh lebih dekat ke OpenAPI dengan penemuan tool yang cerdas. Artinya, tool seharusnya mengembalikan data terstruktur, dan tool seharusnya bisa ditemukan lewat dokumentasi serta deskripsinya.

Mereka juga menyoroti mengapa CLI terasa begitu fungsional. Alasannya, agen dan model cukup merangkai komponen dengan bashism yang efisien. Tidak ada alasan mendasar mengapa hal yang sama tidak bisa dilakukan dengan MCP. MCP di Pi dibangun dengan mengekspos tool tersebut ke sandbox JavaScript, seperti yang juga dilakukan harness lain seperti Codex.

Apa Itu Codemode

Pertanyaan berikutnya yang muncul: mengapa tidak sekadar mengerjakan codemode tanpa MCP? Sebagian jawabannya berkaitan dengan bagaimana tool diekspresikan di Pi saat ini. Tim menyebut telah melakukan banyak pekerjaan dalam beberapa bulan terakhir untuk membuat Pi masuk akal dengan model-model baru yang mengizinkan deferred tool load, yaitu pemuatan tool yang ditunda.

Konsep deferred tool load penting untuk dipahami. Pada pendekatan lama, semua definisi tool dimasukkan ke konteks sejak awal. Semakin banyak tool yang tersedia, semakin besar konteks yang terpakai sebelum model sempat berpikir. Dengan pemuatan yang ditunda, definisi tool baru ditarik saat benar-benar dibutuhkan. Ini mengurangi konsumsi token dan memberi ruang lebih besar untuk penalaran.

Codemode dalam kerangka ini berfungsi sebagai tempat eksekusi: alih-alih model memanggil tool satu per satu lewat antarmuka yang kaku, tool diekspos ke sandbox JavaScript tempat model bisa merangkai beberapa pemanggilan menjadi satu alur. Pola ini menyerupai cara agen bekerja dengan shell: satu blok kode kecil bisa melakukan banyak hal yang jika dilakukan lewat pemanggilan terpisah akan memakan lebih banyak langkah.

Perdebatan yang Lebih Besar

Keputusan Pi menarik untuk dicermati karena menyentuh perdebatan yang lebih luas di ekosistem agen AI. Ada dua kubu yang saling berseberangan. Kubu pertama menganggap MCP sebagai lapisan standar yang menyatukan cara agen mengakses tool eksternal. Kubu kedua menganggap CLI dan pemanggilan fungsi langsung lebih sederhana, lebih murah, dan lebih mudah didebug.

Kasus Pi menunjukkan bahwa pilihan ini tidak selalu hitam putih. Sebuah tim bisa menolak sebuah protokol selama bertahun-tahun, lalu berbalik arah ketika kondisi berubah, tanpa harus mengakui bahwa penolakan awalnya salah. Perubahan pada protokol, perubahan pada kebutuhan internal, dan munculnya pola baru seperti deferred tool load bisa bersama-sama mengubah kalkulasi.

Yang juga menarik adalah penekanan pada komposisi. Argumen inti tim Earendil bukan sekadar bahwa MCP sekarang lebih baik, melainkan bahwa yang dibutuhkan agen modern adalah kemampuan menggabungkan banyak operasi menjadi satu alur yang efisien. Baik CLI, sandbox JavaScript, maupun MCP yang dirancang dengan benar semuanya mencoba menjawab kebutuhan yang sama.

Yang Bisa Diambil Praktisi

Bagi yang membangun agen atau alat serupa, ada beberapa poin yang layak dipertimbangkan:

• Jangan mengunci keputusan arsitektur secara permanen. Penolakan terhadap sebuah teknologi adalah snapshot pada satu waktu, bukan hukum. Tinjau ulang ketika kondisi berubah.
• Rancang tool agar mengembalikan data terstruktur. Mengembalikan teks yang sudah diformat untuk dibaca manusia mempersulit komposisi dan boros token.
• Investasikan pada penemuan tool. Tool yang bisa ditemukan lewat deskripsi dan dokumentasi lebih skalabel daripada daftar tool yang ditumpahkan seluruhnya ke konteks.
• Pertimbangkan pemuatan yang ditunda. Semakin banyak tool yang tersedia, semakin penting untuk tidak memuat semuanya di awal.
• Sandbox adalah pola yang berulang. Baik untuk komposisi tool maupun untuk menjalankan kode yang dihasilkan model, sandbox interpreter muncul sebagai kebutuhan bersama.

Bagaimana Harness Lain Menangani Masalah Serupa

Pendekatan Pi bukan satu-satunya jawaban atas pertanyaan bagaimana agen sebaiknya mengakses tool. Harness lain memilih jalur yang berbeda, dan membandingkannya membantu memahami trade-off yang ada.

Sebagian harness memilih model pemanggilan fungsi langsung, yaitu definisi tool dimasukkan ke konteks dan model memilih salah satu. Pendekatan ini sederhana dan mudah didebug, tetapi skalanya terbatas: semakin banyak tool, semakin besar konteks yang terpakai sebelum model sempat berpikir. Sebagian harness lain memilih pendekatan berbasis shell, di mana agen merangkai perintah CLI seperti manusia. Pendekatan ini hemat token dan sangat fleksibel, tetapi bergantung pada kualitas alat baris perintah yang tersedia dan lebih sulit dibatasi dari sisi keamanan.

Pendekatan ketiga, yang kini diadopsi Pi, adalah mengekspos tool ke sandbox interpreter. Model menulis kode kecil di dalam sandbox, dan kode itulah yang memanggil tool. Keunggulannya, beberapa pemanggilan bisa dirangkai dalam satu langkah, hasil antaranya bisa diproses sebelum dipakai, dan jumlah data yang berpindah bolak-balik ke model bisa ditekan. Kekurangannya, sandbox perlu dirancang dengan hati-hati agar tidak menjadi jalur keluar yang baru.

Ketiga pendekatan ini tidak saling meniadakan. Banyak harness menggabungkan pemanggilan fungsi untuk operasi sederhana, shell untuk tugas sistem, dan sandbox untuk komposisi yang kompleks.

Praktik Baik Desain Tool untuk Agen

Dari kasus Pi, ada beberapa prinsip yang bisa diterapkan siapa pun yang membangun tool untuk agen:

• Kembalikan data terstruktur, bukan teks berformat. Tool yang mengembalikan JSON atau struktur lain lebih mudah dikomposisi daripada tool yang mengembalikan teks yang sudah dipangkas untuk dibaca manusia.
• Sertakan deskripsi yang jelas. Tool yang bisa ditemukan lewat deskripsi memungkinkan pemuatan yang ditunda, sehingga definisinya tidak perlu memenuhi konteks sejak awal.
• Batasi cakupan setiap tool. Tool dengan satu tanggung jawab lebih mudah divalidasi dan lebih aman dijalankan dalam sandbox.
• Rancang untuk komposisi. Bila beberapa operasi sering dipakai bersama, sediakan cara agar penggabungannya tidak memerlukan banyak langkah bolak-balik.
• Perhatikan konsumsi token. Setiap byte yang dikembalikan tool ke konteks model punya biaya. Mengembalikan data yang tidak perlu adalah pemborosan yang menumpuk sepanjang sesi.

Kapan Pendekatan Ini Cocok

Tidak semua proyek agen memerlukan sandbox interpreter. Untuk agen dengan sedikit tool dan tugas yang sederhana, pemanggilan fungsi langsung sudah cukup dan lebih mudah didebug. Biaya menambahkan sandbox, baik dari sisi kompleksitas implementasi maupun permukaan serangan baru, baru terbayar ketika jumlah tool bertambah dan tugas mulai memerlukan penggabungan beberapa langkah.

Tanda bahwa sebuah proyek sudah memerlukan pendekatan yang lebih terstruktur biasanya muncul dalam bentuk konkret: konteks yang penuh dengan definisi tool sebelum pekerjaan dimulai, rangkaian pemanggilan yang selalu muncul bersamaan, atau hasil antara yang harus diproses sebelum dipakai langkah berikutnya. Ketika gejala-gejala itu muncul, mengekspos tool ke sandbox mulai masuk akal.

Yang juga perlu diperhatikan adalah batas keamanan. Sandbox yang mengeksekusi kode yang dihasilkan model harus dirancang dengan asumsi bahwa kode tersebut bisa saja berbahaya. Artinya, isolasi proses, pembatasan akses berkas, dan pembatasan jaringan menjadi syarat, bukan tambahan opsional. Pola yang sama juga berlaku untuk tool yang dipanggil langsung: setiap tool yang memberi akses ke sistem eksternal memperluas permukaan serangan dan perlu dibatasi cakupannya.

Apa Artinya untuk Pengguna Pi

Bagi pengguna Pi, perubahan ini praktis: MCP kini tersedia tanpa perlu memasang extension terpisah. Bagi yang sebelumnya sudah memakai extension MCP, peralihan ke dukungan inti berarti satu dependensi eksternal yang bisa dihapus dari konfigurasi. Bagi yang selama ini menolak MCP karena sikap resmi Pi, kini ada alasan untuk meninjau ulang.

Yang juga layak diperhatikan adalah munculnya konsep codemode sebagai pola umum. Alih-alih memanggil tool satu per satu, agen menulis kode yang memanggil tool tersebut. Pola ini mengubah cara tool didesain: alih-alih antarmuka yang dioptimalkan untuk pemanggilan tunggal, tool lebih baik dirancang agar mudah dipakai dari dalam kode.

Untuk tim yang membangun agen internal, keputusan Pi menunjukkan bahwa pilihan protokol bukan keputusan sekali jadi. Sebuah protokol bisa ditolak hari ini dan diadopsi tahun depan tanpa harus mengakui bahwa penolakan awal salah. Yang penting adalah alasan di balik keputusan, dan kemauan untuk meninjau ulang ketika kondisi berubah.

Kisah Pi ini juga mengingatkan bahwa dalam bidang yang bergerak cepat, argumen teknis punya masa berlaku. Sebuah pernyataan seperti kami tidak mendukung protokol X bisa benar pada saat diucapkan dan menjadi usang setahun kemudian. Yang membedakan tim yang baik adalah kesediaan meninjau ulang keputusan ketika bukti baru muncul, dan kerelaan menjelaskan alasan perubahan itu secara terbuka kepada penggunanya.

Rekomendasi Tools & Layanan

Beberapa layanan yang dipake di panduan ini: free trial Alibaba Cloud (coba gratis, sesuaikan kebutuhan), dan halaman promo terbaru buat cek diskon yang lagi jalan bulan ini.