Pelajaran setelah membuat 50 alat MCP: pemanggilan fungsi ternyata adalah hubungan yang sangat tidak biasa akrab

Tulisan yang merangkum, berdasarkan pengalaman memindahkan alat manajemen aset ke CLI berbasis SQLite dan server MCP selama dua hari akhir pekan,
di titik mana desain alat MCP bercabang secara menentukan dari RPC.
Penulis membuat sekitar 30 perintah CLI dan sekitar 50 alat MCP, dan berangkat dari temuan bahwa meski jumlahnya banyak,
hal yang paling lama menyita waktu bukanlah kode, melainkan penjelasan fungsi.

• Saat fungsi yang sama diekspos sekaligus ke CLI dan MCP, meski signature/argumen/nilai kembalian semuanya sama, kedua antarmuka itu
  berjalan berbeda. Yang berubah hanya apakah pemanggilnya manusia atau LLM
• Signature menjelaskan apa yang diterima sebuah fungsi, tetapi hampir tidak bisa menjelaskan kapan fungsi itu harus dipanggil. Nama fungsi
  lebih dekat ke satu baris dalam kamus, sehingga kata itu sendiri tidak bisa menentukan akan diletakkan di atas kalimat seperti apa
• Bagi pemanggil LLM, dibanding alat yang dipecah halus mengikuti Single Responsibility Principle (SRP), alat berat yang langsung menyentuh intensi lebih
  alami
• Secara bentuk, MCP memang berada dalam garis keturunan RPC (JSON-RPC, signature, schema), tetapi perbedaan penentunya adalah arah kepercayaan
  berbalik. Dalam RPC, pemanggil mempercayai target panggilan, sedangkan dalam MCP, pihak pembuat alat harus mempercayai pemanggil (LLM)
• Signature adalah deklarasi, penjelasan adalah permintaan. Yang satu bersifat memaksa, yang satu lagi bersifat membujuk. Artinya, bahasa persuasi mulai masuk ke dalam desain alat
• Ini bukan perubahan yang benar-benar baru, melainkan lebih dekat ke regresi. Desain industri, arsitektur, dan UX sudah lama berada di posisi ini,
  sedangkan pemrograman selama ini hanya kebetulan bertahan di salah satu ujung yang sangat akrab

Hal-hal yang tidak dikatakan oleh signature

• add_txn (transaksi), add_balance (snapshot aset), dan add_flow (pemasukan/pengeluaran) milik Firma semuanya punya signature
  yang jelas, dan tipe argumennya juga didefinisikan ketat dengan schema zod, tetapi LLM sering bingung memilih alat mana yang harus dipanggil dari ujaran pengguna
• Awalnya dicurigai sebagai masalah model LLM, tetapi masalah sebenarnya ada pada signature itu sendiri. Nama add_txn tidak memuat
  momen pemanggilan seperti “jika pengguna mengatakan jual-beli, gunakan alat ini”
• Pemanggilan baru stabil setelah description dinyatakan dalam bentuk "Use this when... Do NOT use this for..." untuk menegaskan
  kapan dipakai dan batasnya dengan alat lain
• Intensi fungsi bergeser dari signature ke penjelasan fungsi. Seperti gagang palu yang menyiratkan cara pakai lewat bentuknya,
  penjelasan fungsi MCP pada praktiknya setara dengan affordance alat itu bagi LLM (Donald Norman)

SRP vs affordance, dan arah kepercayaan

• Awalnya alat ingin dipecah halus sesuai Single Responsibility Principle menjadi get_holdings, get_prices, get_pnl, tetapi ketika pengguna bertanya “bagaimana portofolio saya?”,
  LLM harus menggabungkan empat atau lima panggilan, respons menjadi lambat, dan peluang meleset makin besar
• Akhirnya show_portfolio dirancang sebagai alat berat yang mengembalikan sekaligus saham yang dimiliki/harga beli rata-rata/harga saat ini/nilai evaluasi/laba rugi kumulatif. get_brief bahkan melangkah lebih jauh dengan sekaligus mengembalikan indikator makro dan insight
• SRP adalah kebajikan bagi orang yang membuat fungsi, affordance adalah kebajikan bagi orang yang memakai alat. Jika pemanggilnya manusia, perakitan masih mungkin; jika LLM, alat yang langsung menyentuh intensi lebih baik
• Pada alat tulis, arah kepercayaan tampak paling jelas. Ketika pada add_txn ditulis "Always confirm with the user before recording", LLM selalu bertanya dan pengguna selalu menjawab “oke” — keunggulan antarmuka bahasa alami pun hilang
• Pada akhirnya tanggung jawab dibagi ulang dalam bentuk "catat segera, tanyakan hanya saat ambigu, dan jika salah bisa dibatalkan". Panduan seperti ini bukan penjelasan formal alat, melainkan prinsip operasional yang diberikan kepada pemanggil

Mungkin pemanggilan fungsi justru selama ini adalah kasus yang khusus

• Sejak awal, manusia memang selalu memakai alat yang tidak mereka buat sendiri. Mulai dari wadah buatan pembuat keramik, pisau buatan pandai besi, hingga program buatan pengembang, semuanya demikian
• Pemanggilan fungsi adalah hubungan yang cukup khusus karena pemanggil dan penulis berbagi banyak konteks, dan sistem tipe/IDE/dokumentasi terus memperkuat keakraban itu
• Jika pemanggilnya bukan manusia, ada dua pilihan. (1) memasukkan lebih banyak konteks ke LLM agar menjadi pemanggil yang akrab, (2) menjembatani jarak dari sisi alat. MCP lebih dekat ke yang kedua
• Bisa jadi ini adalah masa ketika cara mendesain antarmuka itu sendiri sedang berubah diam-diam. Pusat gravitasinya bergeser dari signature ke penjelasan, dari pemaksaan ke persuasi, dari asumsi keakraban ke pengakuan atas jarak