Arsitektur MCP: Uraian Teknis Lengkap dengan Diagram

Arsitektur MCP adalah serangkaian komponen dan aturan komunikasi dasar yang memungkinkan MCP (Model Context Protocol) berfungsi. MCP adalah standar sumber terbuka, dan arsitektur MCP adalah infrastruktur dasar tempat standar tersebut berjalan.

Setiap arsitektur MCP berisi dan dibangun di sekitar tiga komponen inti: host, klien, dan server. Kerangka komunikasi MCP sering digambarkan terdiri atas lapisan data dan lapisan transport. Lapisan data adalah serangkaian aturan tentang cara pesan diformat (permintaan MCP dikirim dalam JSON-RPC 2.0). Lapisan transport membawa pesan-pesan tersebut dan menggunakan Streaming HTTP untuk koneksi eksternal.

Arsitektur MCP adalah kerangka kerja server yang menerapkan Model Context Protocol, sebuah standar terbuka untuk menghubungkan model AI ke alat, sumber daya seperti basis data, dan prompt yang memperluas konteks input. Semua ini secara kolektif disebut “primitif”. Pada akhirnya, arsitektur MCP memungkinkan LLM menemukan alat yang tersedia dan menjalankan alur kerja, tanpa memerlukan pembaruan rutin di sisi klien.

Diagram arsitektur MCP: aplikasi AI bertukar permintaan dengan server MCP, yang menyediakan alat, sumber daya, dan prompt.

Sejak diperkenalkan oleh Anthropic, arsitektur MCP telah digunakan secara luas dalam alur kerja AI. Hal ini terutama karena arsitektur ini menggantikan sistem yang membutuhkan lebih banyak pemeliharaan, seperti sistem yang dibangun di atas beberapa koneksi API, tanpa mengorbankan performa. Karena semua fungsionalitas yang tersedia berada di balik server MCP, hanya diperlukan satu koneksi, dan pembaruan serta penambahan langsung tersedia bagi aplikasi klien.

MCP memberi LLM sarana untuk menemukan dan memanggil alat, prompt, dan sumber daya yang tersedia baginya, baik di sistem lokal aplikasi host maupun dari penyedia eksternal.

Dalam kasus alat, yang menyediakan akses ke fungsionalitas eksternal, penemuan melibatkan host yang melakukan panggilan tools/list ke server MCP untuk mengetahui alat mana yang tersedia. LLM (atau dalam beberapa kasus, host) kemudian dapat membaca deskripsi alat yang tersedia dan memintanya sesuai kebutuhan. Prompt dan sumber daya menggunakan proses yang serupa.

Diagram komponen arsitektur MCP: host yang berisi LLM, orkestrator, dan klien terhubung ke server MCP dalam dua langkah, yaitu penemuan lalu permintaan, dan server MCP mengekspos alat, sumber daya, dan prompt.

Hal ini berbeda dengan arsitektur berbasis API yang dibuat khusus, yang selama ini menjadi norma dalam pengembangan perangkat lunak, di mana fungsionalitas di luar aplikasi harus dipanggil menggunakan koneksi khusus dengan permintaan yang diformat secara presisi.

Aplikasi host adalah platform orkestrasi pusat dan terhubung ke LLM. Alat terkenal seperti Perplexity dan Claude Desktop dapat berperan sebagai host dalam sistem MCP.

Dalam alur kerja sederhana, pengguna mengajukan pertanyaan melalui antarmuka chat. Komponen orkestrator pada host kemudian menambahkan konteks ke pertanyaan tersebut, yang memberi tahu LLM primitif MCP mana yang tersedia beserta deskripsi kemampuannya.

Klien adalah komponen perangkat lunak dalam aplikasi AI. MCP menyediakan antarmuka standar bagi klien untuk berkomunikasi dengan server MCP internal dan eksternal berdasarkan instruksi dari host atau LLM. Tugasnya adalah membuat koneksi, memformat pesan JSON-RPC, mengirim permintaan, dan menerima respons.

Istilah “host MCP” dan “klien MCP” terkadang digunakan secara bergantian. Namun, perbedaan ini berguna karena host, seperti Perplexity, dapat mengorkestrasi beberapa klien MCP sekaligus. Alur kerja AI yang kompleks dapat memerlukan akses ke puluhan atau bahkan ratusan server MCP yang terpisah, dan masing-masing akan menggunakan koneksi tersendiri.

Diagram host MCP, seperti Perplexity, yang mengorkestrasi tiga klien MCP, masing-masing terhubung ke server MCP-nya sendiri, seperti basis data, file, atau API eksternal.

Server mengekspos semua alat yang dapat digunakan oleh alat berbasis AI. Dari perspektif arsitektur, server MCP menafsirkan permintaan yang masuk dan, bila diperlukan, terhubung ke primitif yang diminta.

Server MCP dapat menyediakan akses ke tiga kategori primitif:

Alat: Pada dasarnya, ini adalah fungsionalitas perangkat lunak eksternal. Dalam pendekatan tradisional berbasis API, aplikasi analitik web mungkin mengambil data menggunakan permintaan berformat ke server eksternal. Dalam arsitektur MCP, semua fungsionalitas pihak ketiga dari suatu penyedia tersedia melalui satu koneksi, dan permintaan dibuat dengan aturan format standar.
Sumber daya: Sumber daya adalah sumber data yang menyediakan konteks hanya-baca. Skema basis data adalah contoh yang baik. Server MCP mengekspos berbagai sumber informasi yang tersedia bagi host. Jika host mengkueri basis data, misalnya dengan pencarian SQL yang dihasilkan LLM, hal ini dianggap sebagai permintaan alat.
Prompt: Ini adalah templat prompt yang dapat digunakan kembali untuk membantu LLM melakukan tugas tertentu. Pengguna atau host akan memanggil prompt alih-alih alat karena tugas tersebut memerlukan instruksi siap pakai untuk diselesaikan. Sering kali, tugas yang telah ditetapkan sebelumnya dalam aplikasi host, seperti opsi untuk “meninjau kode” atau “menganalisis data”, disimpan sebagai prompt yang dapat dipilih pengguna.

Perlu juga dicatat bahwa MCP dan API bukanlah teknologi yang saling eksklusif. Server MCP dapat mengekspos panggilan API yang tersedia sebagai respons terhadap permintaan penemuan. Intinya, penyedia MCP-lah yang bertanggung jawab memelihara panggilan tersebut, bukan klien.

Lapisan data dalam arsitektur MCP adalah serangkaian aturan yang menentukan cara permintaan, respons, dan notifikasi diformat. Bahasa standar untuk pesan adalah JSON-RPC.

Semua arsitektur MCP mengikuti proses dasar berupa (1) inisialisasi dan penemuan oleh host, (2) respons oleh server MCP, dan (3) panggilan oleh host (terkadang diputuskan oleh LLM), dengan setiap tahap mewakili pesan JSON yang terpisah.

Diagram lapisan data MCP: pengguna mengirim prompt ke aplikasi host, tempat LLM bekerja dengan klien MCP; klien mengirim permintaan ke server MCP (alat, sumber daya, prompt) dan menerima hasil, lalu host mengembalikan respons kepada pengguna.

Mari kita lihat cara kerja penemuan alat melalui dua contoh (contoh ini juga dapat berlaku untuk sumber daya atau prompt):

Temukan alat sebelum LLM menghasilkan respons: Host menginisiasi klien MCP, yang mengirim permintaan tools/list (daftar alat yang tersedia di server MCP). LLM meninjau daftar ini selama proses pembuatan respons dan menentukan apakah alat, sumber daya, atau prompt tertentu diperlukan.
Berikan LLM opsi untuk menjalankan pencarian: Dalam sistem agentik, host menambahkan opsi penemuan, seperti search-tools, ke input konteks, dan LLM dapat meminta pencarian jika diperlukan.

Alat, yang sebagian besar merupakan fungsionalitas aplikasi eksternal, biasanya dipilih oleh LLM atau host. Sumber daya dan prompt biasanya diminta atas permintaan pengguna atau oleh host.

Berikut contoh permintaan tools/list ke server MCP dari aplikasi catatan fiktif:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Dalam contoh ini, “id”:101 mengidentifikasi permintaan menggunakan ID agar klien dapat mencocokkan respons, dan kolom “params” berisi informasi tambahan tentang klien, seperti nama klien (notes-app-client) dan kemampuannya.

Sebagai respons, server MCP akan mengembalikan definisi alat, yang mencakup nama alat yang tersedia beserta detail terkaitnya. Misalnya, daftar tersebut mungkin menyertakan alat add-task yang memungkinkan aplikasi catatan membuat tugas di aplikasi manajemen tugas atau kalender yang terhubung, dengan menetapkan judul dan prioritas untuk setiap tugas.

Berikut contoh tampilan sebuah permintaan:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Kolom “method” memberi tahu server MCP bahwa ini adalah panggilan alat, “name” menentukan alat mana yang akan dipanggil, dan “arguments” menyediakan input yang diperlukan.

Jika lapisan data adalah apa dari koneksi antara klien dan server MCP, maka lapisan transport adalah bagaimana. Lapisan ini menentukan cara pesan berpindah: saluran spesifik dan aturan yang mengatur cara permintaan dan respons dikirimkan.

MCP memiliki dua jalur transport:

Input/output standar: Jalur ini digunakan ketika server MCP berjalan di lingkungan lokal yang sama dengan aplikasi host. Klien menulis permintaan JSON ke input standar server. Server membacanya, menjalankan operasi yang diminta, dan menulis respons ke output standar.
Streamable HTTP: Ketika server MCP berjalan di luar aplikasi host, klien MCP mengirim permintaan ke server menggunakan HTTP POST. Server merespons dengan satu pesan JSON atau dengan stream Server-Sent Events (SSE), yaitu saluran “mendengarkan” yang persisten, sehingga server dapat mengembalikan beberapa pesan dari waktu ke waktu.

Arsitektur multi-tenant MCP adalah jenis implementasi yang dapat melayani banyak pengguna (tenant) secara bersamaan.

Di sini, tenant dapat berupa individu, sekelompok individu, atau organisasi. Implementasinya dapat berupa menjalankan server MCP terpisah untuk setiap tenant, menyediakan akses ke satu server bersama, atau menempatkan sekumpulan server di balik gateway pusat. Jika gateway digunakan, gateway akan merutekan permintaan ke endpoint yang tepat berdasarkan identitas pengguna atau sifat permintaan.

Arsitektur ini bekerja berdasarkan prinsip dasar yang sama dengan arsitektur MCP standar, tetapi setiap permintaan pengguna beroperasi di ruang kerjanya sendiri (meskipun melibatkan sumber daya bersama) dan diautentikasi secara terpisah. Arsitektur ini umum dalam skenario perusahaan, dan sumber daya bersama sering kali lebih dipilih karena menjalankan banyak server MCP akan memakan biaya yang tidak perlu.

Seperti apa permintaan MCP dari awal hingga akhir dalam praktiknya? Ada delapan tahap inti, yang masing-masing melibatkan komponen arsitektur yang berbeda.

Diagram alir permintaan MCP dari awal hingga akhir dalam delapan langkah: penemuan alat, input pengguna, pemrosesan model, pemilihan alat, permintaan, eksekusi alat, hasil, dan pembuatan jawaban.

Berikut contoh panggilan alat MCP dalam praktiknya, menggunakan contoh sebelumnya, yaitu aplikasi catatan yang terhubung ke layanan manajemen tugas:

Penemuan alat: Aplikasi catatan (host) menggunakan klien MCP-nya untuk meminta daftar alat yang tersedia di server melalui permintaan tools/list. Server mengembalikan nama, deskripsi, dan input yang diharapkan dari alat-alat tersebut, termasuk untuk alat add-task. Proses ini dapat terjadi sebelum Anda mengirimkan prompt.
Input pengguna: Anda mengirimkan permintaan ke aplikasi catatan berbasis LLM melalui chatbot dalam aplikasi, misalnya, “Buat tugas di kalender saya untuk meninjau draf baru saya dengan prioritas sedang.”
Pemrosesan model: Host mengirimkan permintaan Anda beserta definisi alat yang relevan ke LLM.
Pemilihan alat: LLM menghasilkan permintaan alat yang terstruktur, yang menentukan alat dan inputnya: add-task dengan title: Review the draft dan priority: Medium. Host memeriksa apakah tindakan tersebut diizinkan dan meneruskan permintaan ke klien MCP, yang kemudian mengirim pesan JSON-RPC.
Permintaan: Klien MCP mengirimkan permintaan tools/call ke server MCP-nya.
Eksekusi alat: Server MCP memanggil API aplikasi manajemen tugas untuk membuat tugas baru dengan judul dan prioritas yang ditentukan.
Pengembalian hasil: Server mengirimkan hasilnya kembali ke klien MCP, yang meneruskannya ke host. Host menambahkannya ke informasi yang diberikan kepada LLM.
Pembuatan jawaban: LLM menggunakan hasil tersebut untuk membuat jawaban bagi pengguna, misalnya “Saya telah membuat tugas untuk meninjau draf dengan prioritas sedang.”

MCP dan arsitektur API tradisional sering tertukar, padahal keduanya merupakan teknologi yang saling melengkapi. MCP dirancang khusus untuk aplikasi berbasis AI. MCP mengatasi beban pemeliharaan yang tinggi dalam menerapkan dan mengelola banyak koneksi API yang di-hardcode.

Dengan menyediakan satu koneksi per penyedia fungsionalitas atau sumber daya internal bagi aplikasi host, MCP membantu mengatasi masalah input konteks yang membengkak (mencantumkan semua API) atau skrip aplikasi berbasis API yang terbatas.

Sebagai gantinya, MCP dapat mengekspos API (atau lebih tepatnya, fungsionalitas yang memanggil API) sebagai bagian dari daftar alatnya. Setiap kali penyedia memperbarui aplikasinya dan ada API baru, atau jika dokumentasi berubah, mereka cukup memperbarui server MCP. Tidak diperlukan perubahan kode di sisi aplikasi host.

Keamanan MCP telah menjadi topik banyak perdebatan sejak diperkenalkan. Meskipun umumnya dianggap sebagai teknologi yang aman, ada beberapa risiko keamanan, yang banyak di antaranya lebih menonjol dalam implementasi arsitektur yang kompleks.

Arsitektur MCP memiliki potensi kelemahan berikut:

Injeksi prompt: Pengguna menyisipkan prompt berbahaya ke dalam data eksternal yang kemudian disalahartikan oleh model AI sebagai instruksi.
Akses dengan hak istimewa berlebih: Server MCP berpotensi mengekspos banyak alat ke model AI, yang dapat meningkatkan potensi masalah keamanan (radius dampak).
Kebocoran data yang tidak disengaja: Implementasi yang dikonfigurasi dengan buruk dapat menyebabkan informasi sensitif, seperti kunci API atau kredensial basis data, diteruskan ke LLM.
Manipulasi sistem lokal: Seperti aplikasi lainnya, server MCP lokal juga rentan terhadap masalah sistem lokal, seperti skrip berbahaya, dengan masalah tambahan bahwa server tersebut dapat menimbulkan dampak berbahaya lanjutan pada sistem AI agentik.

Tidak satu pun dari masalah ini yang tidak dapat diatasi. Sering kali, langkah-langkah yang sudah mapan sudah cukup untuk memastikan keamanan sistem. Langkah-langkah seperti melibatkan manusia dalam proses (human in the loop), menerapkan kontrol ketat terhadap data sensitif, dan melindungi dari serangan server merupakan praktik yang umum.

MCP telah terbukti menjadi standar terbuka yang berguna dan populer bagi para pengembang. MCP mengatasi banyak masalah API yang di-hardcode dalam aplikasi berbasis LLM dan secara signifikan mengurangi beban pengodean bagi pengembang.

Ke depannya, arsitektur dasar host dan server MCP hampir pasti akan tetap sama. Inovasi di masa depan akan berpusat pada kemampuan agentik tingkat lanjut di seluruh alur kerja multi-langkah.

Selain itu, perlindungan keamanan yang lebih kuat akan dibutuhkan seiring diterapkannya fungsionalitas agentik tersebut, begitu pula arsitektur yang skalabel, terutama di lapisan transport, seiring sistem AI menjadi makin luas dan kompleks.

Apa itu arsitektur MCP?

Komponen arsitektur MCP: Host, klien, dan server

Host

Klien

Server

Apa itu lapisan data dalam arsitektur MCP?

Apa itu lapisan transport dalam arsitektur MCP?

Apa itu arsitektur multi-tenant MCP?

Diagram arsitektur MCP: Panduan langkah demi langkah

Apa perbedaan arsitektur MCP dengan arsitektur API tradisional?

Apakah arsitektur MCP aman?

Apa selanjutnya untuk arsitektur MCP?