MCP sudah mati; Hidup MCP

 (chrlschn.dev)
19 poin oleh GN⁺ 2026-03-16 | 6 komentar | Bagikan ke WhatsApp
  • CLI muncul sebagai tren baru untuk antarmuka alat agen, tetapi CLI kustom juga mengalami masalah konteks yang sama seperti MCP dan harus mengorbankan struktur serta berbagai keunggulan lainnya
  • MCP stdio lokal dan MCP jarak jauh berbasis Streamable HTTP adalah use case yang sepenuhnya berbeda, dan pembedaan ini diabaikan dalam perdebatan saat ini
  • Fitur Prompts dan Resources pada MCP adalah mekanisme untuk mendistribusikan skill dan dokumentasi yang distandardisasi ke seluruh organisasi secara real-time, dan menjadi kunci perpindahan dari vibe coding ke rekayasa agentic yang sistematis
  • Server MCP terpusat menstandarkan autentikasi OAuth, telemetri, observabilitas sehingga memungkinkan keamanan tingkat organisasi dan pengukuran efektivitas alat
  • Untuk pengembang individual, CLI mungkin cocok, tetapi pada tingkat organisasi dan enterprise, MCP adalah alat masa kini sekaligus masa depan yang menjamin konsistensi, keamanan, dan kualitas

Siklus hype yang digerakkan influencer

  • Enam bulan lalu, Model Context Protocol (MCP) adalah topik terbesar di industri, dan setiap vendor ingin meluncurkan produk terkait MCP
  • Saat itu pun sudah ada pandangan skeptis seperti "ini cuma API, jadi kenapa perlu wrapper", dan memang ada tim yang memilih melewati siklus hype MCP lalu menulis wrapper alat sederhana di atas endpoint REST API
  • Untuk sebagian besar use case, MCP makin dianggap sebagai overhead yang tidak perlu dibanding memanggil API secara langsung
  • Kini wacana industri telah bergeser menjadi kritik terhadap MCP dan puja-puji CLI, yang terkait dengan struktur budaya influencer AI yang terus menciptakan tren baru demi mempertahankan perhatian
  • Bahkan tokoh terkenal seperti Garry Tan dan Andrew Ng cenderung menggeneralisasi pengalaman pribadi mereka, dan budaya influencer yang menciptakan FOMO serta hype telah mendistorsi wacana di bidang ini
  • Memang ada kasus nyata di mana CLI lebih cocok sebagai antarmuka alat agen, tetapi tidak selalu demikian dalam semua kasus

Penghematan token dengan CLI: realitas dan batasannya

Alat CLI yang sudah ada dalam data pelatihan

  • Utilitas CLI seperti jq, curl, git, grep, psql, aws yang sudah ada dalam dataset pelatihan LLM dapat langsung digunakan agen tanpa instruksi tambahan, skema, atau konteks
  • MCP harus mendeklarasikan alat lebih dulu dalam respons tools/list, sehingga menimbulkan overhead dibanding alat CLI yang sudah dikenal
  • Untuk alat CLI yang memang sudah ada dalam data pelatihan, memang tepat untuk selalu memprioritaskannya dibanding MCP

Batasan CLI kustom

  • Alat CLI kustom (bespoke) tidak diketahui cara pakainya oleh LLM, sehingga perlu diberi penjelasan di AGENTS.md atau README.md
  • Kita bisa menunjuk direktori /cli-tools dan bergantung pada nama yang deskriptif, tetapi agen sering salah jika hanya memakai cara ini dan pada akhirnya tetap membutuhkan lebih banyak dokumentasi penjelas
  • Bahkan alat seperti curl pun kehilangan manfaat penghematan token ketika harus memahami skema OpenAPI kustom

Ekstraksi dan transformasi berantai

  • Dengan rantai CLI, data bisa dicari lalu ditransformasikan sehingga jumlah data yang masuk ke context window berkurang
  • Namun, konten terformat seperti HTML, JSON, XML juga dapat diekstrak memakai selector seperti DOM/CSS, JSONPath, XPath, sehingga ini bukan keunggulan unik CLI

Konsumsi konteks bertahap

  • Sementara MCP memuat seluruh toolset dan skema di awal, CLI memungkinkan memuat konteks secara bertahap melalui --help
  • Namun untuk alat CLI kustom, agen harus menelusuri konten help selama beberapa turn, dan pada akhirnya memuat informasi serupa skema MCP tanpa struktur
  • Pada alur yang cukup kompleks, agen pada akhirnya akan menelusuri sebagian besar pohon bantuan sehingga penghematannya menjadi minim
  • Menurut hasil riset Vercel, ketika seluruh indeks dokumentasi ditempatkan di AGENTS.md, pemanfaatan dokumentasi oleh agen meningkat, dan penyediaan seluruh skema di awal lebih menguntungkan untuk pemilihan alat yang benar
  • Ketika Anthropic saat ini sudah menyediakan context window 1 juta token, masih layak dipertanyakan apakah penghematan token tetap menjadi argumen yang menentukan

Dualitas MCP: stdio vs Streamable HTTP

Batasan mode stdio

  • Dalam mode stdio, server MCP berjalan secara lokal bersama agen dan menambah kompleksitas yang tidak perlu dibanding sekadar menulis CLI sederhana
  • Untuk sebagian besar use case, MCP mode stdio tidak diperlukan

Nilai revolusioner Streamable HTTP

  • MCP dengan transport Streamable HTTP memungkinkan logika yang sama dijalankan di server terpusat, dan menjadi elemen kunci dalam adopsi organisasi dan enterprise untuk mengubah vibe coding menjadi rekayasa agentic
  • Sebagian besar influencer gagal membedakan dua mode ini

Keunggulan server MCP terpusat

Fitur backend yang kaya

  • Di server terpusat, alat dapat memanfaatkan kemampuan platform yang kaya seperti instance Postgres atau query graf Cypher berbasis Apache AGE
  • Di sisi agen, cukup mengatur endpoint HTTP dan token autentikasi sehingga deployment menjadi sederhana
  • DB lokal seperti SQLite juga memungkinkan, tetapi terbatas untuk berbagi state di seluruh organisasi

Runtime agen sementara (Ephemeral)

  • Dalam lingkungan runtime sementara seperti GitHub Actions, alat yang memerlukan backend kompleks dapat digunakan tanpa instalasi melalui server MCP jarak jauh
  • Pengelolaan workload stateful di lingkungan stateless didelegasikan ke server terpusat

Autentikasi dan keamanan

  • Jika mengakses API aman lewat CLI, semua pengembang harus mengakses API key secara langsung, dan ini menjadi beban besar bagi tim operasi
  • Jika dipusatkan di belakang server MCP, pengembang cukup mengautentikasi ke server MCP dengan OAuth, sementara API key dan secret sensitif dikendalikan di belakang server
  • Saat anggota tim keluar, cukup mencabut token OAuth, dan orang tersebut sejak awal memang tidak pernah memiliki akses ke key dan secret lainnya

Telemetri dan observabilitas

  • Di server MCP terpusat, trace dan metrik OpenTelemetry dapat dikumpulkan dengan alat standar
  • Kita bisa mengetahui alat mana yang efektif, runtime agen mana yang digunakan, dan di titik mana alat gagal
  • Ini juga bisa dilakukan dengan alat CLI, tetapi deployment lokal memerlukan update di sisi pengguna dan scaffolding telemetri harus diulang untuk tiap alat CLI

Deployment instan yang distandardisasi dan update otomatis

  • Alat terdistribusi (paket) menimbulkan masalah kompatibilitas versi API, tetapi MCP memungkinkan server memberi tahu klien tentang update melalui Subscriptions dan Notifications
  • MCP Prompts setara dengan SKILL.md yang dikirim dari server, dan MCP Resources setara dengan /docs yang dikirim dari server

Nilai organisasional MCP Prompts dan Resources

  • Konten dinamis: file *.md di repositori adalah file statis yang perlu diperbarui manual, sedangkan prompts dan resources berbasis server dapat dihasilkan secara dinamis secara real-time
    • Dokumen yang hanya berguna dalam konteks tertentu, data harga, status sistem saat ini, dan sebagainya dapat disuntikkan secara dinamis tanpa pemanggilan alat
  • Pembaruan konsistensi otomatis: file *.md yang didistribusikan lewat repositori atau paket perlu disinkronkan, tetapi jika dikirim lewat prompt MCP maka akan selalu terbaru
    • Bahkan dokumentasi resmi pihak ketiga pun, jika diproksikan lewat server, tidak perlu lagi disalin dan diperbarui manual di repositori
  • Berbagi pengetahuan di seluruh organisasi: konten yang berlaku untuk seluruh organisasi seperti keamanan, best practice telemetri, dan pertimbangan deployment infrastruktur dapat didistribusikan secara konsisten ke semua repositori, semua workflow, semua frontend agen (Claude Code, Codex, VS Code Copilot, GitHub Agents, OpenCode, dan lain-lain)
    • Dalam lingkungan microservices, satu tim dapat diberi akses ke dokumentasi layanan tim lain, atau tim layanan dapat menyediakan skill secara dinamis pada setiap deployment
  • Telah dikonfirmasi ada contoh nyata MCP prompts dan resources yang benar-benar bekerja di OpenCode, Claude Code CLI, dan lainnya, dan hanya dengan konfigurasi klien MCP, tidak perlu pengelolaan tambahan setelah deployment

Kesimpulan: pada level organisasi, MCP adalah masa kini sekaligus masa depan

  • Enam bulan lalu MCP adalah topik terpanas, sementara sekarang dituduh sebagai biang context bloat, tetapi trade-off dan jebakan serupa pada CLI kustom justru diabaikan
  • Ketika tim memikirkan cara beralih dari vibe coding ke rekayasa agentic, mereka secara alami akan sampai pada desain dan misi MCP
  • Seperti terlihat pada kasus terbaru di divisi Amazon AWS yang mewajibkan persetujuan engineer senior untuk perubahan yang dibantu AI, tim pada akhirnya tetap harus mengoperasikan dan memelihara sistem perangkat lunak yang dihasilkan agen AI
  • Saran Garry Tan dan Andrew Ng mungkin berlaku di lingkungan individual yang homogen, tetapi sulit diterapkan apa adanya dalam organisasi tempat tim dengan tingkat kemampuan teknis dan pengalaman yang beragam harus berkonvergensi pada kualitas yang konsisten
  • Untuk merilis perangkat lunak yang andal dan mudah dipelihara, dibutuhkan disiplin rekayasa yang menjamin konsistensi, keamanan, kualitas, dan akurasi, dan untuk itu MCP adalah alat yang tepat bagi organisasi dan enterprise saat ini

Bacaan terkait

6 komentar

 
slowandsnow 2026-03-16

cli adalah alat lokal, sedangkan mcp adalah server, jadi kegunaannya sangat berbeda.
 
cnaa97 2026-03-17

Kalau menjalankan CLI di server, bukankah hasilnya sama?
 
ng0301 2026-03-16

MCP dibangkitkan dari kematian!
 
edunga1 2026-03-16

Dokumen terkait: MCP sudah mati. Hidup CLI
 
hmmhmmhm 2026-03-16

Saya berharap diskusi tentang semacam fitur sandbox CLI agar alat CLI bisa digunakan juga di aplikasi mobile makin berkembang; saat benar-benar mencoba membuatnya kompatibel dengan mobile, pada akhirnya bottleneck-nya tampaknya adalah isu sandboxing.
 
GN⁺ 2026-03-16
Pendapat Hacker News

  • Rasanya sebagian besar fitur integrasi AI yang muncul belakangan ini dirancang dengan buruk
    Bahkan perintah dasar pun belum distandardisasi, sementara yang berlimpah justru panduan tidak akurat hasil generasi LLM, bukan dokumentasi
    Pada akhirnya, hal-hal yang disebut “standar AI” kemungkinan akan terus muncul lalu menghilang. LLM pada dasarnya berbasis teks, jadi sulit bekerja setepat protokol jaringan. Rekayasa yang berpusat pada teks seperti ini pada akhirnya akan membangun piramida abstraksi yang rapuh

  • Menurut saya, alat AI yang paling berguna adalah struktur yang membungkus agen probabilistik dengan gerbang deterministik
    Karena itu saya memakai MCP di atas HTTP. Misalnya, NanoClaw memperkuat keamanan dengan memfilter pesan WhatsApp secara deterministik dan mem-proxy API key. Struktur seperti ini membuat AI lebih dapat dipercaya

    • Saya juga mengikuti pola serupa. Agen otonom saya, Smith, menghubungkan MCP ke service mesh sehingga kebijakan (OPA) dan pemantauan dikelola secara terpusat
      Struktur ini unggul dalam keamanan dan kemudahan pengelolaan, dan bahkan bisa membuat CLI secara otomatis dari katalog alat
      Contoh implementasinya bisa dilihat di smith-gateway
    • Bahkan jika agen disusupi, batasannya tetap harus terjaga. Kami memakai token delegasi kriptografis yang cakupannya dibatasi per tugas, lalu memverifikasinya di batas alat MCP
      Core open-source-nya bisa dilihat di tenuo
    • Inti tooling AI yang bagus belakangan ini bukan memberi kebebasan, melainkan memberi batasan
      MCP memisahkan dengan jelas pengambilan keputusan AI dan eksekusi sistem yang deterministik. Saya memakai Claude Code bersama server MCP; AI menangani pemecahan masalah kreatif, sedangkan eksekusi berjalan lewat jalur yang dapat diprediksi, sehingga sangat efisien

  • MCP adalah spesifikasi protokol tetap untuk komunikasi antar aplikasi AI
    Alih-alih memaksa API antar aplikasi terikat seperti pendekatan “integration” lama, ia menyediakan abstraksi komunikasi yang dapat digunakan ulang seperti HTTP·FTP·SMTP
    Saya rasa AI membutuhkan bahasa umum seperti ini agar bisa berinteraksi dengan berbagai layanan
    Spesifikasinya bisa dilihat di modelcontextprotocol.io/specification/2025-11-25

    • Namun ada yang bilang, “ini solusi untuk masalah yang salah”
      Yang sebenarnya dibutuhkan bukan protokol baru, melainkan spesifikasi CLI atau API yang bisa dieksplorasi secara bertahap. Menurut argumen ini, MCP hanyalah solusi sementara dari masa ketika agen awal belum bisa menjalankan CLI
    • Pendapat lain mengatakan, “kalau AI memang AI, kenapa perlu protokol terpisah untuk memahami HTTP atau FTP?”
      Dari sudut pandang ini, MCP pada akhirnya hanyalah solusi sementara untuk ketidakmatangan teknologi
    • Ada juga pertanyaan yang lebih mendasar: “apakah memang perlu membuat protokol baru?”
    • Ada kritik bahwa MCP pada dasarnya hanya definisi API kustom yang dibangun di atas JSON-RPC, sehingga sulit dianggap lebih standar atau lebih dapat digunakan ulang dibanding cara yang sudah ada
    • Ada juga pendapat bahwa alat CLI pada akhirnya tidak berbeda dari MCP, karena sama-sama merupakan “abstraksi komunikasi yang dapat digunakan ulang”

  • Saat MCP pertama kali muncul, saya mengabaikannya karena terlihat seperti sampah yang terlalu di-engineer
    Sampai sekarang saya tidak menyesal. Hal yang sama juga berlaku untuk LangChain. Berbahaya kalau ikut-ikutan hanya karena sesuatu sedang populer

    • Namun sekarang saya menambahkan antarmuka MCP ke semua kode saya. LLM jadi jauh lebih mudah untuk debugging, dan MCP sudah menjadi komponen yang sama pentingnya dengan UI
      Dengan investasi waktu yang sangat kecil, efisiensi yang didapat bisa sangat besar
    • Tentu, ‘sniff test’ itu berguna, tapi itu saja tidak cukup
      Kadang alat yang kasar justru bertahan hidup karena menyederhanakan masalah integrasi yang rumit
      Kalau sejak awal diabaikan hanya karena terlihat jelek, kita bisa kehilangan kesempatan saat ia nanti menjadi infrastruktur standar
    • LangChain bukan overengineering, melainkan kekacauan tanpa desain sama sekali
    • Ada juga yang malah bilang MCP populer karena terlalu sederhana
      Bukan overengineering, melainkan struktur yang jelas dan intuitif
    • Ada juga orang yang masih belum paham sebenarnya LangChain itu apa

  • Remote MCP lumayan bagus karena autentikasinya ditangani otomatis, sehingga akses ke layanan jadi mudah
    Namun dibanding kombinasi CLIs + Skills, ia punya beban konteks (context bloat) yang lebih besar, dan kehilangan keunggulan Unix CLI seperti pemrosesan pipeline atau input heredoc
    CLI efisien karena skill bisa dibuat otomatis dari output --help
    MCP memerlukan proses yang terus berjalan, sedangkan CLI cukup dijalankan saat dibutuhkan

    • Tentu CLI perlu instalasi, tetapi MCP punya kelebihan karena bisa bekerja hanya dengan konfigurasi

  • Saya tetap menganggap MCP sebagai lapisan yang tidak perlu
    Saya setuju CLI > MCP, tetapi manfaat dokumentasi dan sentralisasi juga bisa diselesaikan dengan cara lain
    Misalnya, dengan Skills kita bisa menyimpan panduan untuk CLI maupun API, dan hanya memuatnya saat diperlukan
    Keuntungan MCP yang terpusat pun sebenarnya bisa diwujudkan cukup dengan proxy yang sudah ada atau AWS SSO
    Pada akhirnya, menurut saya lebih baik mendokumentasikan dengan Skills, lalu melakukan interaksi nyata lewat CLI atau REST API

    • Namun ada juga sanggahan terhadap ini
      Isi Skills pada akhirnya tetap masuk ke konteks dan menambah beban, dan proxy tidak bisa sepenuhnya menggantikan fungsi MCP
      MCP dapat mengaktifkan prompt dan resource melalui perintah / dan referensi @, sesuatu yang tidak bisa dilakukan proxy
      Demo terkait bisa dilihat pada .gif di bagian akhir tulisan dan di spesifikasi MCP

  • Saya merasa MCP lebih cocok untuk lingkungan konsumen
    Di lingkungan pengembangan ia rumit dan tidak efisien, tetapi bagi pengguna umum, MCP memudahkan model untuk menunjukkan kemampuan yang bisa dijalankannya
    Tidak perlu mengatur environment, dan di GUI ia juga bisa memvisualisasikan respons seperti Siri atau Google Assistant

  • Dari sudut pandang penyedia alat AI untuk pengguna non-developer di perusahaan, pendekatan MCP yang tersentralisasi sangat berguna
    Kami bisa mengelola tone merek, istilah internal, akses data bersama, dan konteks domain secara konsisten
    Melalui metode resource di MCP, kami menyediakan “skills” yang terstandardisasi dan mengontrol pola koneksi data

  • Penulis melihat beberapa konsep dari berbagai sudut, tetapi tampaknya tidak mengetahui konsep lama seperti Token Notation(TOON)
    Kesan yang muncul seolah-olah ia berharap hal seperti itu sudah ada

  • Masalah sebenarnya pada MCP adalah beban pemeliharaan
    Misalnya, kalau butuh integrasi GitHub, kita malah harus bergantung pada wrapper npm alih-alih API yang sudah terdokumentasi dengan baik
    Saya pribadi cukup memakai gh CLI atau curl. Kalau API berubah, agen tinggal membaca dokumentasi baru lalu beradaptasi
    Dengan MCP, kita harus menunggu sampai wrapper perantara diperbarui
    Klaim keamanannya juga kontradiktif — awalnya muncul tanpa autentikasi, tetapi sekarang justru menjual keamanan sebagai kelebihan
    Pada praktiknya, ini adalah masalah yang sudah lama diselesaikan oleh cara lama seperti chroot atau scoped token
    Satu-satunya keunggulan MCP yang benar-benar jelas hanyalah flow OAuth untuk pengguna non-developer. Untuk alat developer, menurut saya lebih baik membuat CLI yang memang lebih baik