MCP Dijelaskan: Cara Kerja Model Context Protocol

LLM sudah dapat memanggil tool selama beberapa waktu, tetapi Model Context Protocol (MCP) menghadirkan cara yang terstruktur dan terstandar untuk melakukannya.

Namun, masih ada kebingungan tentang apa sebenarnya MCP itu.

Banyak orang mengira MCP adalah aplikasi, API, atau tool tertentu, tetapi bukan salah satunya. MCP adalah protokol, dan itu berarti sesuatu yang sangat spesifik.

Mari kita uraikan.

Jika Anda hanya ingin melihat apa yang dibuka oleh MCP dalam praktik, lihat video singkat ini:

Apa itu protokol?

Protokol hanyalah sekumpulan aturan yang menentukan cara dua sistem atau lebih berkomunikasi satu sama lain.

Protokol tidak melakukan apa pun dengan sendirinya. Protokol hanya menentukan struktur dan ekspektasi percakapan antara dua entitas. Anggap saja sebagai bahasa bersama dengan aturan tata bahasa yang ketat yang diikuti komputer untuk bertukar informasi.

Sistem pos melakukan hal serupa. Semua kantor pos di negara tertentu mengikuti format alamat standar untuk mengirim surat.

Atau anggap seperti USB-C untuk tool AI. Dua puluh tahun lalu, pasar dipenuhi berbagai jenis kabel pengisian daya dan data. Sama seperti ekosistem AI yang memiliki beberapa cara untuk meneruskan tool ke model bahasa. Framework seperti LangChain, Haystack, dan Pydantic AI semuanya menentukan formatnya sendiri untuk mengintegrasikan tool, yang berarti jika developer ingin menulis toolset untuk Google Maps, mereka harus melakukannya untuk setiap teknologi tertentu.

Agar lebih konkret, mari kita lihat protokol paling populer, HTTP (Hypertext Transfer Protocol), yang menjalankan situs web. HTTP menentukan, antara lain, bagaimana browser (client) meminta halaman web dari server web dan bagaimana server harus merespons.

Berikut contoh siklus permintaan-respons HTTP:

1. Browser membuat permintaan HTTP

Saat Anda mengetik https://example.com di browser, browser mengirim permintaan HTTP terstruktur ke server web:

Berikut parameter dan nilai HTTP yang digunakan dalam contoh kita:

"GET" – Ini adalah tindakan (meminta halaman web).
"/index.html" – Halaman web spesifik yang diminta.
"HTTP/1.1" – Versi protokol yang digunakan.
"Host: example.com" – Nama domain situs web.
"User-Agent: Mozilla/5.0" – Informasi tentang browser yang membuat permintaan.

Server web tahu cara menafsirkan permintaan ini karena HTTP menstandarkan format ini. Server memahami “bahasa” ini.

2. Server Merespons Menggunakan Protokol HTTP

Server memproses permintaan dan mengirim kembali respons HTTP terstruktur:

"HTTP/1.1 200 OK" – Kode respons (200 berarti berhasil).
"Content-Type: text/html" – Jenis konten yang dikirim kembali.
"Content-Length: 512" – Ukuran respons.
HTML Content – Konten halaman web yang sebenarnya (hanya ada judul "Selamat datang di Example.com")

Penting: HTTP sendiri tidak menyimpan halaman web atau menampilkannya. HTTP hanya menentukan aturan tentang bagaimana browser web dan server web boleh berkomunikasi. Sistem apa pun yang mengikuti aturan tersebut dapat berkomunikasi melalui Internet yang didefinisikan oleh HTTP.

Cara MCP bekerja sebagai protokol

Sekarang, mari kita terapkan cara berpikir yang sama pada MCP (Model Context Protocol).

MCP adalah protokol bagi agent AI untuk berbicara dengan tool dan sumber data eksternal. Seperti HTTP, MCP tidak menyimpan data atau mengeksekusi tugas sendiri. MCP hanya menentukan cara terstandar bagi AI untuk meminta dan mengambil informasi dari tool.

Apa yang dimaksud dengan “tool” tersebut?

Dalam konteks LLM, tool adalah sistem eksternal, API, atau layanan yang dapat berinteraksi dengan AI untuk memperluas kemampuannya melampaui pembuatan teks saja. Tool memungkinkan agent AI mengambil data real-time, membuat janji temu, atau mengirim pesan ke teman Anda, sehingga jauh lebih berguna untuk kebutuhan dunia nyata.

Misalnya Anda bertanya kepada agent AI:

“Sekarang jam berapa di London?”

Karena AI itu sendiri tidak mengetahui jawaban yang benar, karena model AI memiliki tanggal batas pengetahuan (Oktober 2023 untuk model OpenAI), AI perlu mengambil data langsung dari layanan waktu. Namun, alih-alih menggunakan HTTP untuk meminta halaman web, AI menggunakan MCP untuk meminta data waktu.

Berikut yang terjadi:

1. Agent AI membuat permintaan MCP ke layanan waktu (contoh)

"method": "tools.call" → AI memanggil tool eksternal.
"tool": "get_time" → Nama tool yang ingin digunakan.
"args": { "location": "London" } → Parameter input spesifik.

Sama seperti dalam HTTP, permintaan ini mengikuti format yang ketat sehingga tool apa pun yang kompatibel dengan MCP tahu persis cara menafsirkannya.

2. Server waktu MCP merespons

Tool eksternal (server waktu) mengikuti aturan respons MCP dan mengirim kembali:

"status": "success" → Mengonfirmasi bahwa permintaan diproses dengan benar.
"result" → Berisi data waktu yang sebenarnya.

Sekarang, agent AI dapat mengambil data ini dan menyusun respons aktual kepada pengguna dengan:

“Waktu saat ini di London adalah 12:20 PM (GMT).”

Untuk merangkum dan menghilangkan kebingungan:

“MCP adalah aplikasi.” → Bukan, MCP adalah sekumpulan aturan. Anda memerlukan software AI dan tool yang mengimplementasikan MCP untuk benar-benar menggunakannya, sama seperti aplikasi Instagram memerlukan server Instagram yang aktif untuk merespons permintaan HTTP dan mengirimkan data.

“MCP adalah database.” → Bukan, MCP tidak menyimpan data. MCP membantu agent AI berbicara dengan database atau API.

“MCP seperti API.” → Tidak persis. API adalah cara spesifik untuk berinteraksi dengan satu sistem, sedangkan protokol (seperti MCP atau HTTP) menentukan cara universal agar banyak sistem berbeda dapat berkomunikasi. MCP adalah bahasa yang dapat digunakan sistem AI untuk berinteraksi dengan banyak API aktual (waktu, database, Stripe, Slack, dan sebagainya).

Mengapa MCP menarik

Sekarang kita tahu bahwa MCP adalah cara terstandar bagi software AI untuk berinteraksi dengan tool dan aplikasi eksternal, dan bahwa MCP bukan API, mari kita pahami mengapa komunitas developer AI (termasuk kami) tertarik dengannya.

Karena MCP bukan API, melainkan memungkinkan aplikasi AI berinteraksi dengan API aktual dalam skala besar, MCP membantu proyek yang perlu terhubung ke banyak sistem eksternal dimulai lebih cepat. Tool juga memberi model jangkauan, dan yang terjadi dalam insiden OpenAI Hugging Face adalah gambaran ketika jangkauan itu melampaui tugasnya. Untuk melakukan ini, developer terkadang perlu melalui siklus pengembangan integrasi API penuh, tetapi saat ini mereka biasanya menggunakan library yang sudah ada atau proyek open-source (misalnya, tersedia di GitHub) yang menyediakan fungsi yang dibutuhkan.

Menggunakan library ini mempercepat awal pengembangan, tetapi mengintegrasikannya dengan benar ke sistem Anda (jika tidak kompatibel dengan implementasi yang Anda temukan di GitHub) tetap membutuhkan upaya agar tool bekerja dengan AI.

Dengan MCP, setelah framework tersedia, menambahkan integrasi baru (misalnya, mengintegrasikan Google Drive) mungkin hanya soal menghubungkan ke server MCP Google Drive dengan beberapa baris kode. Anda tidak akan menghadapi masalah kompatibilitas karena keduanya menggunakan protokol yang sama: MCP.

Mari kita bandingkan kedua pendekatan untuk melihat perbedaannya dengan lebih jelas.

Integrasi standar vs. menggunakan Model Context Protocol (MCP)

Agar perbandingan ini konkret, mari kita telusuri penambahan akses file Google Drive ke AI Agent, pertama secara manual lalu dengan tool yang kompatibel dengan MCP.

Integrasi standar

1. Temukan dan adaptasi library: Anda mencari client Google Drive API atau proyek open-source. Google menyediakan client library (misalnya Google Drive API untuk Python), lalu Anda memasukkannya ke proyek Anda. Anda tetap perlu memastikan library tersebut bekerja dengan lingkungan AI Anda.

2. Implementasikan logika: Anda menulis fungsi untuk, misalnya, mencari file atau mengambil dokumen dari Drive. Saat AI membutuhkan sesuatu, AI harus memanggil fungsi ini. Anda memformat permintaan AI menjadi panggilan API khusus Google Drive. Setelah mendapatkan respons dari Google, Anda mengekstrak konten untuk dikembalikan ke konteks AI.

3. Tangani error dan edge case: Tambahkan kode untuk menangani kasus seperti “file tidak ditemukan,” error izin, atau batas laju API. Jika API Google mengembalikan error, Anda menangkapnya dan mungkin merespons dengan pesan permintaan maaf atau meminta AI merumuskan ulang. Anda juga perlu mencegah AI mengirim terlalu banyak permintaan terlalu cepat.

4. Pelihara: Seiring waktu, jika Google memperbarui API atau library mereka, Anda harus memperbarui kode Anda. Jika Anda menemukan bug di library, Anda mungkin harus menambal atau mencari sumber lain. Pada dasarnya, Anda menjadi maintainer integrasi Google Drive ini di dalam aplikasi AI Anda.

Proses ini berlaku untuk tool lain: ingin menambahkan Slack atau database ke AI Anda? Anda perlu mengulangi seluruh proses untuk masing-masing.

Integrasi MCP

Sekarang mari kita lihat bagaimana proses itu terlihat saat menggunakan MCP.

Pertama, mari kita definisikan konsep utama:

Client – aplikasi AI (ChatGPT, aplikasi Claude, Quickchat AI) yang membuat koneksi ke satu atau beberapa server dan meminta informasi atau tindakan untuk menjalankan tugas yang diminta pengguna.

Server – Setiap server dapat terhubung ke sesuatu seperti database, API (Google Drive) dan menentukan sekumpulan “tool” atau data yang dapat disediakannya. Dalam hal ini, server adalah program yang mengekspos tool dan kemampuan ini kepada Client (aplikasi AI).

Developer, tergantung pada apa yang ingin mereka lakukan, dapat memilih berada di salah satu sisi: membangun server untuk mengekspos data, atau membangun client AI yang dapat berbicara dengan server apa pun. Sebagian besar menginginkan opsi kedua, tetapi tetap mari kita mulai dari sisi server untuk memahami cara kerja MCP langkah demi langkah:

• Menginisialisasi server MCP. Developer atau admin sistem menyiapkan server MCP untuk tool atau sumber data tertentu. Server MCP biasanya hanya program kecil yang mengimplementasikan spesifikasi MCP. Misalnya, ada server Google Drive MCP siap pakai yang tersedia dan tahu cara mencari serta mengambil dokumen.

  Saat menginisialisasi server, Anda memberinya akses ke sistem target (Google Drive). Server kemudian mengekspos sekumpulan tool yang sesuai dengan tindakan atau query yang dapat ditanganinya. Pada dasarnya, ini adalah adapter API yang berbicara MCP di satu sisi dan layanan native di sisi lain.

  Setelah server berjalan, server menunggu permintaan.

• Menghubungkan LLM (client) ke server MCP. Selanjutnya, aplikasi AI (sisi “client”) perlu terhubung ke server tersebut. Dalam praktiknya, jika Anda menggunakan platform AI yang mendukung MCP (seperti Claude Desktop), Anda akan mengonfigurasinya dengan alamat atau perintah untuk memulai server. Setelah terhubung, client membuat sesi dengan server mengikuti handshake MCP. Jika Anda menggunakan antarmuka Claude, Anda akan melihat bahwa Claude “terhubung” ke server MCP tertentu (UI mungkin menunjukkan connector yang tersedia).

Begitulah tampilannya di Claude UI

• Menemukan tool yang tersedia. Setelah koneksi dibuat, hal pertama yang dilakukan adalah mencari tahu apa yang ditawarkan server (kadang-kadang, ini terjadi otomatis setelah Anda terhubung ke server). Client MCP mengirim permintaan tools/list ke server (ini ditentukan dalam protokol). Server membalas dengan daftar tool yang tersedia, masing-masing dengan detail seperti nama, deskripsi, dan skema input.

  Misalnya, server mungkin merespons bahwa ia memiliki tool create_file(path, content), read_file(path), dan search_files(query) yang tersedia. Client kemudian membuat informasi ini tersedia bagi LLM. Dalam banyak implementasi, client akan memformat deskripsi tool ini dan menyertakannya dalam konteks model (misalnya, menambahkan ke system prompt: “Anda memiliki akses ke tool berikut… [daftar tool]”).

Berikut system prompt AI bersama pesan pengguna yang meminta waktu saat ini

Dengan tool MCP yang diimplementasikan, tool bernama “get_current_time” diintegrasikan, memungkinkan AI mengakses sumber daya eksternal dan mengambil waktu yang tepat di London

Ini berarti Anda tidak perlu memikirkan dan memprogram terlebih dahulu semua tindakan potensial yang mungkin dibutuhkan aplikasi AI Anda untuk menyelesaikan suatu tugas. Dengan MCP, AI dapat menemukan semua tindakan yang mungkin secara langsung dengan bertanya kepada server MCP dan memilih apa pun yang diperlukan.

• Menggunakan tool melalui MCP. Saat AI perlu melakukan tindakan atau mengambil data, AI akan memanggil tool melalui MCP. Dari perspektif AI (terutama untuk model seperti Claude yang secara native mendukung penggunaan tool), AI akan memutuskan dalam penalarannya: “Saya harus memanggil tool X dengan parameter ini.” Client MCP menangkap niat tersebut dan mengirim permintaan tools/call dalam format MCP ke server yang sesuai (server MCP Google Drive).

• Server MCP bertindak sebagai jembatan. Server menerima permintaan terstruktur yang sesuai MCP dari agent AI, memetakannya ke endpoint Google Drive API yang benar, menulis ulang permintaan menjadi panggilan Google Drive API aktual, mengeksekusi permintaan, memproses respons, dan memformat ulangnya menjadi respons yang sesuai MCP lagi sebelum mengirimkannya kembali ke agent AI.

  Hal yang perlu dicatat adalah bahwa server MCP mengikuti pendekatan terstruktur untuk menangani error, memastikan bahwa AI Agents dapat menafsirkan dan menindaklanjutinya secara efektif.

  Misalnya AI Agent menggunakan tool MCP untuk menemukan file di Google Drive. Jika permintaan menyertakan ID file yang tidak valid (misalnya, string sepanjang lima karakter alih-alih format yang diharapkan), server MCP akan mengembalikan pesan error:

  Alih-alih gagal begitu saja, AI Agent dapat mengambil respons terstruktur ini dan merumuskannya ulang menjadi umpan balik yang ramah pengguna:

  “Sepertinya ID file yang Anda berikan terlalu pendek. ID file Google Drive biasanya sepanjang 28 karakter. Bisakah Anda memeriksanya kembali dan mencoba lagi?”

  Pendekatan ini memastikan bahwa error tidak menjadi jalan buntu, melainkan menjadi kesempatan bagi AI Agent untuk membimbing pengguna menuju penyelesaian yang berhasil.

• Menjawab pertanyaan/permintaan pengguna. Setelah server MCP mengembalikan hasil, client MCP menyerahkan data tersebut kembali ke aplikasi AI. Model kemudian memasukkan hasil itu ke dalam penalarannya atau langsung ke output yang dibuatnya untuk pengguna.

  Jika pengguna meminta pembuatan file Google Sheets baru, balasan server (yang berisi ID file dan tautan yang dibuat) akan diteruskan ke model. Model kemudian akan merespons pengguna dengan: “Kabar baik! File Google Sheets baru Anda sudah siap. Anda dapat mengaksesnya di sini: [link].”

Sepanjang proses ini, AI tetap mengendalikan alur: AI memutuskan kapan memanggil tool dan bagaimana menggunakan hasilnya dalam membentuk jawaban. Sementara itu, developer tidak perlu mengorkestrasi langkah-langkah ini secara manual, framework MCP dan model AI menanganinya. Hasil akhirnya adalah pengguna dapat meminta AI menjawab pertanyaan atau menjalankan tugas kompleks yang membutuhkan informasi atau tindakan eksternal, dan AI dapat melakukannya secara otonom melalui MCP lalu mengembalikan hasil.

Manfaat menggunakan MCP

Perhatikan bagaimana pendekatan ini mengabstraksi banyak detail: client tidak menangani API key atau kode status HTTP, itu ditangani oleh server MCP.

Poin utamanya adalah kesederhanaan pada titik integrasi: kita “meminta” pelanggan, dan kita mendapatkannya. Logika tentang cara mengambilnya dikapsulkan di tempat lain. Artinya, developer yang bekerja di sisi AI tidak perlu menulis panggilan HTTP baru untuk setiap tindakan baru, mereka cukup memanggil tool berdasarkan nama. Pekerjaan berat (auth, memanggil endpoint Google Drive, memformat respons) dilakukan dalam kode server MCP, yang dapat digunakan ulang dan terstandar.

Berikut ringkasan manfaat utamanya:

• Mengurangi glue code khusus API. Sebelum MCP, membuat AI menggunakan layanan eksternal biasanya mengharuskan penulisan banyak kode “glue”: memanggil API, mengubah respons menjadi teks yang dapat dicerna model, lalu mengurai output model untuk mungkin memanggil API lain, dan seterusnya. Dengan MCP, sebagian besar glue tersebut dihilangkan. Client model dan server menangani pertukaran data secara terstruktur, sehingga Anda tidak perlu mengubah format lain (seperti JSON) menjadi teks atau sebaliknya secara manual, protokol melakukannya. Anda juga tidak perlu menulis logika untuk memutuskan kapan memanggil apa. AI (dipandu oleh deskripsi tool dan penalaran atau prompt-nya sendiri) melakukannya.

• Connector bersama yang dapat digunakan ulang, bukan wrapper API sekali pakai. Dengan MCP, Anda menulis integrasi sekali dan dapat menggunakannya kembali di banyak proyek dan sistem AI. Misalnya, Anda dapat membuat server MCP untuk wiki internal perusahaan Anda. Aplikasi AI apa pun yang mendukung MCP dapat terhubung ke server tersebut untuk meng-query wiki. Anda tidak perlu mengimplementasikan ulang “pencarian wiki” untuk setiap chatbot AI baru atau setiap vendor LLM yang berbeda. Kemampuan penggunaan ulang ini adalah pergeseran dari masa lalu ketika setiap tim mungkin menulis integrasinya sendiri yang sedikit berbeda untuk API yang sama. MCP mendorong library connector yang dapat dibagikan dan ditingkatkan bersama.

• Integrasi plug-and-play dengan LLM yang berbeda. MCP bersifat model-agnostic. Protokol tidak peduli apakah client-nya Claude, GPT-4, DeepSeek, atau model masa depan apa pun, selama client dapat menangani antarmuka MCP. Di masa depan, jika Anda ingin beralih ke model lain, Anda dapat melakukannya tanpa menulis ulang semua integrasi Anda.

• Pemeliharaan lebih mudah. Karena MCP adalah standar terbuka, ada komunitas yang berkembang yang berkontribusi pada server siap pakai (untuk database, API populer, dan sebagainya) yang dapat Anda manfaatkan alih-alih membangun dari nol. Saat Anda mengintegrasikan lebih banyak sistem, MCP membantu menghindari “spaghetti” dari banyak integrasi point-to-point. Dan Anda tidak perlu memantau semua pembaruan API dari penyedia lain.

Apakah integrasi API akan menjadi usang?

Baik integrasi API tradisional maupun MCP memiliki tempat masing-masing. Pendekatan terbaik dapat bergantung pada sifat proyek, keahlian tim, dan tujuan jangka panjang.

Jika Anda hanya perlu mengintegrasikan satu atau dua layanan eksternal dan interaksinya relatif sederhana, integrasi API langsung sering kali menjadi solusi tercepat. Jika aplikasi web Anda hanya perlu memverifikasi token pembayaran Stripe saat checkout, memanggil API Stripe secara langsung sederhana dan efektif. Memperkenalkan MCP dalam skenario ini mungkin berlebihan. Anda dapat menghubungkan AI Agent ke REST API terdokumentasi apa pun dengan satu HTTP Action yang ditinjau, atau menggunakan integrasi sekali klik seperti Google Sheets untuk mencatat lead dan permintaan demo, tanpa menjalankan server MCP.

Dalam kasus ketika Anda memerlukan kontrol yang sangat ketat atas permintaan/respons (untuk penyetelan performa, penanganan data khusus, atau protokol proprietary), menulis langsung ke API bisa lebih baik. Integrasi tradisional memungkinkan Anda menggunakan semua fitur lanjutan API dan menyesuaikan panggilan secara tepat. Jika API memiliki persyaratan yang tidak biasa atau jika Anda ingin menghindari lapisan abstraksi demi kejelasan dan kontrol maksimum, pendekatan tradisional sesuai.

Untuk contoh konkret tentang bagaimana tool MCP diekspos ke AI Agent produksi bersama custom API actions, lihat bagaimana Quickchat AI Agents menggabungkan kedua pendekatan. Pembahasan lebih mendalam tentang kapan menggunakan MCP, AI Actions individual, atau “Generate from Text” ada di API untuk AI Agents: Dari MCP ke Custom Endpoints. Untuk mencobanya sendiri, ikuti panduan langkah demi langkah untuk menghubungkan AI Agent Anda ke server MCP jarak jauh agar agent memanggil tool aktif di tengah percakapan.

Daftar server MCP yang tersedia

Jika Anda ingin mulai menggunakan MCP, lihat direktori server MCP di bawah ini:

• https://github.com/modelcontextprotocol/servers
• https://smithery.ai

Anda juga dapat menjalankannya tanpa menulis kode apa pun: setiap Quickchat AI Agent dapat diubah menjadi server MCP dengan URL hosted yang dipanggil Claude, ChatGPT, dan Cursor sebagai tool. Koneksi juga bekerja ke arah sebaliknya: Quickchat AI Agent dapat memanggil server MCP hosted milik vendor sebagai tool-nya, yaitu cara asisten penjadwalan AI yang dibangun di atas server MCP Calendly memeriksa ketersediaan nyata dan membuat booking rapat dari chat, serta cara chatbot Notion AI menjawab dari help center live dan mencatat permintaan dukungan kembali ke database Notion.

Quickchat AI juga menjalankan server MCP jarak jauh untuk akun Anda sendiri. Hubungkan ke ChatGPT, Claude, Cursor, atau Codex dan Anda dapat mengelola AI Agents Anda dari sana: analytics, transkrip percakapan, pembaruan knowledge base, dan pembuatan Agent baru, di balik satu proses masuk OAuth. Panduan setup untuk setiap client ada di Kelola AI Agent Anda dari ChatGPT, Claude, dan Codex dengan MCP.

FAQ

Apakah ini hanya bekerja dengan Claude?

MCP bersifat model-agnostic. Protokol tidak peduli apakah client-nya Claude, GPT-4, turunan LLaMA lokal, atau model masa depan apa pun, selama client dapat menangani antarmuka MCP. Ini berarti Anda tidak terkunci pada satu penyedia AI saat membangun integrasi tool Anda.

Apa perbedaan MCP dengan sekadar memberikan semua info yang dibutuhkan model di awal? Mengapa tidak memasukkan data ke prompt saja?

MCP pada dasarnya berbeda dari memasukkan data ke prompt model karena MCP memungkinkan model mengambil informasi secara dinamis saat dibutuhkan, bukan bekerja dengan prompt statis yang sudah dimuat sebelumnya. Memasukkan teks ke prompt menghadapi keterbatasan, karena model AI memiliki context window tetap, yang berarti terlalu banyak data dapat menyebabkan detail penting hilang, memperlambat respons, dan meningkatkan biaya API (karena model harga per token yang digunakan vendor LLM). Cara itu juga hanya menyediakan pengetahuan pada satu titik waktu, sedangkan MCP memungkinkan akses real-time ke data eksternal yang aktif dan membiarkan AI mengambil tindakan, bukan hanya membaca informasi. AI dengan prompt yang padat mungkin mengetahui detail pelanggan, tetapi tidak akan dapat memperbarui catatan atau memproses transaksi.

Bagaimana jika kita menghubungkan puluhan tool ke AI? Bukankah itu akan membebani model atau menyebabkannya menyalahgunakan tool?

Itu bergantung pada implementasinya, tetapi benar bahwa LLM saat ini memiliki batas dalam membedakan dan memilih di antara banyak opsi. Jika Anda menyajikan, misalnya, 50 tool yang mungkin kepada model, ada risiko model memilih tool yang salah. Pendekatan MCP sendiri tidak memaksa Anda memuat semuanya sekaligus. Anda sebaiknya menghubungkan tool yang relevan berdasarkan konteks. Praktik terbaik adalah hanya menghubungkan tool yang dibutuhkan untuk tugas/domain yang sedang ditangani dan memanfaatkan kolaborasi multiagent, semacam routing tool atau agent yang pertama-tama memutuskan subset tool mana yang perlu dipertimbangkan.

MCP vs Function Calling

Function calling tradisional (seperti yang terlihat di API OpenAI atau LLM lain) memungkinkan developer menentukan sekumpulan fungsi, memberikan definisinya kepada model, dan membuat model “memanggil” fungsi tersebut berdasarkan nama dengan argumen. Ini adalah langkah besar untuk integrasi AI, tetapi memiliki keterbatasan. Salah satu perbedaan utama adalah kapan dan bagaimana tool didefinisikan. Dalam function calling klasik, semua fungsi yang mungkin harus dideklarasikan di awal (pada waktu desain) dalam prompt atau melalui API. Model hanya dapat memanggil fungsi tetap tersebut. Dalam MCP, tool dapat ditemukan saat runtime, AI dapat meng-query apa yang tersedia dan bahkan mendapatkan tool baru di tengah sesi.

MCP vs GPT Actions & Plugins

GPT Actions/Plugins merujuk pada ekosistem OpenAI tempat Anda dapat mengaktifkan plugin (seperti browser web, atau pembaca PDF) untuk ChatGPT, atau “GPTs” (agent ChatGPT kustom) yang dapat menggunakan tool. Hal-hal itu menarik, tetapi memerlukan pengembangan kustom untuk setiap plugin dan terbatas pada platform OpenAI. Jika Anda menginginkan plugin ChatGPT untuk suatu tugas, Anda harus membuat API dan manifest, lalu melalui persetujuan OpenAI atau setidaknya mengaktifkannya secara manual. Setiap plugin pada dasarnya adalah silo, plugin cuaca, plugin perjalanan, dan sebagainya, masing-masing dengan endpoint dan logikanya sendiri. MCP memperbaiki konsep ini dengan menyatukan dan membukanya.

MCP vs RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG) adalah teknik ketika LLM dilengkapi dengan knowledge base eksternal. Biasanya, RAG melibatkan database vektor atau indeks pencarian: query pengguna digunakan untuk mengambil dokumen atau data yang relevan (dengan pencarian semantik atau metode lain), dan dokumen tersebut diberikan kepada model sebagai konteks tambahan untuk “dibaca” saat membentuk jawaban. RAG berfokus pada pemberian pengetahuan kepada model yang awalnya tidak dimilikinya, terutama berguna untuk QA faktual atau informasi khusus domain. Namun, RAG bersifat read-only, model mengambil potongan teks, tetapi tidak melakukan tindakan di luar retrieval.

Sebaliknya, MCP berfokus pada mengambil tindakan atau menjalankan operasi arbitrer, bukan hanya mengambil konteks informasi. Dengan MCP, AI dapat melakukan sesuatu: menulis ke database, mengirim email, mengeksekusi kode, dan sebagainya. MCP tidak terbatas pada mengambil pengetahuan, MCP dapat memicu perubahan di sistem eksternal. Jadi dalam banyak hal, RAG dan MCP melayani tujuan yang berbeda.