Apakah MCP Sudah Mati?

(quandri.io)

1 poin oleh GN⁺ 5 jam lalu | 2 komentar | Bagikan ke WhatsApp

MCP menghubungkan LLM ke alat eksternal, tetapi dalam workflow pengembangan, biaya konteks, stabilitas operasional, dan duplikasi dengan CLI/API menjadi beban besar
Dalam pengukuran Quandri, 77 definisi alat untuk Linear, Notion, Slack, dan Postgres memakan sekitar 21.077 token, atau 10,5% dari konteks Claude 200K
Untuk melihat issue Linear, pendekatan MCP selalu membawa 42 definisi alat sehingga menghabiskan sekitar 12.957 token, jauh lebih besar daripada pendekatan CLI yang sekitar 200 token
MCP menambah proses server terpisah beserta autentikasi, inisialisasi, konflik, dan latensi round-trip eksternal, sedangkan CLI/API mudah direproduksi, di-debug, dan digabungkan di terminal
Quandri membungkus CLI yang sudah ada menjadi Skills untuk menghemat sekitar 21K token, dan hanya memakai MCP ketika tidak ada CLI atau ketika kontrol izin tingkat tim diperlukan

Biaya utama yang terungkap dari MCP

MCP(Model Context Protocol) menghubungkan LLM ke alat eksternal seperti GitHub, Linear, Notion, dan Slack, tetapi dalam workflow pengembangan nyata, penggunaan konteks, stabilitas operasional, dan tumpang tindih dengan CLI/API yang sudah ada menjadi masalah utama
Sejak dirilis pada akhir 2024, MCP disebut sebagai “USB-C untuk ekosistem AI”, tetapi bagi developer yang memakainya sehari-hari, biaya lain justru lebih dulu terlihat
Di Claude Code, setelah pengukuran ini dilakukan, Tool Search with Deferred Loading diperkenalkan sehingga skema alat MCP dimuat hanya saat dibutuhkan dan penggunaan konteks berkurang lebih dari 85%
Di Claude Code saat ini, masalah membengkaknya konteks sudah banyak berkurang, tetapi persoalan performa, debugging, dan arsitektur masih tetap ada

Sangat menghabiskan jendela konteks

Jendela konteks adalah ruang yang dipakai LLM untuk bekerja, dan saat server MCP dihubungkan, sebagian besar ruang itu bisa terisi hanya oleh definisi alat, bukan oleh isi pekerjaan sebenarnya
Hasil pengukuran dari ekstraksi definisi alat nyata pada server MCP yang terhubung di lingkungan Quandri menunjukkan bahwa ketika keempat server dihubungkan, 10,5% jendela konteks habis hanya untuk definisi alat
Ukuran definisi alat:
- Linear: 42 alat, sekitar 51.229 karakter, sekitar 12.807 token
- Notion: 14 alat, sekitar 16.156 karakter, sekitar 4.039 token
- Slack: 12 alat, sekitar 15.168 karakter, sekitar 3.792 token
- Postgres: 9 alat, sekitar 1.755 karakter, sekitar 438 token
- Total: 77 alat, sekitar 84.308 karakter, sekitar 21.077 token
Penggunaan konteks per model:
- Pada konteks Claude 200K, definisi alat mengambil 10,5%
- Pada konteks GPT-4o 128K, definisi alat mengambil 16,5%
Linear saja selalu memuat 42 definisi alat dan memakan lebih dari sekitar 12.800 token, sehingga walaupun yang dipakai hanya get_issue dan save_issue, semua definisi tetap ikut dimuat
Contoh definisi alat yang besar:
- linear/save_issue: 2.479 karakter, sekitar 619 token
- slack/search_public: 1.614 karakter, sekitar 403 token
- linear/list_issues: 1.588 karakter, sekitar 397 token
- notion/fetch: 1.379 karakter, sekitar 344 token
- slack/send_message: 1.248 karakter, sekitar 312 token

Beban stabilitas operasional dan performa

MCP perlu menjalankan dan mempertahankan proses terpisah, sehingga dapat menimbulkan kegagalan inisialisasi dan masalah autentikasi berulang
Setiap pemanggilan alat memerlukan round-trip ke server eksternal, sehingga kecepatan respons AI melambat
Jika proses server MCP crash, alat bisa hilang di tengah sesi
Tidak jelas izin apa saja yang benar-benar dimiliki tiap alat, sehingga visibilitas izin rendah
Dalam benchmark Jira MCP dari MCP is dead. Long live the CLI, MCP 3 kali lebih lambat per panggilan dibanding pemanggilan REST API langsung, dan panggilan pertama termasuk inisialisasi 9,4 kali lebih lambat
Perbedaan performa ini tidak terbatas pada Jira saja, tetapi berasal dari arsitektur yang menambahkan lapisan proses berupa server MCP di antara LLM dan API dasar
Overhead yang sama juga berlaku pada server Linear, Notion, dan Slack di stack Quandri

Bertumpang tindih dengan CLI/API yang sudah ada

CLI/API memungkinkan manusia dan LLM memakai perintah yang sama, sedangkan MCP hanya ada di dalam percakapan LLM
CLI/API bisa bebas digabungkan dengan pipe, jq, dan grep, sedangkan MCP terikat pada format yang dikembalikan server
CLI/API bisa langsung direproduksi dan di-debug di terminal, sedangkan MCP hanya dapat direproduksi dalam konteks percakapan
LLM sudah mempelajari cara menggunakan CLI/API melalui man page dan StackOverflow, sedangkan MCP memerlukan definisi alat terpisah
CLI/API umumnya sudah terpasang, sementara MCP membutuhkan konfigurasi server, autentikasi, dan manajemen proses tambahan

Biaya token untuk melihat issue Linear

Saat melihat issue Linear yang sama, pendekatan MCP memakai sekitar 65 kali lebih banyak token dibanding pendekatan CLI
Pendekatan CLI memakai sekitar 200 token:
- Prompt perintah curl: sekitar 50 token
- Respons: sekitar 150 token
Pendekatan MCP memakai sekitar 12.957 token:
- 42 definisi alat Linear yang selalu dimuat: sekitar 12.807 token
- Pemanggilan alat dan respons: sekitar 150 token
Contoh CLI ini memanggil Linear GraphQL API secara langsung:

curl -s -H "Authorization: Bearer $LINEAR_TOKEN" \  
  -H "Content-Type: application/json" \  
  -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' \  
  https://api.linear.app/graphql

Alternatif: strategi CLI-first dan Skills

Pendekatan yang menyediakan CLI → API → dokumentasi lebih ringan dan lebih langsung
Karena LLM sudah mempelajari cara memakai CLI dari man page dan StackOverflow, definisi alat terpisah tidak perlu selalu dimuat
Memakai CLI yang sudah ada secara langsung menghindari pemborosan konteks untuk definisi alat, dan karena manusia serta AI memakai antarmuka yang sama, debugging menjadi lebih mudah
Juga bisa bebas digabungkan dengan perintah lain melalui pipeline
Jika MCP seperti “membuka semua menu di atas meja sejak awal”, maka Skills lebih mirip “meminta pustakawan mengambil hanya buku yang dibutuhkan”
MCP memuat semua definisi alat saat koneksi dibuat dan selalu menghabiskan konteks, sedangkan Skills dimuat hanya saat diperlukan dan hanya memakan konteks ketika sedang dipakai
Semakin banyak server, semakin besar tekanan konteks dari MCP, sedangkan Skills tidak selalu memakan konteks sebanding dengan jumlah skill yang ada
Intinya adalah menaruh panduan penggunaan CLI ke dalam Skills, dan ini paling efisien bila digabungkan dengan strategi CLI-first
Contoh Linear Skill hanya berisi URL API, cara autentikasi, perintah curl untuk melihat issue, cara pencarian GraphQL, dan petunjuk bahwa JSON diparse dengan jq:

# Linear Issue Lookup Skill  
- Linear API: https://api.linear.app/graphql  
- Auth: Bearer Token ($LINEAR_TOKEN env var)  
- Get issue: curl -s -H "Authorization: Bearer $LINEAR_TOKEN" -H "Content-Type: application/json" -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' https://api.linear.app/graphql  
- Search issues (GraphQL): adjust the query field for JQL-like filtering  
- Results are JSON, parse with jq

Dengan pendekatan ini, LLM hanya memuat isi di atas ke konteks saat skill tersebut dipanggil
Tidak perlu terus membawa 42 definisi alat Linear; cukup muat perintah CLI yang benar-benar diperlukan

Kapan MCP masih relevan

Saat layanan tidak punya CLI, MCP bisa menjadi satu-satunya cara koneksi
Bagi pengguna non-developer yang tidak memakai terminal, MCP bisa lebih mudah diakses
Untuk komunikasi dua arah real-time yang melampaui pola request-response sederhana, MCP bisa cocok

Kriteria memilih untuk akses database

Akses database pada akhirnya adalah menjalankan query, dan LLM pada dasarnya sudah cukup paham SQL serta query MongoDB
Jika informasi DB, cara memakai CLI, dan skema disertakan dalam Skill, LLM dapat menulis query tanpa MCP
Contoh Postgres Skill hanya memuat host, skema tabel, dan cara memakai CLI psql:

# Postgres Skill  
- Host: postgres://localhost:5432/myapp  
- Tables: users (id, name, email), orders (id, user_id, status)  
- CLI: psql -h localhost -d myapp -c "SELECT * FROM users WHERE ..."

Untuk database, MCP juga punya kelebihan:
- Keamanan query: server MCP dapat memaksa mode read-only dan memblokir query berbahaya di level server
- Perlindungan kredensial: pendekatan CLI dapat mengekspos string koneksi di prompt, sedangkan server MCP mengelola kredensial secara internal
Untuk pengembangan lokal atau DB pribadi, Skills + CLI lebih ringan, lebih cepat, dan lebih mudah dipulihkan saat terjadi kesalahan
Untuk DB produksi atau lingkungan tim bersama, MCP lebih cocok karena pengaman seperti validasi query dan kontrol akses di level server menjadi penting
Dalam sebagian besar workflow developer, MCP mudah menjadi over-engineering

Cara Quandri menggunakannya

Quandri memakai Bash + CLI, Skills, dan MCP bersama-sama sesuai layanan yang digunakan
Untuk alat yang dipakai setiap hari seperti gh, psql, dan aws, mereka memakai Bash + CLI:
- Tidak ada biaya konteks
- Fleksibilitas tinggi
- Bisa langsung di-debug di terminal
Untuk workflow multi-langkah berulang seperti menulis commit dan review PR, mereka memakai Skills:
- Dimuat hanya saat dipanggil
Untuk layanan seperti Slack, Linear, dan Notion yang tidak punya CLI kuat, mereka memakai MCP
MCP juga dipakai untuk kasus seperti akses database produksi ketika autentikasi tingkat tim atau pembatasan cakupan izin penting
Jika CLI sudah ada dan autentikasi lokal memungkinkan, biasanya itulah cara paling ringan
Jika layanan tidak punya CLI atau dibutuhkan autentikasi yang konsisten untuk seluruh tim, MCP punya nilai

Kesimpulan dan metode pengukuran

Daripada menghubungkan semuanya, yang lebih penting adalah mengajarinya dengan baik
Di Quandri, server MCP digantikan dengan Skills yang membungkus CLI yang sudah ada, sehingga menghemat sekitar 21K token konteks
Dalam workflow harian, kegagalan inisialisasi hilang dan debugging tetap dilakukan di terminal
Pendekatan memuat hanya alat yang diperlukan, pada saat diperlukan, bersama panduan CLI, lebih efisien
MCP mungkin akan berevolusi untuk menyelesaikan masalah ini di masa depan, tetapi untuk saat ini Skills adalah pilihan yang lebih baik
Metode pengukuran:
- Mengekstrak skema JSON tiap alat dari server MCP yang benar-benar dimuat di lingkungan Claude Code
- Mengukur ukuran berdasarkan nama alat, deskripsi, dan parameter
- Estimasi token memakai heuristik sekitar 1 token per 4 karakter
- Estimasi total server diekstrapolasi dari rata-rata alat sampel

Ingin terus mengikuti topik teknologi pilihan? Ikuti channel Telegram. @GeekNewsID

2 komentar

aer0700 3 jam lalu

Menurut saya, sepertinya tinggal memilih teknologi yang sesuai dengan situasi masing-masing. Kalau dibilang sudah mati, rasanya juga tidak begitu, karena nyatanya sudah dipakai sangat luas.

GN⁺ 5 jam lalu

Komentar Hacker News

Saya memimpin tim di OpenAI yang menangani ChatGPT App Store, plugin Codex, dan MCP secara umum, dan hal yang luput dari tulisan-tulisan yang mengatakan “MCP sudah mati” adalah bahwa pada praktiknya tidak terlalu penting apakah MCP dipakai sebagai protokol transport
Alasan MCP belum mati adalah karena hampir semua perusahaan di dunia sedang membuat server MCP, dan kami tahu karena berhubungan langsung dengan mereka
Banyak dari perusahaan ini tidak punya CLI, bahkan tidak punya API eksternal, tetapi tetap membuat server MCP
Secara internal, semua server MCP itu bisa saja diubah menjadi CLI, memakai mode kode, atau mengimplementasikan pencarian alat, tetapi itu hanya detail implementasi, dan inti utamanya adalah agen AI jadi bisa mengakses layanan yang sebelumnya tidak bisa mereka akses
Mungkin masih bisa diperdebatkan apakah MCP sudah mati sebagai lapisan komunikasi yang dipakai model untuk berbicara langsung, tetapi sama sekali tidak benar jika dikatakan MCP sudah mati sebagai protokol
Argumen ini juga jadi lebih lemah daripada dulu karena fitur penggunaan komputer/browser di aplikasi Codex, dan kalau belum mencobanya, levelnya benar-benar mengagumkan
- Menurut saya, kemungkinan besar MCP akan mati
  Alasan terbesarnya adalah bahwa entah implementasi nyatanya berupa API, web, atau CLI, ini menambahkan satu lapisan lagi dan satu pihak lagi di atasnya yang sinkronisasinya bisa rusak
  AI seharusnya tidak memakai protokol atau himpunan instruksi yang berbeda dari yang diakses, diketahui, dan digunakan manusia
  Saat ini perusahaan ingin mengekspos server MCP karena sedang tren, tetapi kenyataannya adalah Claude dipakai untuk membuat server MCP di atas API yang sudah ada, lalu sesekali disuruh memperbaruinya agar sesuai dengan dokumentasi publik
  Dokumentasi API sudah terbuka, dan Claude Code juga membuat server MCP hanya dengan membaca dokumentasi publik di internet, jadi MCP terasa seperti jalan memutar sementara untuk keterbatasan model saat ini
- Pada akhirnya, MCP lebih mirip nama merek untuk “API yang bisa dipakai model bahasa besar”
  Akibatnya, bahkan perusahaan yang sebelumnya tidak terlalu berorientasi teknis pun membuat API agar alat mereka tidak terlihat usang di era agen
  Saya mendukung tujuannya, tetapi apakah saya akan memilih ini sebagai protokol untuk mencapainya itu soal lain, dan bagaimanapun juga ini sudah menjadi protokol yang orang pernah dengar dan benar-benar pakai
- Pernyataan bahwa “hampir semua perusahaan di dunia membuat server MCP” justru terdengar seperti echo chamber
- MCP pada praktiknya menghabiskan context window yang masih sangat berharga sambil memecahkan masalah yang sebenarnya tidak ada
  Klaim bahwa tanpa MCP agen tidak bisa mengakses layanan, dalam penilaian paling baik pun, menyesatkan, dan seperti disebut di artikel, akses tetap bisa dilakukan hanya dengan alat command line dan input/output-nya
  Bahkan dari sudut pandang teknis murni, dibanding alat command line, MCP punya komposabilitas yang lebih rendah, dan menurut saya pihak yang tidak memprioritaskan komposabilitas pada akhirnya akan menanggung akibatnya
  Terus terang saja, ada bias investasi di sini, dan fakta bahwa MCP dijual ke banyak perusahaan tidak membantah bias itu
  Lihat saja Microsoft; banyak yang menganggap seberapa dalam kegunaan dan kualitas teknis terkubur hampir tidak ada hubungannya, bahkan justru sebaliknya
  Saya curiga dorongan OpenAI terhadap MCP saat ini juga sangat dipengaruhi faktor organisasi, dan dari dalam mungkin sulit untuk melihatnya
- Cerita bahwa MCP sedang dibuat di tempat-tempat yang tidak punya CLI cukup mengkhawatirkan
  Menyalin fungsi CLI yang sudah ada untuk integrasi agen yang lebih baik berbeda dengan menjadikannya satu-satunya antarmuka yang mengikat semua orang pada spesifikasi yang nanti bisa saja dinilai ada yang lebih baik
  Kalau begitu, nanti harus membayar utang MCP, dan pada akhirnya bisa jadi lebih murah kalau dari awal tidak melakukannya
Tulisan ini terasa seperti ditulis AI
Pada dasarnya MCP cukup dekat dengan JSON-RPC yang mewajibkan beberapa field khusus
Ada kekhawatiran soal JSON-RPC, tetapi tetap dibutuhkan lapisan penemuan layanan yang bisa diintegrasikan oleh model bahasa besar
Ini harus bisa dilakukan di berbagai tempat seperti situs web, aplikasi desktop, layanan backend, dan CLI hanyalah salah satu titik pertemuan dengan sistem-sistem ini
Apa pun yang akan menggantikan MCP, meskipun menentukan protokol komunikasi atau field penemuan alat yang berbeda, kemungkinan besar bentuknya akan tetap mirip
- Setiap kali membaca tulisan tentang MCP, rasanya seperti seluruh internet atau HN sedang mengalami serangan panik massal
  Orang bilang API lebih baik daripada MCP, tetapi MCP itu cuma API dengan sedikit petunjuk tambahan agar AI bisa menemukan cara memakainya
  Ada juga yang bilang pakai CLI saja, tetapi saya tidak paham persis maksudnya
  Alasan model bahasa besar bisa memakai alat CLI umum seperti ffmpeg dengan baik adalah karena pengetahuan itu sudah mengeras di dalam bobotnya
  Kalau Anda membuat alat CLI baru, Anda tetap harus mengajari AI cara memakainya, dan kalau bagian “mengajari” itu ingin disediakan dari server maka itu MCP, sedangkan kalau ingin dalam bentuk statis lokal maka itu skill
  Saya tidak mengerti kenapa konsep sesederhana ini bisa memicu perdebatan sebanyak ini
- Masalahnya adalah MCP mengambil konteks secara relatif permanen, dan tidak datang bersama sistem instalasi/penghapusan serta penemuan yang rapi
  Skill seharusnya semuanya berbasis MCP, dipanggil hanya saat diperlukan, dan bisa dikelola serta ditemukan dengan mudah oleh manusia maupun AI agar benar-benar berfungsi
  Kalau melihat cakupan penerapan nyatanya, ruang lingkup awalnya terlalu sempit, dan kalau ada sesuatu yang dibangun di atasnya, masih mungkin untuk hidup kembali
Untuk klaim “Masalah 1: melahap jendela konteks”, saya tidak paham apa bedanya dengan menjalankan linearcli --help, notioncli --help, dan slackcli --help satu per satu
Bahkan di MCP, lingkungan eksekusi bisa memasukkan hanya judul tiap alat ke dalam konteks, lalu dokumentasi lengkap ditambahkan per server MCP atau per alat saat diperlukan
Untuk mendapatkan efek yang sama lewat CLI, semua CLI harus menyediakan perintah seperti --short-descr
“Masalah 2: keandalan operasional rendah” juga, jika alat memakai REST API maka protokolnya mirip, jadi tidak ada alasan MCP harus lebih lambat
Jika lambat, besar kemungkinan itu masalah implementasi, misalnya MCP ditumpuk di atas API lalu dijalankan di server subkontraktor pada pusat data yang jauh
Bisa saja sebagian besar server MCP memang berantakan, tetapi itu masalah industri, bukan masalah protokol
“Masalah 3: tumpang tindih dengan CLI/API yang sudah ada” memang benar bila alat CLI sudah tersedia, dan server SQL MCP atau curl MCP memang terlihat seperti pemborosan token
Namun di sebagian besar organisasi tidak ada CLI, dan kalaupun ada, biasanya hanya API yang dirancang untuk dipakai program, bukan model bahasa besar
Ucapan “sediakan CLI → API → dokumentasi secara berurutan” terdengar seperti mengatakan bahwa alih-alih situs web yang lambat dan boros, perusahaan seharusnya lebih dulu menyediakan klien native desktop dan klien native mobile
- Saya belum mendalami bidang ini, tetapi setahu saya MCP, selain rilis Claude Code terbaru, dimuat lebih dulu ke konteks
  Jika tidak sering dibutuhkan, harus dimatikan lalu dinyalakan lagi saat perlu
  Jika contoh penggunaan dimasukkan ke file skill, panggilan --help pertama juga bisa dikurangi, dan kalau memakai CLI rasanya juga mudah menjalankan sub-agen dengan konteks terpisah lalu hanya menerima hasilnya
Tidak ada tanggal di tulisannya, tetapi disebutkan bahwa lazy tool loading adalah pembaruan terbaru yang muncul setelah artikel itu ditulis
Namun lazy tool loading ditambahkan pada November 2025: https://www.anthropic.com/engineering/advanced-tool-use
Jadi angka-angka ini setidaknya sudah berumur 7 bulan, dan saya tidak tahu kenapa ini diangkat sekarang
- Tetap terasa aneh bahwa ini masih dibahas
  Karena lazy tool loading, konteks besar, dan prompt caching, tahun 2026 sudah sepenuhnya berbeda dari 2025
  Perdebatan bahwa CLI menghemat token juga runtuh jika langkah pertama tetap menjalankan --help
  Jika cara pemanggilan tidak diingat dalam parameter, masalah bahwa itu pada akhirnya tetap harus ada di dalam konteks tidak berubah
- Bahkan terlihat seperti tulisan yang lebih lama lagi, dan menyiratkan seolah GPT-4o masih yang terbaru
- Lazy tool loading bukan bagian dari MCP
  Itu adalah parameter khusus Claude API yang tidak didukung sebagian besar API model bahasa besar lainnya
- Artikel itu bertanggal 29 Mei 2026, dan mengatakan bahwa pembaruan itu adalah perubahan “terbaru” setelah artikel tersebut adalah kebohongan agar mereka terlihat lebih baik
Sepertinya pernah ada tulisan bagus bahwa MCP cocok di tingkat organisasi ketika perlu menyediakan akses terpadu dan aman ke API utilitas internal bagi pegawai nonteknis yang memakai alat agen internal
Alur kerja dikodekan sebagai skill agar bisa dibagikan antar-instans, sedangkan hal-hal yang membutuhkan akses API sadar konteks ditangani oleh MCP
- Ini artikelnya? https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
- Kalau begitu, saya penasaran apa kelebihan MCP dibanding agen yang mengakses API secara langsung
- Saya jadi bertanya-tanya apakah ini dimaksudkan untuk menggantikan sistem otorisasi yang melindungi API
  Bagaimanapun juga, API tampaknya tetap harus punya mekanisme izin dalam bentuk apa pun
- Betul
  Itulah juga alasan perusahaan seperti Runlayer tumbuh cepat, dan tanpa control plane terpusat, MCP akan menjadi ladang ranjau
Selain poin-poin yang sudah disebut, remote MCP bersifat server-driven sehingga produsen dapat menambahkan fitur baru tanpa harus memperbarui skill dan CLI semua klien
Selain itu, remote MCP aman karena tidak membutuhkan izin mengeksekusi kode nyata di sistem lokal
Skill sering membungkus skrip dengan npx/uvx, dan ini pada dasarnya berbahaya setara dengan curl npm.com | bash
Saya pernah mengimplementasikan skill yang menghubungkan tim ke sistem manajemen internal perusahaan, dan akhirnya mendaftarkannya sebagai MCP
MCP itu sendiri sepenuhnya tidak berguna karena hanya mengekspos grep dokumentasi dan panggilan API, tetapi alasan utama memilih jalur ini adalah distribusi
Tim nonteknis menginginkan UI di mana cukup menambahkan URL maka semuanya berjalan dan OAuth dipandu, dan MCP memungkinkan itu di Claude maupun ChatGPT
Cara panggilan MCP terlihat di UI chat juga lebih baik, dan lebih jelas bagi pengguna
Daripada mengelola server MCP dan mendistribusikan CLI untuk semua platform, bagaimana kalau API diekspos lewat SSH?
SSH adalah protokol yang sempurna untuk model bahasa besar
Agen coding sudah bisa memakainya, dan ssh api@example.com list-users sudah cukup
Kemungkinan 90% pengguna sudah memasang ssh, dan baik input maupun output sama-sama teks sehingga sangat cocok untuk model bahasa besar
Ia menangani autentikasi kunci publik, output streaming, I/O interaktif, bahkan transfer file lewat scp/rsync jika diinginkan
Jika pengguna menautkan akun mereka ke Github atau GitLab, Anda bahkan bisa mengambil kunci ssh mereka dan menyiapkan autentikasi lebih dulu, sehingga mereka tinggal terhubung dan langsung masuk
- Tinggal skalakan ini ke tingkat seluruh organisasi
Analogi restoran itu kurang bagus
Bayangannya seperti “10 buku menu terbuka di meja sehingga tidak ada tempat untuk menaruh makanan, dan setiap kali memesan kita harus mengeluarkan buku menu lagi”, padahal pesanan berulang tidak umum kecuali itu restoran tapas
Makanan juga bisa diletakkan di atas buku menu, dan biasanya setelah memesan buku menu disingkirkan agar meja, yaitu konteks, menjadi kosong
Jika ingin menjelaskan dengan analogi, perlu usaha untuk membuatnya lebih relevan