MCP lagi ramai dibahas sebagai “USB-C buat AI”. Tapi menurut gua, bagian paling menarik dari update 2026-07-28 bukan branding connector-nya. Yang menarik justru hal boring: protokolnya mulai dibuat lebih gampang dioperasikan seperti sistem production beneran.
Artikel ini ngebahas kenapa MCP stateless penting buat developer yang mulai bikin atau memakai AI agent. Intinya: MCP bukan cuma cara agent manggil tool. Begitu tool itu dipakai banyak user, lu perlu mikirin load balancing, auth, routing, cache, observability, dan failure mode. Kalau nggak, “agent tooling” cuma pindah dari demo keren ke operasional yang rapuh.
Apa itu MCP dalam bahasa sederhana?
Model Context Protocol atau MCP adalah protokol untuk menghubungkan aplikasi AI dengan context dan tool eksternal. Misalnya agent butuh baca issue GitHub, query database, ambil file, buka search internal, atau menjalankan fungsi tertentu lewat server yang sudah disediakan.
Analogi simpelnya: kalau API biasa dibuat supaya aplikasi bisa ngobrol dengan layanan lain, MCP dibuat supaya aplikasi AI bisa memakai resource, prompt, dan tool dengan pola yang lebih standar. Di dokumentasi MCP, fitur server dibagi ke beberapa konsep seperti resources, prompts, dan tools. Itu penting karena AI agent yang berguna biasanya bukan cuma menjawab chat, tapi juga perlu akses kerja nyata.
Masalahnya, akses kerja nyata selalu membawa konsekuensi. Begitu agent bisa manggil tool, pertanyaan berikutnya bukan lagi “bisa connect nggak?”, tapi:
- siapa yang boleh manggil tool itu?
- request ini punya permission apa?
- kalau server restart, request masih aman?
- kalau traffic naik, bisa dibagi ke banyak instance?
- kalau agent salah langkah, ada audit trail-nya nggak?
Kenapa update MCP 2026-07-28 penting?
Rilis MCP 2026-07-28 membawa beberapa perubahan besar: stateless protocol core, Multi Round-Trip Requests, header-based routing, cacheable list results, authorization hardening, framework extension formal, dan update Tier 1 SDK.
Yang paling penting buat developer umum adalah perubahan ke stateless core. Di blog resminya, MCP menjelaskan bahwa request sekarang makin self-contained. Secara praktis, ini bikin server MCP lebih gampang dijalankan di belakang load balancer karena request tidak harus selalu “ingat” session state yang tinggal di satu instance tertentu.
GitHub juga sudah menyiapkan GitHub MCP Server untuk mendukung spec berikutnya sebelum tanggal rilis resmi. Di changelog GitHub, mereka menulis bahwa stateless core membuat deployment MCP lebih gampang diskalakan, sesi dan initialize dihapus, dan client bisa connect lebih cepat.
Di Hacker News, salah satu komentar dari operator gateway MCP juga menarik: banyak bug mereka datang dari kebutuhan menyimpan state server. Buat gua, ini sinyal yang realistis. Kadang perubahan protocol yang terasa abstrak justru lahir dari rasa sakit operasional yang nyata.
Stateless itu bukan buzzword, tapi rem operasional
Stateless artinya server tidak harus menggantungkan request berikutnya pada state session yang tersimpan di memori instance sebelumnya. Request idealnya membawa context yang cukup untuk diproses sendiri, atau memakai mekanisme eksternal yang jelas kalau memang butuh state.
Kenapa ini penting? Karena begitu server lu punya lebih dari satu instance, state lokal mulai jadi sumber bug:
- request pertama masuk instance A, request berikutnya masuk instance B;
- instance A restart dan state hilang;
- load balancer perlu sticky session yang bikin scaling lebih ribet;
- debugging jadi susah karena bug hanya muncul di pola routing tertentu;
- cache dan retry jadi riskan karena server punya asumsi state tersembunyi.
Buat demo di laptop, stateful sering terasa nyaman. Buat production, stateful bisa jadi utang. Bukan berarti state selalu buruk, tapi state harus dikelola dengan sadar: disimpan di tempat yang benar, punya lifetime jelas, dan bisa diaudit.
MCP server laptop beda dengan MCP server production
Ini bagian yang sering kelewat. Banyak developer mencoba MCP dari server lokal: connect ke editor, panggil tool, jalan, lalu terasa magic. Itu valid buat eksplorasi. Tapi production MCP server punya standar yang beda.
| Area | Demo lokal | Production |
|---|---|---|
| Traffic | Satu user, satu mesin | Banyak user, banyak instance |
| Auth | Token pribadi atau login lokal | Scoped permission, revocation, audit log |
| State | Bisa numpang memori proses | Harus jelas, tahan restart, aman di-load-balance |
| Failure | Restart manual | Retry, timeout, observability, alerting |
| Security | Risiko terbatas | Tool access bisa menyentuh data dan sistem penting |
Kalau lu bikin agent internal yang bisa akses GitHub, Slack, Jira, database, atau dashboard deploy, MCP server itu bukan mainan kecil. Dia jadi bagian dari control plane kerja tim. Kalau control plane-nya rapuh, agent yang pintar tetap bisa bikin chaos.
Authorization hardening itu sinyal yang lebih penting dari hype agent
Rilis MCP ini juga menyebut authorization hardening. Ini penting karena banyak diskusi AI agent terlalu fokus ke kemampuan model, bukan izin akses.
Prompt bukan permission system. Kalau agent punya token terlalu luas, prompt “jangan hapus data” bukan boundary yang cukup. Boundary yang lebih waras adalah permission yang sempit, approval gate untuk aksi sensitif, audit log yang bisa dibaca manusia, dan tombol revoke saat ada incident.
Ini juga nyambung dengan tren yang lebih besar: agent bukan cuma user baru, tapi juga non-human identity. Dia butuh identitas sendiri, scope sendiri, dan jejak aksi sendiri. Kalau semua agent cuma numpang token manusia, lu bakal susah jawab pertanyaan sederhana: “siapa yang melakukan aksi ini?”
Checklist sebelum lu bikin MCP server buat workflow nyata
Kalau lu baru eksperimen, nggak perlu langsung over-engineer. Tapi begitu MCP server mulai dipakai untuk workflow kerja nyata, minimal cek ini:
- Scope tool sekecil mungkin. Jangan kasih tool “do anything” kalau task-nya cuma baca issue atau ambil metadata.
- Pisahkan read dan write. Tool baca data harus beda boundary dengan tool yang bisa update, delete, deploy, atau kirim pesan.
- Gunakan approval untuk aksi sensitif. Deploy, delete, rotate secret, invite user, dan kirim email massal sebaiknya tidak auto-run tanpa review.
- Bikin request tahan retry. Kalau request diulang karena timeout, hasilnya jangan menggandakan efek samping.
- Log keputusan penting. Simpan siapa/agent apa yang memanggil tool, input penting, output ringkas, status, dan error.
- Jangan simpan secret di context agent. Agent butuh akses lewat mekanisme credential yang bisa dicabut, bukan secret mentah di prompt.
- Uji failure mode. Restart server, putus network, ubah permission, dan lihat apakah agent gagal dengan aman.
Checklist ini nggak glamorous. Tapi justru ini bedanya demo AI dengan workflow yang bisa dipercaya.
Angle buat developer Indonesia: jangan cuma ikut hype MCP
Gua ngerti kenapa MCP menarik. Rasanya seperti cara standar buat bikin AI agent nyambung ke semua hal. Tapi buat developer, skill yang lebih mahal bukan cuma “bisa bikin MCP server”. Skill yang lebih mahal adalah tahu kapan tool itu layak diberi akses, bagaimana membatasi aksinya, dan bagaimana membaca jejaknya saat ada masalah.
Kalau lu lagi belajar AI tooling, saran gua: mulai dari tool kecil yang jelas. Misalnya tool read-only untuk baca dokumentasi internal atau issue tracker. Setelah itu baru tambah aksi write dengan approval. Jangan langsung bikin agent yang bisa deploy, edit database, dan kirim notifikasi ke semua channel cuma karena demo-nya keren.
Agent tooling yang matang itu kelihatan boring: ada auth, log, timeout, cache, routing, dan permission. Tapi boring ini yang bikin sistem bisa dipakai lebih dari sekali tanpa bikin lu deg-degan.
Takeaway singkat
- MCP adalah protokol untuk menghubungkan AI app dengan context dan tool eksternal.
- Update 2026-07-28 penting karena MCP bergerak ke stateless core dan fitur production seperti routing, cache, dan authorization hardening.
- MCP server lokal yang jalan di laptop belum tentu siap production.
- Prompt bukan permission system. Tool access tetap butuh auth, audit, dan revocation.
- Buat builder, peluangnya besar: bikin AI agent yang berguna, tapi tetap punya boundary yang bisa dipercaya.
FAQ singkat
Apakah MCP stateless berarti semua server MCP otomatis aman?
Nggak. Stateless membantu operasional dan scaling, tapi security tetap bergantung ke auth, permission, validasi input, audit log, dan cara lu membatasi tool.
Apakah developer kecil perlu peduli MCP production layer?
Perlu kalau tool lu mulai menyentuh data penting atau dipakai orang lain. Kalau masih eksperimen lokal, cukup pahami prinsipnya dulu supaya nggak salah desain dari awal.
Apakah MCP bakal jadi standar final untuk semua AI agent?
Belum tentu. Tapi problem yang dibahas MCP nyata: agent butuh cara standar untuk akses context dan tool. Walaupun standar berubah, mental model soal auth, routing, dan audit tetap kepakai.
Penutup
Menurut gua, update MCP ini menarik bukan karena bikin AI terdengar lebih canggih, tapi karena bikin agent tooling terlihat makin seperti software engineering biasa. Ada protokol, ada state, ada auth, ada routing, ada cache, ada failure mode.
Dan itu kabar bagus. Karena kalau AI agent mau masuk kerja nyata, dia nggak cukup cuma pintar ngomong. Dia harus bisa dioperasikan, dibatasi, diaudit, dan dimatikan saat salah jalan.
Kalau lu lagi eksplor MCP atau AI agent workflow, simpan checklist di atas. Follow rafli.dev buat insight tech yang jujur, relatable, dan anti-bullshit.
