Saya Masih Lebih Memilih MCP daripada Skills

• MCP adalah antarmuka standar berbasis abstraksi API yang memungkinkan LLM meminta suatu tugas tanpa harus mengetahui struktur internal alat, serta mendukung penggunaan jarak jauh dan pembaruan otomatis
• Melalui arsitektur zero-install, autentikasi OAuth, dan keamanan sandboxing, MCP mengurangi beban instalasi dan persoalan perizinan, serta menyediakan lingkungan yang sama di platform apa pun
• Sebaliknya, Skills menimbulkan banyak friksi di lingkungan eksekusi nyata karena ketergantungan pada instalasi CLI, kompleksitas autentikasi dan deployment, serta masalah kompatibilitas antarplatform
• Skills harus diposisikan sebagai lapisan pengetahuan, sedangkan MCP sebagai lapisan koneksi; saat LLM berinteraksi dengan sistem eksternal gunakan MCP, dan untuk penyampaian pengetahuan prosedural gunakan Skills
• Dengan layanan cloud tunneling seperti MCP Nest, server MCP lokal dapat diakses dari jarak jauh, sehingga dinilai sebagai inti untuk membangun lingkungan integrasi AI yang terstandarisasi

---

Kelebihan MCP

• Model Context Protocol (MCP) didasarkan pada struktur abstraksi API yang memungkinkan LLM menjalankan tugas hanya dengan mengirim permintaan, tanpa perlu memahami cara kerja internal alat
  • Contoh: saat LLM berinteraksi dengan DEVONthink, ia cukup memanggil devonthink.do_x() dan server MCP menangani seluruh prosesnya
• Penggunaan jarak jauh tanpa instalasi dimungkinkan; klien cukup menentukan URL server MCP dan bisa langsung berfungsi tanpa instalasi tambahan
• Pembaruan otomatis didukung; ketika server MCP jarak jauh diperbarui dengan alat atau resource baru, semua klien dapat langsung menggunakan versi terbaru
• Autentikasi berbasis OAuth memperkuat keamanan, dan pengguna tidak perlu mengelola token secara manual
• Portabilitasnya tinggi, sehingga dapat diakses melalui server MCP yang sama di lingkungan apa pun seperti Mac, mobile, maupun web
• Dengan arsitektur sandboxing, hak eksekusi langsung terhadap lingkungan lokal dibatasi dan hanya antarmuka yang terkontrol yang diekspos
• Melalui fitur pencarian cerdas dan pembaruan otomatis, hanya alat yang diperlukan yang dimuat, dan bahkan pada instalasi lokal pembaruan bisa dilakukan otomatis saat dijalankan

Batasan dan Friksi pada Skills

• Skills berguna untuk mengajarkan pengetahuan atau cara penggunaan tertentu kepada LLM, tetapi saat harus menjalankan tindakan nyata, ketergantungan pada CLI menjadi masalah
• Sebagian besar Skill memerlukan instalasi CLI terpisah, tetapi versi web seperti ChatGPT, Perplexity, dan Claude tidak dapat menjalankan CLI
• Akibatnya, muncul masalah-masalah berikut
  • Kompleksitas deployment: CLI harus didistribusikan dan dikelola sebagai binary, NPM, uv, dan sebagainya
  • Masalah pengelolaan rahasia: token autentikasi disimpan dalam teks polos di file .env, atau autentikasi hilang saat sesi diinisialisasi ulang
  • Ekosistem yang terputus: cara instalasi dan pembaruan Skill berbeda-beda di tiap platform, sehingga menimbulkan masalah kompatibilitas dan error parsing YAML
  • Pemborosan konteks: meskipun LLM hanya memerlukan satu pemanggilan fungsi, seluruh SKILL.md tetap harus dimuat
• Skill yang berisi instruksi “instal CLI terlebih dahulu” menambahkan kompleksitas yang tidak perlu, dan lebih efisien jika digantikan dengan MCP jarak jauh

Kriteria Memilih Alat yang Tepat

• Kapan menggunakan MCP: saat LLM perlu terhubung ke sistem eksternal seperti situs web, layanan, atau aplikasi, MCP digunakan sebagai antarmuka standar
  • Contoh: Google Calendar seharusnya menangani autentikasi dan eksekusi melalui MCP jarak jauh berbasis OAuth, tanpa menuntut instalasi CLI
  • Untuk Chrome, Hopper, Xcode, Notion, dan lainnya, idealnya masing-masing menyediakan endpoint MCP bawaan untuk mengendalikan fungsinya
• Kapan menggunakan Skills: harus difokuskan pada penyampaian pengetahuan murni dan pemberian konteks
  • Untuk mengajarkan cara menggunakan alat yang sudah terpasang (curl, git, gh, gcloud)
  • Untuk standarisasi istilah internal organisasi, alur kerja, dan gaya penulisan
  • Untuk berbagi pengetahuan prosedural seperti pemrosesan PDF atau pengelolaan rahasia (misalnya cara menggunakan fnox)
• Skills harus dipandang sebagai lapisan pengetahuan, dan MCP sebagai lapisan koneksi

Konektor dan Manual

• Untuk memperjelas peran Skills dan MCP, diajukan usulan agar Skills disebut manual LLM (LLM_MANUAL.md), sedangkan MCP disebut konektor (Connector)
• Contoh yang benar-benar digunakan dalam operasi
  • mcp-server-devonthink: server MCP lokal yang memungkinkan LLM mengendalikan DEVONthink secara langsung
  • microfn: menyediakan MCP jarak jauh di mcp.microfn.dev
  • Kikuyo: menyediakan MCP jarak jauh di mcp.kikuyo.dev
  • MCP Nest: layanan yang memungkinkan akses jarak jauh ke server MCP lokal dengan men-tunnel-kannya ke cloud (mcp.mcpnest.dev/mcp)
• Beberapa proyek juga menyediakan Skill untuk CLI, tetapi Skill yang menjelaskan cara menggunakan MCP justru lebih berguna
  • Skill berfungsi sebagai lapisan pengetahuan yang menjelaskan fungsi MCP, hubungan antaralat, dan kapan harus menggunakannya
  • MCP bertanggung jawab atas koneksi dan eksekusi yang sebenarnya
• Dengan kombinasi ini, LLM dapat memanfaatkan MCP secara efisien tanpa trial-and-error berulang

Penggunaan MCP dan Skill Secara Berdampingan

• Pola-pola yang tidak intuitif yang ditemukan saat menggunakan MCP, seperti kesalahan format tanggal atau keterbatasan pencarian, dirangkum ke dalam Skill untuk digunakan kembali
• Skill yang dibuat dengan cara ini berperan sebagai cheat sheet untuk MCP, membantu LLM bekerja dengan tepat tanpa pemborosan token yang tidak perlu
• Melalui folder .claude/skills, panduan perilaku AI per proyek dapat dipertahankan, dan prosedur yang sering dipakai dapat dikelola dalam bentuk dotfiles
• Masa depan integrasi AI bergantung pada antarmuka yang terstandarisasi (MCP), dan pendekatan terfragmentasi berbasis CLI sebaiknya dihindari
• Diharapkan layanan besar seperti Skyscanner, Booking.com, Trip.com, dan Agoda.com akan menyediakan MCP resmi

Pengenalan MCP Nest

• MCP Nest adalah layanan yang memungkinkan server MCP yang semula hanya dapat digunakan secara lokal (seperti Fastmail, Gmail, dan lain-lain) diakses dari jarak jauh melalui cloud tunneling
• Dapat digunakan secara sama pada klien yang mendukung MCP seperti Claude, ChatGPT, dan Perplexity
• Tanpa mengekspos mesin lokal secara langsung, pengguna dapat mempertahankan lingkungan MCP yang sama di semua perangkat

[jujumilk3]

Keduanya memang sejak awal berbeda sama sekali, jadi kenapa pembicaraan seperti ini terus muncul ya

[xguru]

Karena saya harus mempromosikan MCP Nest di bagian akhir tulisan.. hehe. Sepertinya banyak klaim perbandingan seperti itu yang makin mendapat dukungan.

[jjw9512151]

Skills itu ilmu pedang, sedangkan MCP itu pedangnya.. Kegunaannya berbeda, dan keduanya sama-sama diperlukan

[ide127]

Skills dan MCP punya peran yang berbeda, tetapi sepertinya tulisan-tulisan seperti ini terus menimbulkan kebingungan.

[ide127]

Apalagi di industri AI yang sudah kacau ini, para penginjil palsu berkeliaran di mana-mana

[GN⁺]

Komentar Hacker News

• Yang ingin saya tekankan adalah bahwa alih-alih fokus pada preferensi pribadi, kita harus fokus pada desain alat yang dibutuhkan agar LLM bisa bekerja secara optimal
  MCP justru menambah friksi. Misalnya, jika Anda menangani sistem embedded, buat saja antarmuka pemantauan berbasis CLI yang memungkinkan LLM langsung melakukan debugging, reset, menjalankan emulator, dan sebagainya, lalu dokumentasikan cara pakainya dalam file skill
  Untuk pekerjaan sederhana, MCP tidak diperlukan. Misalnya git atau menghitung biaya AWS sudah sangat dikuasai LLM. Hanya sistem yang kompleks saja yang efisien jika kita membuat dan mendokumentasikan alatnya sendiri

  • Rasanya diskusi MCP mencampuradukkan terlalu banyak konsep. Intinya adalah persistensi sesi
    Jika hanya sekali pakai, CLI atau API sudah cukup, tetapi jika perlu akses berkelanjutan, server MCP berguna
    MCP yang tersusun rapi memberi tahu agen cara pakainya tanpa memboroskan prompt. Meniru akses berkelanjutan dengan file skill itu tidak efisien. MCP adalah cara paling efektif untuk mengintegrasikan alat eksternal ke dalam sesi agen
  • MCP dan skill adalah hubungan saling melengkapi. Melihat keduanya sebagai sesuatu yang berlawanan adalah kesalahpahaman
  • Rantai alat LLM saat ini tampak seperti masa transisi yang belum terstandarisasi. Alih-alih menaruh informasi di berbagai tempat seperti .md atau skill, kita memerlukan standar yang merapikannya ke lokasi optimal melalui loop refleksi diri yang otomatis
  • Saya juga memakai pendekatan serupa. Sebagian besar alat CLI langsung dibuat oleh Claude, dan saya hampir tidak pernah memakai IDE
    Bahkan fitur refactoring JetBrains saya ganti dengan skrip, sehingga kecepatan sesi turun dari 5 menit menjadi 10 detik
    Sampai sekarang saya sama sekali belum memakai MCP. Kombinasi REST + Swagger + codegen + Claude + skill sudah cukup
  • Kelebihan MCP adalah kontrol izin. Misalnya, jika Anda tidak ingin AI punya izin menulis ke git, Anda bisa membatasi cakupan yang diekspos lewat MCP. Hanya dengan READ_ONLY_SKILL saja tidak cukup

• Pada akhirnya perdebatan ini adalah soal pengembang individu vs kolaborasi skala organisasi
  Jika Anda sendirian dan ingin loop umpan balik yang cepat, CLI lebih baik; jika Anda butuh kontrol dan konsistensi di tingkat organisasi, MCP lebih cocok
  Saat ini MCP memang banyak memakan konteks, tetapi akan diperbaiki dengan metode pengungkapan bertahap

  • Di organisasi ada masalah bahwa kontrol akses MCP itu sulit. Jika manusia keliru menghapus dua hal mungkin masih bisa ditoleransi, tetapi agen bisa menghapus ribuan hal dalam sekejap. CLI aman karena cakupan aksesnya bisa dibatasi
  • Pemborosan konteks adalah masalah implementasi klien. Pemuatan bertahap bisa dilakukan tanpa mengubah spesifikasi
  • MCP dan CLI adalah alat dengan tujuan berbeda, dan paling kuat bila dipakai bersama

• Saya ingin agen yang memakai alat CLI yang sudah ada apa adanya, bukan API
  Saya sudah memakai CLI secara lokal, jadi tidak ada alasan untuk menambahkan MCP. Saya juga tidak ingin model jarak jauh
  Jika perlu memanggil API, skill sudah cukup

  • Saya juga langsung menaruh perintah curl ke dalam skill untuk memanggil API kustom. LLM sangat andal untuk hal seperti ini
  • Tetapi untuk manajemen secret key, MCP lebih aman. Jika server MCP dijalankan lebih dulu, kunci tidak terekspos ke lingkungan agen
  • MCP berperan sebagai lapisan batas keamanan antara agen dan dunia luar. Tidak selalu diperlukan, tetapi berguna
  • Di lingkungan tertentu, LLM mungkin tidak punya hak akses ke CLI. Dalam kasus seperti itu, pemanggilan CLI berbasis skill menjadi tidak berguna
  • Ada juga masalah autentikasi (authn) dan otorisasi (authz). MCP bisa mengontrolnya sebagai middleware

• MCP dan Skill bukan hubungan zero-sum
  MCP menangani antarmuka terstandarisasi di lapisan infrastruktur, sedangkan Skill menangani konteks perilaku yang spesifik per proyek
  Jika digabungkan, Anda bisa mendapatkan stabilitas sekaligus fleksibilitas

  • Pada akhirnya MCP hanyalah bentuk pembungkus CLI. Bahkan MCP punya overhead konteks yang lebih besar
  • Beberapa MCP berbayar memang benar-benar bernilai. Misalnya MCP untuk pencarian web lebih nyaman daripada menjalankan crawler sendiri
  • Pada agen yang di-host di cloud, kombinasi Skill + MCP adalah struktur kunci. Autentikasi dan pengelolaan dependensi jadi lebih mudah
  • Penulis juga mendukung kombinasi ini. MCP punya portabilitas tinggi sehingga bisa dipakai dengan cara yang sama di ChatGPT, Claude, Perplexity, dan lain-lain
  • Skill bisa diabaikan oleh LLM, tetapi kebijakan MCP punya daya paksa di sisi server

• Sebagian besar diskusi berpusat pada orang-orang yang menjalankan agen coding secara lokal
  Di lingkungan seperti itu Skill lebih nyaman, tetapi pengguna umum memakai layanan berbasis cloud seperti ChatGPT
  Dalam kasus ini MCP menjadi pilihan default. Kekuatan utamanya adalah autentikasi dan akses jarak jauh

  • Tetapi ada yang menganggap MCP tidak lebih dari wrapper API yang berisik
    Anda harus menjalankan server, dan bagi LLM itu justru menjadi beban. Skill mengenkode dokumentasi API agar ramah untuk LLM, sehingga lebih sederhana
  • Ada juga bantahan bahwa klaim “sebagian besar pengguna tidak memakai agen lokal” membutuhkan dasar
  • Ada juga lelucon yang mengoreksi salah ketik ‘agronomic’ menjadi ‘ergonomic’

• Saya lebih menyukai Skill. Alasannya, Skill bisa langsung memanfaatkan kembali alat CLI yang dipakai manusia
  Skill adalah dokumen yang bisa dibaca dan ditulis manusia, sehingga LLM dan manusia berbagi alat yang sama
  Sebaliknya, MCP mengharuskan dibuatnya API baru khusus LLM, dan dokumentasinya juga harus dikelola terpisah
  Skill hanya dimuat saat diperlukan sehingga menjaga konteks tetap rapi

• Orang yang berargumen “hanya Skill” biasanya nonteknis, sedangkan yang bilang “hanya CLI” seringnya pengembang individu
  MCP cocok untuk lingkungan enterprise. Ia menstandarkan autentikasi dan antarmuka

  • Banyak orang bersikap negatif terhadap MCP karena ketidakstabilan JIRA MCP. Skill berbasis acli lebih stabil
  • Saya sendiri membangun MCP internal untuk perusahaan. Saya pasangkan autentikasi Google Workspace agar Claude bisa dengan aman melihat data internal atau melakukan deployment aplikasi
    MCP mudah diperbarui dan dideploy sehingga aksesibilitasnya tinggi bahkan untuk nonteknis
  • Ada juga pendapat bahwa perusahaan sudah punya sistem autentikasi internal, jadi CLI lebih baik
    Pada akhirnya MCP tidak lebih dari subset API yang distrukturkan
  • MCP bisa dijalankan dengan cepat. Rangkaian Codex → LiteLLM → VLLM → MCP bisa siap hanya dalam beberapa menit
  • Saya menganggap sistem SaaS yang ada sebagai legacy
    Basis data SQL lokal lebih efisien daripada API yang sulit untuk akses data
    MCP hanyalah satu lagi protokol RPC, dan masalah autentikasi pun masih belum terselesaikan

• Saya melihat MCP diperlukan karena irasionalitas manusia
  Banyak organisasi masih tidak menyediakan API atau CLI. MCP menutup keterputusan digital semacam ini
  Dalam perusahaan, rantai pelaporan atau struktur politik menghambat otomatisasi, dan MCP bisa mem-bypass hal tersebut

  • Saya juga setuju. Jika agen rekan kerja bisa berkolaborasi sebagai pengganti mereka, digitalisasi organisasi akan jauh lebih mudah. MCP bagus karena menyembunyikan kerumitan wiring seperti ini

• Skill punya masalah context bloat karena seluruh dokumen harus dimasukkan ke konteks
  MCP juga mirip, tetapi dengan fitur penemuan alat, pemuatan bertahap dimungkinkan
  Masalah yang lebih besar adalah output MCP langsung masuk ke konteks agen. Jika layanan MCP dipanggil lewat CLI, pemfilteran atau caching bisa dilakukan

  • Ada juga respons, “kalau begitu kenapa tidak pakai HTTP request saja?”
  • Penulis menjelaskan bahwa MCP terbaru sudah menyelesaikannya dengan lazy loading berbasis penemuan alat. Claude Code memakai subagen untuk mencegah log membludak
  • Saya menyelesaikannya dengan membungkus MCP lokal memakai cache memori. Setiap output alat diberi ID, lalu alat lain dipanggil menggunakan ID tersebut. Ini efektif untuk menghemat token dan meningkatkan kecepatan

• Skill bagus untuk memuat pengetahuan intuitif, sedangkan MCP cocok untuk otomatisasi yang dapat diulang
  Jika LLM menulis skrip yang sama berulang kali, akan lebih efisien jika itu dijadikan alat tetap

  • Sebagian besar proses sebaiknya dipraproses dengan skrip, dan LLM hanya terlibat dalam perencanaan serta verifikasi
    Jadi, kuncinya adalah mempraproses sebanyak mungkin dengan skrip
  • Skrip juga bisa langsung disertakan di dalam skill. skill bisa memuat kode juga
  • Penulis asli menjelaskan bahwa tulisan tersebut ditulis oleh orang sungguhan di dalam pesawat, bukan oleh AI
  • Ada juga yang bilang mereka memakai skill untuk pekerjaan berulang, lalu diskusi berlanjut dari sudut pandang kontrak API MCP
    Jika hanya skrip kecil, cukup taruh di konteks lalu katakan, “pakai ini”