MCP Sudah Mati. Hidup CLI

 (ejholmes.github.io)
36 poin oleh GN⁺ 2026-03-02 | 8 komentar | Bagikan ke WhatsApp
  • MCP dengan cepat kehilangan perhatian di industri, dan kini pendekatan berbasis CLI lebih praktis
  • LLM sudah mahir menggunakan alat command line, dan tanpa protokol terpisah pun dapat menyelesaikan pekerjaan hanya dengan dokumentasi dan CLI
  • CLI bisa dijalankan dan di-debug dalam lingkungan yang sama oleh manusia maupun LLM, sehingga penyebab masalah lebih mudah dilacak
  • Dari sisi composability, sistem autentikasi, dan stabilitas pun CLI lebih efisien daripada MCP dan lebih mudah dipelihara
  • MCP menimbulkan friksi berkelanjutan di praktik kerja nyata, seperti inisialisasi yang tidak stabil, reautentikasi berulang, dan tidak adanya kontrol izin
  • Dalam kebanyakan kasus, CLI adalah pilihan yang lebih sederhana dan lebih andal, dan perusahaan sebaiknya memprioritaskan penyediaan API dan CLI dibanding server MCP

Keterbatasan MCP dan Keunggulan CLI

  • Setelah Anthropic mengumumkan Model Context Protocol (MCP), industri berlomba-lomba membangun server MCP, tetapi alat utama seperti OpenClaw dan Pi tidak mendukungnya, dan manfaat nyatanya pun minim
    • LLM sebenarnya sudah bisa menyelesaikan pekerjaan lewat CLI dan dokumentasi
    • MCP menambahkan endpoint baru dan sistem autentikasi baru, tetapi hanya menduplikasi fungsi yang sudah ada
  • LLM dioptimalkan untuk penggunaan alat CLI dan sangat mahir menggunakannya
    • Dilatih dengan jutaan man page, jawaban Stack Overflow, dan shell script GitHub
    • Misalnya, jika Claude diberi perintah seperti gh pr view 123, ia dapat menjalankannya apa adanya
  • MCP menjanjikan antarmuka yang lebih rapi, tetapi pada praktiknya deskripsi, parameter, dan waktu penggunaan tiap alat tetap harus didokumentasikan dengan cara yang sama

CLI Juga Berguna bagi Manusia

  • CLI memungkinkan manusia dan LLM berbagi perintah yang sama
  • Saat Jira berperilaku tak terduga, kita bisa langsung menjalankan perintah jira issue view yang sama untuk mereproduksi masalah
  • Dalam MCP, alat hanya ada di dalam percakapan LLM, sehingga saat masalah muncul kita harus repot menelusuri log pengiriman JSON
  • Proses debugging seharusnya tidak memerlukan protocol decoder
  • CLI memiliki input dan output yang jelas sehingga pelacakan masalah lebih mudah

Kemampuan Komposisi (Composability)

  • CLI bisa digabungkan dalam pipeline dengan jq, grep, file redirection, dan lain-lain
  • Contoh analisis Terraform plan skala besar:
    • terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
  • Dengan MCP, seluruh plan harus dibuang ke context window (mahal dan sering kali tidak memungkinkan), atau filtering kustom harus diimplementasikan langsung di server MCP
  • Pendekatan CLI memanfaatkan alat yang sudah ada dan terdokumentasi dengan baik, serta bisa dipahami manusia maupun agen

Masalah Autentikasi (Auth)

  • MCP terlalu opinionated dalam soal autentikasi
  • Alat CLI sudah memakai sistem autentikasi yang teruji: aws memakai profile dan SSO, gh memakai gh auth login, kubectl memakai kubeconfig
  • Baik dipakai langsung oleh manusia maupun dijalankan oleh Claude, alur autentikasinya tetap sama
  • Jika ada masalah autentikasi, cukup gunakan cara yang sudah ada seperti aws sso login, gh auth refresh, tanpa perlu troubleshooting khusus MCP

Masalah Operasional: Tidak Ada Komponen Bergerak (No Moving Parts)

  • Server MCP lokal harus memulai dan menjaga proses terpisah; di Claude Code, proses ini dibuat sebagai child process dan kadang menimbulkan masalah
  • Alat CLI hanyalah file biner di disk, tanpa proses background, pengelolaan state, atau prosedur inisialisasi tambahan

Ketidaknyamanan di Praktik Kerja Nyata

  • Inisialisasi tidak stabil: server MCP kadang gagal start sehingga Claude Code harus sering di-restart, lalu dicoba lagi setelah state direset
  • Reautentikasi berulang: saat memakai beberapa alat MCP, masing-masing perlu diautentikasi; CLI yang memakai SSO atau kredensial jangka panjang tidak punya masalah ini
  • Kontrol izin yang kasar: di Claude Code, alat MCP bisa diizinkan berdasarkan nama, tetapi tidak bisa dibatasi hanya-baca atau diberi batasan rentang parameter
    • Pada CLI, misalnya gh pr view bisa diizinkan sementara gh pr merge tetap memerlukan persetujuan, sehingga kontrol izin yang rinci dimungkinkan

Kapan MCP Masih Valid

  • Jika sama sekali tidak ada alat yang setara dalam bentuk CLI, MCP bisa menjadi pilihan yang tepat
  • Diakui bahwa ada nilai pada antarmuka yang distandardisasi, dan mungkin ada use case di mana MCP lebih cocok daripada CLI
  • Namun, untuk sebagian besar pekerjaan, CLI tetap lebih sederhana, lebih cepat di-debug, dan lebih andal

Pelajaran Inti dan Pesan untuk Builder

  • Alat terbaik adalah alat yang berfungsi baik untuk manusia maupun mesin; CLI telah melalui puluhan tahun iterasi desain sehingga composable, mudah di-debug, dan terintegrasi dengan sistem autentikasi yang sudah ada
  • MCP mencoba menciptakan abstraksi yang lebih baik, tetapi ternyata abstraksi yang sudah cukup baik itu sudah ada
  • Perusahaan yang berinvestasi pada server MCP tetapi belum memiliki CLI resmi perlu meninjau ulang strateginya;
    API yang baik → CLI yang baik akan dimanfaatkan agen dengan sendirinya
  • Dengan mengurangi kompleksitas protokol yang tidak perlu, produktivitas dan maintainability dapat ditingkatkan

Bacaan terkait

8 komentar

 
sonnet 2026-03-03

Bukan berarti MCP tidak punya kelebihan, melainkan kita baru sadar dari ilusi penggunaan MCP secara serampangan pada hal-hal yang memang tidak mendapatkan manfaat darinya. Saat membuka microservice untuk LLM pun kita tidak akan memakai CLI, dan MCP adalah protokol API.
 
brainer 2026-03-03

Waktu itu juga sebenarnya cukup pakai API. Alasan kami memakai MCP sebenarnya karena keterbatasan long context, tetapi sekarang batasan itu sebagian besar sudah berhasil diatasi.
 
jamsya 2026-03-03

Sangat relate.
tanpa perlu instal aws mcp pun, Claude Code ternyata otomatis pakai aws cli buat ambil hal yang dibutuhkan 😂
 
GN⁺ 2026-03-02
Komentar Hacker News

  • Sudah lama saya menghindari mengatakan ini, tetapi sekarang saya yakin MCP tidak punya keunggulan praktis
    Saya menjalankan agen AI yang mengendalikan seluruh workflow pengembangan saya lewat perintah shell, dan mereka bisa memahami CLI flag hanya dari output --help meski melihatnya untuk pertama kali
    Sebaliknya, server MCP selalu tidak stabil dan butuh perawatan
    CLI bisa dikombinasikan dengan jq, grep, file redirection, dan lain-lain, sedangkan MCP terkungkung pada format yang dikembalikan server
    Pada akhirnya, saya rasa adopsi MCP lebih merupakan sinyal pemasaran ‘AI-first’ daripada alasan teknis

    • MCP memang tumbuh pesat pada 2024, tetapi menurut saya metanya berubah cepat pada awal 2025 saat terminal agent (Claude Code) muncul
    • Saya justru lebih suka MCP. Dibanding CLI, error handling dan debugging jauh lebih rapi, dan kita bisa membatasi flag berbahaya atau membagi hasil dengan pagination
      MCP cukup dipahami sebagai konsep wrapper sederhana seperti REST atau gRPC
    • Saya juga menghindari MCP. Saya pernah memakai JIRA MCP dan hasilnya berantakan. Sebagai gantinya, saya membiarkan LLM memanggil API langsung dan menulis script, dan itu jauh lebih efisien
      Sekarang saya menganggap alat CLI untuk LLM ada di puncak
    • Perusahaan kami mengekspos alat khusus web seperti wiki internal lewat MCP agar Claude bisa langsung mengecek log dan metrik
      Tetapi tidak nyamannya, hasil MCP selalu masuk ke context window. Akan bagus kalau bisa di-dump ke filesystem
    • Server MCP terasa seperti produk transisi yang dibuat saat LLM belum terlalu maju. Saya rasa melatih dengan data CLI jauh lebih baik

  • MCP mirip black-box API yang bisa langsung dipanggil tanpa instalasi atau provisioning resource
    Sementara itu, CLI bisa mengakses environment lokal sehingga jauh lebih presisi
    Dengan jq dan CLI duckdb, saya mengambil sample file data skala besar, lalu Opus 4.6 otomatis menyesuaikan query sambil mengeksplorasinya
    CLI punya respons real-time yang bagus, jadi sangat berguna terutama untuk analisis data eksploratif
    CLI yang sering saya pakai antara lain showboat, br, psql, roborev

    • Saya juga punya pengalaman yang sama. Input/output teks pada CLI paling cocok dengan cara LLM dilatih
      Saya menikmati memakai duckdb dengan ChatGPT, tetapi saya penasaran apakah Anda mengatur system prompt agar DB lokalnya tetap dipertahankan
    • Daripada CLI, kita bisa menjalankan perintah di container Docker untuk menghindari masalah instalasi. Mungkin pendekatan seperti ini juga bisa diotomatisasi menjadi sebuah “skill”
    • Sebagai penutur non-native bahasa Inggris, saya merasa lucu melihat bentuk jamak seperti MCPs

  • MCP punya arti saat kita perlu menemukan alat yang tidak ada di CLI dan memanggilnya secara kontekstual
    Misalnya, echomindr yang saya buat menyediakan DB berisi keputusan pendiri startup yang diekstrak dari podcast lewat MCP
    Saat Claude menerima pertanyaan terkait startup, ia mencari pengalaman nyata para founder untuk menjawabnya
    CLI cocok saat manusia sudah tahu alat mana yang akan dipakai, sedangkan MCP cocok untuk pemilihan tool berbasis discovery

  • Sepertinya penulis melihat penggunaan AI hanya dari sudut pandang developer
    Kebanyakan pengguna memakai LLM lewat antarmuka berbasis web seperti ChatGPT
    Dari sudut pandang perusahaan, MCP jauh lebih cocok untuk menghubungkan alat marketing, sales, dan project management

  • MCP sendiri tidak buruk, tetapi stdio MCP terlalu over-engineered
    Sebagai gantinya, pendekatan Streamable HTTP + OAuth Discovery adalah cara integrasi AI yang paling efisien saat ini
    Misalnya, Sentry MCP memungkinkan autentikasi dan akses data hanya dengan satu URL
    Masalahnya ada pada cara implementasi MCP. Alih-alih dipanggil lewat bash, MCP akan bekerja jauh lebih fleksibel jika diekspos sebagai HTTP endpoint

    • Baik CLI maupun MCP sama-sama memerlukan sistem izin yang dirancang konsisten di level API. Bagian Streamable HTTP itu perlu penjelasan lebih lanjut
    • Saya juga setuju. Autentikasi dan telemetri terpusat jauh lebih sederhana. Tetapi memang harus dipakai hanya untuk use case yang tepat

  • Beberapa klien saya tidak punya server MCP, tetapi developer tetap memintanya
    Pada akhirnya kami mengekspor Postman API dalam JSON untuk diberikan, tetapi developer tetap menginginkan server MCP
    Kenyataannya, dukungan MCP berfungsi seperti checklist pemasaran

  • Blog ini tampaknya terlalu condong ke sudut pandang developer
    Saat menghubungkan alat atau layanan untuk non-developer, MCP terasa jauh lebih natural

    • Benar. Di antarmuka chat, CLI tidak bisa dijalankan, dan banyak layanan untuk non-developer memang tidak punya CLI sama sekali
    • Saya juga sempat bertanya-tanya apakah CLI bisa dijalankan di antarmuka web/mobile seperti ChatGPT atau LeChat
    • Antarmuka untuk non-developer sudah berevolusi ke bentuk seperti OpenClaw dan Claude Cowork

  • Lowongan kerja seperti “mencari kandidat dengan pengalaman 5 tahun di MCP” pada akhirnya menjadi meme yang tidak bermakna

  • Salah satu alasan CLI lebih baik daripada MCP adalah karena ia punya format yang dioptimalkan secara teori informasi
    Output alat Unix menempatkan informasi terkait berdekatan, sehingga mekanisme perhatian pada LLM bisa bekerja lebih efisien
    JSON memang mudah di-parse, tetapi tidak nyaman untuk dibaca dan ditalar
    Format CLI intuitif bagi manusia maupun LLM
    Referensi terkait: Entropy and Information Layout

  • Membandingkan MCP dan CLI itu seperti membandingkan OpenAPI dan string (JSON)
    MCP didefinisikan secara formal, sementara CLI adalah antarmuka abstrak setingkat (String, List String, Map Int Stream) -> PID
    Pada akhirnya keduanya sama-sama API, dan yang penting adalah memilih alat yang tepat untuk mencapai tujuan

    • Tetapi CLI menyediakan dokumentasi lengkap lewat --help, jadi jika LLM bisa memahaminya, sulit mengatakan standardisasi MCP pasti lebih baik
    • Pengalaman penggunaan nyata lebih penting daripada teori. Kalau ingin mengatakan MCP dan CLI itu sama, perlu dibuat contoh yang menunjukkan Playwright CLI dan MCP memiliki penggunaan token dan konfigurabilitas yang sama
      Jika tidak, secara praktis orang akan langsung merasakan bahwa kedua pendekatan ini memang berbeda
 
develosopher 2026-03-03

Jika seseorang mengembangkan SaaS dan sedang mempertimbangkan antara CLI vs MCP untuk integrasi AI, kemungkinan besar mereka akan memilih MCP terlebih dahulu. Mendukung CLI berarti menambah titik pengelolaan. Keduanya bisa berjalan berdampingan, tetapi sepertinya CLI tidak akan hilang.
 
hanje3765 2026-03-03

Sepertinya dengan meningkatnya kecerdasan LLM, kebutuhan akan MCP menjadi tidak lagi jelas.
Saya juga benar-benar merasakan hal yang sama.
 
m00nlygreat 2026-03-03

Sepertinya eksekusi jarak jauh dirapikan ke mcp, sedangkan eksekusi lokal ke skills.
 
hulryung 2026-03-03

Saya juga mulai langsung membuat dan menggunakan tool lewat CLI ketimbang MCP.