Setiap API Akan Dibangun Ulang untuk Agen

MCP memecahkan masalah koneksi. Ia tidak memecahkan kesenjangan kata kerja (verb gap).

Anda dapat membungkus REST API yang sempurna ke dalam MCP dalam satu sore. Meski begitu, agen pengkodean (coding agent) akan tetap kesulitan. Ia akan memilih endpoint yang salah. Ia akan memanggil tiga alat padahal satu saja cukup. Ia mungkin melakukan penulisan yang merusak (destructive write) tanpa bertanya.

API tersebut tidak rusak. Ia hanya dibangun untuk konsumen yang salah.

Selama dua puluh tahun, API dibangun untuk manusia. Manusia membawa niat (intent) dan model mental. Agen tidak membawa keduanya. Mereka harus merekonstruksi keduanya dari antarmuka (surface) Anda.

Ketika konsumen utamanya berubah sebanyak ini, antarmukanya pun harus ikut berubah.

Saya percaya antarmuka produk yang serius tidak hanya akan membungkus API yang sudah ada. Mereka akan membangunnya kembali di sekitar operasi asli-agen (agent-native).

Ini berarti beralih dari API berbasis sumber daya (resource-shaped) ke kontrak berbasis niat (intent-shaped). Kita harus merancang ulang di sekitar tujuan, status (state), efek samping (side-effects), persetujuan, dan pemulihan (recovery).

MCP adalah standar yang hebat untuk koneksi dan transportasi. Namun dalam spesifikasinya, sebuah alat hanyalah sebuah fungsi dengan nama dan skema. Ia tidak menentukan urutan operasi atau mana yang berbahaya.

Ini menciptakan kesenjangan kata kerja. API memberikan kata benda dan operasi CRUD kepada agen. Agen membutuhkan kata kerja yang membawa niat.

Lihat GitHub. Mereka mempersempit set alat mereka untuk meningkatkan penalaran agen. Mereka belajar bahwa pemetaan 1:1 dari API produk ke alat agen tidaklah berhasil.

Penelitian menunjukkan bahwa sebuah API bisa valid secara struktural tetapi tidak berguna secara semantik bagi agen. API asli-agen (agent-native) menjawab lebih dari sekadar "apa yang harus saya kembalikan." Ia menjawab:

  • Apa tujuannya?
  • Dalam status apa saya berada?
  • Apa efek sampingnya?
  • Apakah saya butuh persetujuan?
  • Bagaimana cara saya memulihkan diri?

Alih-alih penulisan mentah (raw write), Anda memerlukan pembagian:

  • Pratinjau tindakan.
  • Dapatkan persetujuan eksplisit.
  • Lakukan commit pada perubahan.
  • Rollback jika gagal.

Ini bukan sekadar "edisi agen." Ini hanyalah API yang lebih baik. Pengembang juga menginginkan pratinjau, kesalahan izin yang jelas, dan rollback. Pada akhirnya, desain asli-agen akan menggantikan desain yang berpusat pada manusia.

Pergeseran ini sangat masif. Ini memengaruhi API, CLI, dan log. Kita harus beralih dari prosa yang dapat dibaca manusia ke status yang dapat diproses mesin (machine-parseable state).

Keamanan bukanlah pembungkus yang Anda tambahkan kemudian. Keamanan adalah properti yang Anda rancang ke dalam operasi itu sendiri.

Sumber: https://dev.to/gyu07/every-api-will-be-rebuilt-for-agents-2hj4

Komunitas belajar opsional: https://t.me/GyaanSetuAi