Cara Kerja MCP (Model Context Protocol): Panduan Langkah demi Langkah

Apa Itu Model Context Protocol (MCP)

MCP adalah protokol terbuka yang memungkinkan aplikasi AI terhubung ke program eksternal, yang disebut server MCP, yang mengekspos kemampuan seperti alat yang dapat dipanggil oleh model, sumber daya yang dapat dibaca, dan template perintah yang dapat dipanggil pengguna. Aplikasi AI, yang disebut host, membuat satu klien untuk setiap server yang terhubung dengannya, dan klien bertukar pesan JSON-RPC 2.0 dengan server melalui saluran lokal atau koneksi HTTP. Hasilnya adalah cara standar bagi aplikasi AI yang kompatibel untuk menemukan apa yang ditawarkan server, menggunakannya, dan memberikan umpan balik hasilnya ke model bahasa, tanpa kode integrasi khusus untuk setiap pasangan.

Para Pemeran Utama

Sebelum membahas tahapan-tahapannya, ada baiknya kita mengenal para peserta terlebih dahulu, karena kosakata protokol inilah yang seringkali membingungkan.

Host, Klien, dan Server

Arsitektur MCP memiliki tiga peserta. Host MCP adalah aplikasi AI yang berinteraksi dengan pengguna, seperti Claude Desktop, Claude Code, atau Visual Studio Code. Server MCP adalah program yang menyediakan konteks dan kemampuan, seperti konektor ke database, pelacak masalah, atau sistem file. Dan klien MCP adalah komponen di dalam host yang tugasnya hanya untuk mempertahankan koneksi ke satu server tertentu.

Hubungannya adalah satu host ke banyak klien ke banyak server, dengan setiap klien dipasangkan dengan tepat satu server. Dokumentasi resmi memberikan contoh: ketika Visual Studio Code terhubung ke server Sentry MCP, ia membuat objek klien MCP untuk mempertahankan koneksi tersebut. Ketika kemudian terhubung ke server sistem file lokal, ia membuat objek klien kedua. Setiap klien memiliki koneksi khusus sendiri, sehingga server tetap terisolasi satu sama lain.

Kata "server" seringkali membingungkan orang. Dalam MCP, ini mengacu pada program yang menyediakan konteks, di mana pun program tersebut berjalan. Server dapat berjalan secara lokal di mesin kita sendiri, dalam hal ini biasanya melayani satu klien, atau jarak jauh di suatu platform, dalam hal ini dapat melayani banyak klien.

Dua Layer

Protokol itu sendiri memiliki dua layer. Layer data mendefinisikan pesan JSON-RPC 2.0 yang dipertukarkan antara klien dan server: bagaimana penemuan bekerja, apa saja primitif intinya, dan bagaimana notifikasi berperilaku. Layer transport mendefinisikan bagaimana pesan-pesan tersebut dikirim. MCP mendukung dua transport. Stdio menggunakan aliran input dan output standar dari proses lokal, memberikan komunikasi cepat dan langsung pada satu mesin. Streamable HTTP menggunakan HTTP POST untuk pesan klien-ke-server dengan Server-Sent Events opsional untuk streaming, yang memungkinkan server jarak jauh dan mendukung otentikasi HTTP standar, dengan OAuth direkomendasikan untuk mendapatkan token. Transport HTTP-plus-SSE yang lebih lama telah usang dan digantikan oleh Streamable HTTP.

Tiga Primitif Server

Server mengekspos tiga jenis kemampuan, yang disebut primitif. Alat adalah fungsi yang dapat dieksekusi yang dapat dipanggil oleh model untuk melakukan tindakan, seperti menjalankan kueri database, memanggil API, atau menulis file. Sumber daya adalah sumber data yang menyediakan konteks, seperti isi file, catatan database, atau respons API. Prompt adalah template yang dapat digunakan kembali yang menyusun interaksi, seperti prompt sistem atau serangkaian contoh few-shot.

Cara yang berguna untuk mengingat perbedaannya adalah dengan siapa yang memegang kendali. Alat dipilih oleh model. Sumber daya biasanya dipilih dan disertakan sebagai konteks oleh aplikasi host. Prompt dipilih oleh pengguna. Sebuah server database tunggal mungkin menawarkan ketiganya: alat untuk menjalankan kueri, sumber daya yang berisi skema, dan templat prompt dengan contoh kueri yang baik.

Klien juga mengekspos fitur kembali ke server. Elicitation memungkinkan server untuk meminta informasi lebih lanjut kepada pengguna di tengah permintaan, misalnya untuk mengkonfirmasi suatu tindakan atau memberikan detail yang hilang. Dua fitur klien yang lebih lama, sampling dan logging, telah usang sejak revisi saat ini.

Perjalanan Sebuah Permintaan: Sebuah Contoh Nyata

Untuk mempermudah pemahaman, bayangkan skenario ini. Kita menggunakan asisten coding AI, yaitu host MCP. Asisten ini memiliki dua server yang dikonfigurasi, yaitu server jarak jauh untuk platform pemantauan kesalahan kita, dan server lokal yang membaca file di mesin kita. Kita mengetik: "Mengapa proses checkout gagal sejak pagi ini? Periksa kesalahan terbaru dan lihat kode pembayarannya."

Berikut adalah bagaimana permintaan tersebut melewati tujuh tahapan.

Langkah 1: User Request

Semuanya dimulai dengan seseorang mengetikkan permintaan dalam bahasa alami. Pada titik ini, MCP belum terlibat. Permintaan tersebut sampai ke aplikasi host, yang menambahkannya ke percakapan dan bersiap untuk mengirimkannya ke model bahasa.

Yang membedakan adalah apa yang dikirim host bersama dengan kata-kata kita. Karena host telah terhubung ke server MCP dan mengumpulkan deskripsi alat-alatnya, host dapat menyertakan deskripsi alat tersebut dalam konteks yang diberikannya kepada model. Model melihat permintaan kita bersama dengan katalog tentang apa yang dapat dilakukannya, seperti: menanyakan kesalahan terbaru, membaca file, dan sebagainya. Dari perspektif model, alat hanyalah deskripsi terstruktur dengan nama, penjelasan, dan skema input.

Ini adalah saat yang tepat untuk menjelaskan secara tepat apa yang dilakukan dan tidak dilakukan MCP. Dokumentasi resmi menyatakan bahwa MCP hanya berfokus pada protokol untuk pertukaran konteks dan tidak menentukan bagaimana aplikasi AI menggunakan model bahasa atau mengelola konteks yang diberikan kepadanya. Jadi, bagaimana host menyampaikan sesuatu kepada model, model mana yang digunakannya, dan bagaimana ia memutuskan apa yang akan disertakan adalah keputusan aplikasi, bukan protokol.

Dalam contoh kita, model membaca pertanyaan kita dan alat yang tersedia, lalu memutuskan bahwa menjawab memerlukan data nyata. Model tersebut membutuhkan kesalahan terbaru dari platform pemantauan dan isi kode pembayaran. Keputusan untuk menggunakan alat itulah yang menggerakkan seluruh proses selanjutnya.

Langkah 2: Host MCP

Host adalah aplikasi AI, dan merupakan konduktor dari seluruh operasi. Ia melakukan beberapa tugas yang mudah diabaikan.

Pertama, ia mengelola koneksi. Sebelum kita mengetikkan permintaan, host membaca konfigurasinya, yang mencantumkan server MCP yang telah kita siapkan, dan terhubung ke masing-masing server. Untuk server lokal, konfigurasi biasanya memberikan perintah untuk diluncurkan. Untuk server jarak jauh, ia memberikan URL dan mungkin kredensial. Untuk setiap server, host membuat klien, yang merupakan subjek dari langkah selanjutnya.

Kedua, ia menggabungkan konteks. Host mengumpulkan alat, sumber daya, dan perintah dari semua servernya dan menyajikan katalog terpadu ke model, sehingga model tidak perlu mengetahui server mana yang menyediakan apa. Ketika kita menghubungkan lima server, model melihat satu set kemampuan gabungan.

Ketiga, dan yang terpenting, host adalah penegak keamanan dan persetujuan. Spesifikasi MCP menugaskan host untuk menegakkan kebijakan keamanan dan persyaratan persetujuan, menangani keputusan otorisasi pengguna, dan mengontrol interaksi antar server. Ini memang dirancang demikian. Arsitektur ini bertumpu pada beberapa prinsip, seperti: host harus memudahkan pembuatan server, server harus sangat mudah dikomposisikan, server tidak boleh dapat membaca seluruh percakapan atau melihat ke server lain, dan fitur harus ditambahkan secara bertahap. Dalam praktiknya, host menyimpan riwayat percakapan lengkap untuk dirinya sendiri dan hanya membagikan informasi yang dibutuhkan server tersebut kepada setiap server. Server pemantauan tidak pernah melihat file pribadi kita, dan server sistem file tidak pernah melihat log kesalahan kita, kecuali jika host memilih untuk menghubungkannya melalui model.

Keempat, host berkoordinasi dengan model bahasa. Ia mengirimkan permintaan kita dan katalog alat ke model, menginterpretasikan respons model, dan ketika model meminta untuk menggunakan alat, ia mengarahkan permintaan tersebut ke tempat yang tepat. Ia juga memutuskan apakah akan meminta persetujuan kita sebelum menjalankan alat, yang merupakan cara sebagian besar host menangani tindakan dengan efek samping.

Dalam contoh kita, host memegang dua klien, satu untuk server pemantauan dan satu untuk server sistem file, dan ketika model memutuskan untuk melihat kesalahan terbaru, host mengetahui klien mana yang memiliki alat tersebut.

Langkah 3: Klien MCP

Di dalam host, terdapat satu klien untuk setiap server. Klien adalah komponen kecil namun penting: ia memelihara koneksi khusus ke servernya dan menangani detail komunikasi protokol, sehingga bagian host lainnya tidak perlu melakukannya.

Apa yang Dilakukan Klien

Klien mengelola transportasi, baik itu meluncurkan proses lokal dan berkomunikasi melalui input dan output standar, atau membuka koneksi HTTP ke server jarak jauh. Ia memformat dan mengirim permintaan JSON-RPC, menerima respons, dan menangani kesalahan. Untuk server jarak jauh, ia menangani otentikasi, biasanya memperoleh dan melampirkan token OAuth atau kredensial lain sesuai dengan kebutuhan server. Ia juga menyediakan fitur yang dapat digunakan server sebagai balasannya, seperti elisitasi, di mana server meminta input dari pengguna dan klien meneruskan permintaan tersebut ke host untuk ditampilkan kepada kita.

Statelessness: Perubahan Besar

Revisi saat ini membuat perubahan penting pada bagaimana klien dan server berhubungan. Versi MCP sebelumnya memulai setiap koneksi dengan jabat tangan, pertukaran inisialisasi di mana klien dan server menegosiasikan versi dan kemampuan serta membangun sesi, dan banyak tutorial lama menjelaskan urutan tersebut. Revisi 28-07-2026 menghapusnya. MCP sekarang menjadi protokol stateless, yaitu setiap permintaan bersifat mandiri dan membawa semua yang dibutuhkan server untuk memprosesnya.

Secara konkret, setiap permintaan menyertakan, dalam bidang yang disebut _meta, versi protokol yang digunakan klien dan kemampuan yang didukung klien, dan klien biasanya juga menyertakan nama dan versinya. Server tidak perlu mengingat apa pun dari permintaan sebelumnya untuk memahami permintaan saat ini. Hal ini membuat server jauh lebih mudah untuk diimplementasikan dan diskalakan, karena setiap instance dapat menangani setiap permintaan, tanpa sesi yang lengket atau status koneksi bersama, yang merupakan sumber umum masalah operasional dengan desain lama.

Bagi developer, saran praktisnya adalah SDK resmi menyerap sebagian besar perubahan ini, jadi peningkatan SDK adalah langkah pertama, tetapi implementasi kustom yang ditulis berdasarkan revisi lama perlu diperhatikan.

Satu Klien per Server

Pasangan satu-ke-satu penting untuk isolasi. Karena setiap klien hanya memiliki satu koneksi, masalah pada satu server, seperti kerusakan, kelambatan, atau perilaku yang salah, tidak akan memengaruhi server lain. Ini juga memperkuat batas keamanan, yaitu klien hanya berkomunikasi dengan servernya sendiri, dan host berada di atas semuanya.

Langkah 4: Penemuan Server

Sebelum klien dapat menggunakan server, klien perlu mengetahui apa yang ditawarkan server tersebut. Ini disebut penemuan, dan di MCP hal ini terjadi pada dua tingkatan.

Menemukan Server

Tingkat pertama hanyalah mengetahui server mana yang ada. Di sebagian besar host saat ini, ini adalah masalah konfigurasi: kita atau organisasi kita menentukan server yang akan dihubungkan. Direktori dan registri server MCP ada untuk membantu menemukannya, dan beberapa host menawarkan katalog atau instalasi sekali klik. Tetapi protokol itu sendiri tidak memerlukan pencarian server otomatis di seluruh jaringan. Host terhubung ke server yang telah diberitahukan kepadanya.

Menemukan Apa yang Dapat Dilakukan Server

Level kedua adalah level yang didefinisikan secara detail oleh protokol. Setelah klien terhubung, klien dapat menanyakan informasi tentang dirinya kepada server. Dalam revisi saat ini, setiap server harus mengimplementasikan permintaan yang disebut server/discover, yang dapat dikirim klien sebelum permintaan lainnya. Permintaan ini mengembalikan versi protokol yang didukung server, kemampuannya, dan identitasnya.

Dokumentasi resmi memberikan contoh. Klien mengirimkan permintaan penemuan yang membawa metadata-nya:

json
{
   "jsonrpc": "2.0",
   "id": 1,
   "method": "server/discover",
   "params": {
       "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
         "name": "example-client",
      "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
          "elicitation": {}
      }
   }
}

Dan server merespons dengan apa yang didukungnya:

json
{
"jsonrpc": "2.0",
"id": 1,
   "result": {
   "resultType": "complete",
   "supportedVersions": ["2026-07-28"],
      "capabilities": {
      "tools": { "listChanged": true },
      "resources": {}
   },
"_meta": {
   "io.modelcontextprotocol/serverInfo": {
      "name": "example-server",
      "version": "1.0.0"
      }
   },
   "ttlMs": 3600000,
   "cacheScope": "public"
   }
}

Pertukaran kecil ini melakukan tiga tugas. Pertama, menangani pemilihan versi: klien menyatakan versi mana yang digunakannya, dan server mencantumkan versi mana yang diterimanya. Jika server tidak mendukung versi yang diminta, server akan menolak permintaan dengan pesan kesalahan yang mencantumkan versi yang didukungnya, dan klien akan mencoba lagi dengan versi yang didukung bersama. Kedua, menangani penemuan kemampuan: klien menyatakan dapat menangani elisitasi, dan server menyatakan menawarkan alat, dengan dukungan notifikasi untuk perubahan daftar alat, dan sumber daya. Oleh karena itu, masing-masing pihak mengetahui apa yang dapat dilakukan pihak lain, sehingga operasi yang tidak didukung tidak pernah dicoba. Dan ini bertukar identitas, yang membantu dalam proses debugging dan kompatibilitas.

Responsnya juga dapat di-cache. Bidang ttlMs adalah petunjuk kebaruan, sehingga klien tidak perlu mengulangi penemuan pada setiap permintaan. Memanggil server/discover, dari sisi klien, bersifat opsional, karena setiap permintaan membawa metadata yang sama dan klien dapat mengirim permintaan secara langsung dan menangani kesalahan versi jika ada yang kembali. Discovery adalah cara yang nyaman untuk mengambil semuanya dalam satu panggilan.

Menemukan Alat, Sumber Daya, dan Petunjuk

Mengetahui bahwa server menawarkan alat tidak sama dengan mengetahui alat mana yang tersedia. Untuk itu, klien menggunakan metode daftar. Setiap primitif memiliki metode daftar, yaitu: tools/list, resources/list, dan prompts/list. Daftar alat mengembalikan, untuk setiap alat, nama unik, judul yang mudah dibaca manusia, deskripsi tentang apa yang dilakukannya dan kapan harus menggunakannya, dan skema input, yang ditulis dalam JSON Schema, yang mendefinisikan parameter yang diharapkan oleh alat tersebut.

Berikut adalah versi singkat dari contoh resmi, sebuah server yang menawarkan alat cuaca:

json
{
"name": "weather_current",
"title": "Informasi Cuaca",
"description": "Dapatkan informasi cuaca terkini untuk lokasi mana pun di seluruh dunia",
"inputSchema": {
   "type": "object",
   "properties": {
      "location": {
         "type": "string",
         "description": "Nama kota, alamat, atau koordinat (lintang, bujur)"
      },
      "units": {
         "type": "string",
         "enum": ["metric", "imperial", "kelvin"],
         "default": "metric"
         }
      },
   "required": ["location"]
   }
}

Deskripsi ini sangat penting, karena inilah yang dibaca oleh model bahasa untuk memutuskan apakah dan bagaimana menggunakan suatu alat. Deskripsi yang samar menghasilkan model yang salah menggunakan alat tersebut atau mengabaikannya. Deskripsi yang tepat, dengan deskripsi parameter yang jelas, menghasilkan perilaku yang andal. Respons terhadap permintaan daftar juga membawa petunjuk caching, dan daftar panjang dapat di-page-kan menggunakan kursor.

Tetap Terkini: Daftar dan Notifikasi Dinamis

Daftar bersifat dinamis. Alat server dapat berubah seiring dengan perubahan izin atau munculnya fitur baru. Pada revisi saat ini, notifikasi perubahan bersifat opsional: klien membuka aliran data jangka panjang dengan permintaan langganan/mendengarkan yang menyebutkan jenis notifikasi yang diinginkannya, seperti perubahan daftar alat, dan server, jika telah mengiklankan dukungannya, akan mengirimkannya melalui aliran data tersebut. Ketika notifikasi tiba, klien biasanya memanggil tools/list lagi untuk memperbarui. Dokumentasi secara jujur ​​menyatakan bahwa notifikasi bersifat upaya terbaik, tanpa jaminan bahwa setiap notifikasi akan terkirim, terutama saat koneksi ulang, sehingga klien juga harus memperbarui secara berkala.

Penemuan Alat dalam Skala Besar

Ketika sebuah host terhubung ke banyak server, memuat setiap deskripsi alat ke dalam konteks model menjadi mahal dan dapat menurunkan kinerja. Dokumentasi menunjukkan penemuan alat progresif sebagai praktik terbaik untuk klien yang menggabungkan banyak server: alih-alih memuat setiap alat di awal, klien menampilkan alat sesuai permintaan saat model membutuhkannya.

Dalam contoh kita, klien host telah menemukan bahwa server pemantauan menawarkan alat untuk mencari dan mengambil kesalahan, dan bahwa server sistem file menawarkan alat untuk membaca dan mendaftarkan file. Host telah menggabungkan ini ke dalam katalog untuk model.

Langkah 5: Pemanggilan Alat dan Sumber Daya

Sekarang aksi dimulai. Model, setelah membaca permintaan kita dan katalog, memutuskan untuk menggunakan sebuah alat, dan protokol mengubah keputusan itu menjadi panggilan konkret.

Dari Keputusan Model ke Panggilan Protokol

Penting untuk memperjelas siapa yang melakukan apa. Model tidak pernah berbicara langsung dengan server MCP. Ketika memutuskan untuk menggunakan sebuah alat, ia mengirimkan permintaan terstruktur, dalam format apa pun yang digunakan penyedianya untuk panggilan alat, dengan menyebutkan nama alat dan argumennya. Host mencegat permintaan itu, mencari tahu server mana yang memiliki alat yang disebutkan, dan menyerahkan panggilan tersebut ke klien yang sesuai. Klien kemudian menerjemahkannya menjadi permintaan alat/panggilan MCP.

Di sinilah MCP dan fitur pemanggilan alat milik penyedia model bertemu. Mereka bukanlah pesaing. Fitur penyedia adalah bagaimana model mengekspresikan keinginan untuk memanggil suatu fungsi. MCP adalah bagaimana host menemukan alat dari berbagai sumber dan bagaimana ia menjalankan panggilan tersebut. Host mengkonversi deskripsi alat MCP ke dalam format yang diharapkan oleh model dan mengkonversi panggilan balik model menjadi permintaan MCP.

Permintaan alat/panggilan

Panggilan tersebut menyebutkan nama alat dan menyediakan argumen yang sesuai dengan skema inputnya. Menggunakan contoh cuaca resmi:

json
{
"jsonrpc": "2.0",
"id": 3,
"method": "tools/call",
"params": {
   "name": "weather_current",
   "arguments": {
      "location": "San Francisco",
      "units": "imperial"
   },
   "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
         "name": "example-client",
         "version": "1.0.0"
         },
         "io.modelcontextprotocol/clientCapabilities": {
         "elicitation": {}
         }
      }
   }
}

Nama harus sama persis dengan nama dari daftar. Argumen mengikuti skema, dengan parameter wajib dan parameter opsional menggunakan nilai defaultnya. Parameter _meta berisi field standar per permintaan yang memungkinkan statelessness berfungsi. Dan ID JSON-RPC memungkinkan klien untuk mencocokkan respons akhir dengan permintaan ini.

Sumber Daya dan Perintah

Alat bukanlah satu-satunya hal yang dapat dipanggil oleh klien. Untuk sumber daya, klien menggunakan resources/list untuk melihat apa yang tersedia dan resources/read untuk mengambil konten berdasarkan URI. Sumber daya umumnya dikendalikan oleh aplikasi: host memutuskan sumber daya mana yang akan disertakan sebagai konteks, mungkin karena kita memilih file atau karena aplikasi secara otomatis melampirkan skema basis data. Untuk perintah, klien menggunakan prompts/list dan prompts/get, biasanya sebagai respons terhadap pengguna yang memilih templat, seperti perintah slash, yang mengembalikan pesan terstruktur yang dapat ditempatkan host dalam percakapan.

Persetujuan dan Izin

Karena panggilan alat dapat memiliki efek nyata, sebagian besar host menyisipkan titik pemeriksaan manusia sebelum menjalankannya. Host mungkin bertanya, "Izinkan server pemantauan untuk mencari kesalahan?" dan mengingat jawaban kita untuk sesi tersebut, atau mungkin menjalankan alat baca-saja secara otomatis sambil memerlukan persetujuan untuk apa pun yang menulis atau menghapus. Protokol menyerahkan kebijakan kepada host, dan kualitas kebijakan tersebut merupakan bagian utama dari seberapa aman aplikasi yang diaktifkan MCP. Host yang baik menunjukkan kepada kita apa yang akan dipanggil dan dengan argumen apa, daripada konfirmasi yang samar.

Ketika Diperlukan Lebih Banyak Input

Terkadang server tidak dapat menyelesaikan permintaan tanpa informasi lebih lanjut. Sebuah alat mungkin memerlukan konfirmasi, atau argumen yang tidak diberikan oleh model. Fitur elisitasi menangani hal ini. Server mengembalikan hasil yang menunjukkan bahwa input diperlukan, klien meneruskan permintaan ke host, host menanyakan kepada pengguna, dan panggilan berlanjut dengan jawabannya. Interaksi ini menggunakan pola yang disebut spesifikasi sebagai permintaan multi-putaran, yang sesuai dengan desain tanpa status, karena status yang dibutuhkan untuk melanjutkan dibawa bersama dengan permintaan daripada disimpan dalam sesi.

Pekerjaan yang Berlangsung Lama

Tidak setiap operasi selesai dalam sekejap. Untuk permintaan yang berlangsung lama, protokol mendukung pelacakan kemajuan dan ekstensi Tugas opsional, yang memungkinkan server mengembalikan handle yang tahan lama yang dapat diakses klien nanti untuk mendapatkan status dan mengambil hasilnya.

Dalam contoh kita, model meminta untuk mencari kesalahan checkout terbaru di platform pemantauan. Host mengarahkan panggilan ke klien pemantauan, yang mengirimkan permintaan tools/call ke server pemantauan melalui HTTP, membawa parameter pencarian. Kemudian, model akan meminta untuk membaca file pembayaran, dan panggilan itu akan diteruskan ke klien sistem file.

Langkah 6: Sistem Eksternal

Server MCP berada di ujung protokol. Di satu sisi, ia berkomunikasi dengan klien menggunakan MCP. Di sisi lain, ia berkomunikasi dengan sistem sebenarnya yang menyimpan data atau melakukan tindakan. Ini adalah langkah di mana sesuatu benar-benar terjadi di dunia nyata.

Server sebagai Adaptor

Pada intinya, server MCP adalah adaptor. Ketika permintaan alat/panggilan tiba untuk alat yang disebut sesuatu seperti search_errors, kode server menerjemahkannya ke dalam apa pun yang dipahami oleh sistem yang mendasarinya, seperti: permintaan HTTP ke API REST, kueri SQL terhadap database, pembacaan dari sistem file, panggilan ke layanan internal, atau perintah ke produk SaaS. Ia menjalankan operasi, mengumpulkan output, dan membentuknya menjadi hasil MCP.

Protokol sengaja tidak menyebutkan apa yang terjadi di dalam langkah ini. MCP menstandarisasi percakapan antara klien dan server, bukan internal server. Kebebasan itulah mengapa server ada untuk berbagai macam sistem, mulai dari kontrol versi dan basis data hingga pemantauan, pengiriman pesan, dan alat desain.

Kredensial dan Izin

Server bertindak dengan kredensialnya sendiri, dan ini memiliki implikasi keamanan. Server yang terhubung ke database kita melakukannya dengan serangkaian izin database, dan semua yang diminta model melalui server tersebut dibatasi oleh apa yang diizinkan oleh izin tersebut. Prinsip hak akses minimal sangat berlaku di sini, yaitu berikan server akses baca saja jika hanya membaca yang dibutuhkan, batasi akses ke tabel atau proyek yang diperlukan, dan hindari kredensial administrator yang luas. Untuk server jarak jauh, otentikasi antara klien dan server, biasanya menggunakan OAuth, sehingga mengontrol siapa yang dapat memanggil server sama sekali, dan server yang dirancang dengan baik memetakan pengguna yang diautentikasi ke izin yang sesuai di sistem hilir.

Merancang Alat yang Baik

Cara server menyajikan kemampuannya menentukan seberapa baik model dapat menggunakannya. Server yang baik menawarkan sejumlah kecil alat yang diberi nama dengan jelas dan ruang lingkupnya sempit, bukan serangkaian alat yang tumpang tindih dan tersebar luas. Mereka memvalidasi input, karena argumen model adalah saran, bukan jaminan. Mereka mengembalikan hasil yang ringkas dan bermanfaat, bukan membuang data mentah yang membuang konteks model. Dan mereka menghasilkan pesan kesalahan yang membantu yang memungkinkan model untuk pulih, misalnya, memberi tahu bahwa format tanggal tidak valid dan format yang diharapkan.

Menangani Efek Samping

Alat yang mengubah sesuatu membutuhkan perhatian ekstra. Alat yang mengirim email, membuat catatan, atau menghapus file harus dirancang agar aman untuk dicoba ulang jika memungkinkan, dan harus menampilkan dengan jelas apa yang telah dilakukannya. Banyak tim memisahkan server hanya baca dari server yang dapat menulis, sehingga kebijakan persetujuan dapat lebih ketat untuk yang terakhir.

Dalam contoh kita, server pemantauan menerima permintaan pencarian, memanggil API platform pemantauan dengan kredensialnya sendiri, mengambil kesalahan checkout terbaru, dan menyiapkan ringkasan daripada mengembalikan ribuan baris log mentah.

Langkah 7: Hasil Kembali ke LLM

Langkah terakhir menutup siklus. Pekerjaan server telah selesai, dan outputnya harus kembali ke model agar model dapat melanjutkan.

Respons
Server mengembalikan respons JSON-RPC ke klien. Dalam contoh resmi, panggilan cuaca mengembalikan hasil yang ditandai selesai, dengan array konten yang berisi item teks:

json
{
   "jsonrpc": "2.0",
   "id": 3,
   "result": {
      "resultType": "complete",
      "content": [
         {
         "type": "text",
         "text": "Cuaca saat ini di San Francisco: 68°F, sebagian berawan dengan angin ringan dari barat dengan kecepatan 8 mph. Kelembapan: 65%"
         }
      ]
   }
}

Array konten memungkinkan hasil yang kaya dan multi-bagian. Teks adalah tipe yang paling umum, tetapi hasilnya dapat membawa tipe konten lain, seperti gambar atau referensi ke sumber daya. Jika panggilan gagal, server dapat melaporkan kegagalan tersebut dalam hasilnya sehingga model dapat melihat apa yang salah dan memutuskan apakah akan mencoba lagi, menyesuaikan argumennya, atau mencoba hal lain.

Kembali Melalui Host ke Model

Klien menerima respons dan meneruskannya ke host. Host kemudian menambahkan hasilnya ke percakapan sebagai hasil alat, yang terkait dengan permintaan asli model, dan memanggil model lagi. Dari sudut pandang model, ia mengajukan pertanyaan dan sekarang telah menerima jawaban. Ia membaca hasilnya dalam konteks, bersama dengan permintaan asli kita dan semua yang telah terjadi sejauh ini.

Siklus Berlanjut

Apa yang dilakukan model selanjutnya bergantung pada apakah ia memiliki cukup informasi untuk menjawab. Jika ya, ia menulis respons akhir, yang ditampilkan host kepada kita. Jika tidak, ia dapat meminta panggilan alat lain, dan siklus berulang dari langkah 5: host mengarahkan panggilan, klien mengirimkannya, server mengeksekusinya, dan hasilnya dikembalikan. Permintaan yang kompleks dapat melibatkan banyak putaran seperti itu, dengan model menghubungkan alat di beberapa server. Dalam contoh kita, model pertama kali menerima kesalahan terbaru dari server pemantauan, memperhatikan bahwa kesalahan tersebut mengarah pada waktu habis (timeout) dalam fungsi pembayaran, kemudian meminta server sistem file untuk membaca file tersebut, dan akhirnya menalar di antara kedua hasil tersebut untuk menjelaskan kemungkinan penyebabnya dan menyarankan perbaikan.

Mengelola Hasil

Beberapa masalah praktis muncul pada tahap ini. Hasil akan menghabiskan context window model, sehingga output yang besar dapat mengganggu informasi lain, itulah sebabnya server harus mengembalikan hasil yang terfokus dan host dapat memotong atau meringkasnya. Hasil juga, dalam arti keamanan, merupakan input yang tidak tepercaya. Data yang dikembalikan dari sistem eksternal dapat berisi teks yang terlihat seperti instruksi, risiko yang dikenal sebagai injeksi prompt, yang akan kita bahas selanjutnya.

Pertimbangan Keamanan di Seluruh Alur

Karena MCP menghubungkan model ke sistem nyata, keamanan perlu mendapat perhatian di setiap tahap, bukan sebagai pertimbangan belakangan.

Perhatian pertama adalah persetujuan dan visibilitas. Pengguna harus mengetahui server mana yang terhubung, apa yang dapat dilakukan masing-masing server, dan kapan suatu alat akan dijalankan, terutama untuk tindakan yang mengubah sesuatu. Host adalah titik penegakan, dan host yang menyetujui semuanya secara diam-diam mengalihkan semua risiko kepada pengguna.

Perhatian kedua adalah hak akses minimal. Server hanya boleh memiliki izin yang dibutuhkan, dan organisasi harus lebih memilih server yang spesifik untuk tugas tertentu daripada server yang luas. Server yang dapat membaca satu proyek jauh lebih kecil risikonya daripada server dengan akses administrator ke seluruh platform.

Perhatian ketiga adalah kepercayaan pada server. Server adalah kode yang kita undang ke dalam alur kerja kita, dan server yang berbahaya atau disusupi dapat menimbulkan kerugian, mulai dari mengembalikan data yang menyesatkan hingga membocorkan apa yang diterimanya. Lebih baik gunakan server dari sumber yang kita percayai, tinjau apa yang dilakukan server pihak ketiga, dan berhati-hatilah dalam menginstal server yang berjalan secara lokal dengan akses ke file kita. Deskripsi alat juga merupakan bagian dari permukaan serangan, karena berupa teks yang dibaca oleh model, dan deskripsi yang berbahaya dapat mencoba mengarahkan perilaku model. Prinsip isolasi arsitektur membantu: server seharusnya tidak dapat membaca seluruh percakapan atau melihat ke server lain, yang membatasi apa yang dapat dipelajari oleh satu server jahat.

Kekhawatiran keempat adalah injeksi cepat melalui hasil. Setiap konten yang mengalir kembali ke model, baik itu halaman web, email, tiket, atau bidang database, mungkin berisi instruksi yang ditulis oleh seseorang selain pengguna. Model yang memperlakukan teks tersebut sebagai perintah dapat dimanipulasi untuk menyalahgunakan alatnya. Pertahanan berlapis: perlakukan hasil alat sebagai data daripada instruksi, batasi tindakan apa yang dapat dilakukan setelah konten yang tidak tepercaya, perlukan persetujuan untuk operasi sensitif, dan pantau perilaku yang tidak biasa.

Kekhawatiran kelima adalah otentikasi untuk server jarak jauh. Server jarak jauh harus memerlukan otorisasi yang tepat, dan protokol merekomendasikan OAuth untuk mendapatkan token melalui HTTP. Token harus memiliki cakupan yang sempit, dan server harus memvalidasinya daripada mempercayai pemanggil mana pun.

Terakhir, ada masalah pengamatan. Pencatatan panggilan alat, argumen, dan hasil, dengan kehati-hatian yang tepat terhadap data sensitif, memungkinkan untuk mengaudit apa yang dilakukan model dan untuk men-debug perilaku yang tidak terduga.

Melihat Seluruh Alur Secara Bersamaan

Dengan ketujuh langkah tersebut terlihat, urutan lengkapnya mudah diceritakan kembali. Seorang pengguna mengetikkan permintaan ke dalam aplikasi host. Host, yang mengelola koneksi, keamanan, dan konteks, menyajikan permintaan tersebut kepada model dan katalog gabungan alat yang dikumpulkan dari semua servernya. Model memutuskan bahwa ia membutuhkan data dan meminta untuk menggunakan suatu alat. Host mengarahkan permintaan tersebut ke klien MCP yang memiliki koneksi ke server yang tepat. Klien mengirimkan permintaan JSON-RPC, yang membawa versi dan kemampuannya, melalui stdio atau HTTP. Server, yang kemampuannya dipelajari klien melalui penemuan dan pencatatan, menerima panggilan dan menerjemahkannya menjadi operasi pada sistem eksternal, menggunakan kredensial lingkupnya sendiri. Sistem mengembalikan data, server membentuknya menjadi hasil, dan respons tersebut kembali melalui klien ke host. Host menambahkannya ke dalam percakapan, dan model menalarnya, baik dengan memanggil lebih banyak alat atau menulis jawaban akhir untuk pengguna.

Setiap tahap memiliki tanggung jawab yang jelas. Host mengatur dan melindungi. Klien berbicara dalam protokol dan menjaga koneksi khusus. Server menyesuaikan protokol dengan sistem nyata. Dan model tersebut memutuskan apa yang harus dilakukan. Pemisahan tanggung jawab inilah yang membuat standar ini bermanfaat: setiap host dapat bekerja dengan setiap server, dan setiap server baru segera tersedia untuk setiap host yang kompatibel.

Memulai dan Melakukan Debugging

Jika kita ingin melihat MCP beraksi, cara tercepat adalah menggunakan host yang mendukungnya dan menghubungkan server referensi, seperti server sistem file, dengan mengikuti dokumentasi host tersebut. Jika kita ingin membangun, SDK resmi menangani mekanisme protokol, dan kita fokus pada alat-alatnya: pilih sejumlah kecil kemampuan yang spesifik dan terdeskripsi dengan baik, tulis deskripsi dan skema yang tepat, kembalikan hasil yang ringkas, dan putuskan izin dengan hati-hati. MCP Inspector, alat developer resmi, memungkinkan kita terhubung ke server, mencantumkan alat-alatnya, dan memanggilnya secara manual, yang sangat berharga untuk menguji server sebelum kita melampirkannya ke model.

Jika terjadi kesalahan, tujuh langkah tersebut juga berfungsi sebagai daftar periksa debugging. Jika model tidak pernah menggunakan alat tersebut, periksa penemuan dan deskripsi alat tersebut. Jika panggilan gagal, periksa argumen terhadap skema, otentikasi, dan log server itu sendiri. Jika hasilnya tampak buruk, lihat apa yang dikembalikan server dan apakah terlalu panjang, terlalu samar, atau dalam bentuk yang salah. Dan jika perilaku tampak aneh setelah peningkatan, periksa revisi protokol mana yang digunakan oleh masing-masing pihak.


Jadi, MCP memecahkan masalah yang tampaknya sederhana, yaitu bagaimana membiarkan aplikasi AI menggunakan alat dan data tanpa menulis integrasi khusus untuk setiap pasangan. Solusinya adalah pembagian kerja yang bersih. Host melakukan koordinasi. Klien mempertahankan satu koneksi masing-masing. Server mengekspos alat, sumber daya, dan perintah dalam bentuk standar. Penemuan memberi tahu klien apa yang tersedia. Pemanggilan menjalankan permintaan model. Sistem eksternal melakukan pekerjaan sebenarnya. Dan hasilnya mengalir kembali sehingga model dapat melanjutkan.