Jawaban langsung: cara kerja MCPMCPAturan standar yang memungkinkan program AI memakai alat dan data Anda dengan izin yang jelas.Buka glosarium memakai pesan JSON-RPC 2.0 antara 3 peran: host (aplikasi AI), klien MCP (konektor di dalam host), dan MCP server. Saat pengguna bertanya, model memilih tool dari daftar yang server umumkan, lalu host meminta persetujuan. Klien mengirim tools/call, server menjalankan fungsi ke sistem sumber, dan hasilnya kembali ke model. Resource dan prompt mengikuti jalur serupa, tetapi aplikasi dan pengguna yang mengendalikannya.

Kondisi utama: alur ini mengikuti revisi 2026-07-28, era modern MCP. Tiap request membawa versi dan kemampuannya sendiri, dan tidak ada handshake initialize. Klien era legacy memakai handshake itu; era legacy dan modern pada 5 versi MCP menjelaskan bedanya, jadi artikel ini tidak mengulangnya. Batas: artikel ini tidak mengajarkan menulis kode server, tidak membahas OAuth secara detail, dan tidak membandingkan klien satu per satu. Contoh pesan di sini disederhanakan; skema resmi memuat field yang lebih lengkap.

Kami menulis artikel ini pada 13 September 2026 dari spesifikasi resmi Model Context Protocol revisi 2026-07-28, halaman arsitekturnya, dan skema TypeScript resminya. Artikel ini adalah penjelasan mekanisme pesan, jadi tanpa tangkapan layar produk. Tiap klaim membawa tautan sumber di dekatnya, dan daftar lengkap ada pada bagian Sumber di akhir halaman.

Masalah: "sudah support MCP" tidak menjelaskan cara kerja MCP

Vendor sering menulis "sudah mendukung MCP" pada halaman produknya (lihat definisi MCP di glosarium kami), tetapi klaim itu tidak menjelaskan siapa memanggil apa, dan di mana persetujuan pengguna terjadi.

Tanpa peta alur pesan, tim tidak bisa menilai risiko 1 tool tulis, atau menulis SOP persetujuan yang benar. Tim juga tidak tahu kapan server boleh membaca data, dan kapan hanya model yang memutuskan.

Artikel pengantar MCP kami menjelaskan definisi dan kosakata dasar. Artikel ini mulai dari langkah berikutnya: alur pesan 1 panggilan tool, dari pertanyaan pengguna sampai jawaban yang mereka terima.

3 peran dan hubungan 1 klien untuk 1 server

MCP menyambungkan 3 peran lewat pesan JSON-RPC 2.0: host, klien MCP, dan MCP server. Tiap peran punya tugas sendiri, dan tiap klien MCP bicara dengan tepat 1 server. Sumber: spesifikasi resmi MCP.

Topologi MCP: 1 host dengan 3 klien MCP, tiap klien tersambung ke 1 MCP server yang berbeda, dan server tidak saling melihat
Tiap klien (1) berbicara dengan 1 server. Server (2) tidak melihat percakapan penuh atau server lain. Persetujuan (3) terjadi di host.

Host: aplikasi AI yang memulai koneksi

Host adalah aplikasi AI yang dipakai pengguna, misalnya Claude Desktop. Host membuat dan mengelola beberapa klien MCP sekaligus, dan menegakkan kebijakan keamanan serta persetujuan pengguna. Sumber: arsitektur MCP.

Klien MCP: konektor di dalam host

Klien MCP adalah konektor di dalam host. Setiap klien punya hubungan 1 banding 1 dengan 1 server; 1 klien tidak pernah bicara dengan 2 server sekaligus. Host menambah 1 klien baru untuk tiap server baru yang tersambung. Sumber: arsitektur MCP.

MCP server: penyedia tool, resource, dan prompt

MCP server menawarkan sampai 3 fitur ke klien: tool (fungsi yang dijalankan model), resource (data konteks), dan prompt (templat pesan). Prinsip desainnya membuat server tidak bisa membaca seluruh percakapan pengguna, dan tidak melihat server lain yang tersambung ke host yang sama. Persetujuan pengguna terjadi di host, bukan di server. Sumber: arsitektur MCP.

Alur 1 panggilan tool dari pertanyaan sampai jawaban

Simulasi berikut mengikuti 1 pertanyaan pengguna sampai jawaban yang mereka terima, dalam 7 tahap. Tiap tahap berpindah antara host, klien MCP, dan MCP server.

Diagram urutan 7 tahap 1 panggilan tool MCP: server/discover, tools/list, pemilihan tool oleh model, persetujuan di host, tools/call, hasil atau isError, jawaban
Tahap (1) sampai (3) menyiapkan daftar tool. Persetujuan (4) mendahului tools/call (5). Hasil (6) bisa berupa data atau isError yang dipakai model untuk memperbaiki input.

Tahap 1: server mengumumkan versi dan kemampuannya

Klien memanggil server/discover untuk membaca versi protokol, kemampuan, dan identitas server. Server modern wajib menyediakan RPC ini. Sumber: halaman versi protokol MCP.

Tahap 2: klien membaca daftar tool dengan tools/list

Klien memanggil tools/list untuk membaca daftar tool yang server tawarkan, lengkap dengan nama, deskripsi, dan skema input tiap tool.

Tahap 3: model memilih tool dari daftar

Tool bersifat dikendalikan model: model menemukan dan memanggil tool berdasarkan konteks percakapan dan perintah pengguna. Sumber: spesifikasi tool MCP.

Tahap 4: host meminta persetujuan pengguna

Sebelum eksekusi berjalan, harus selalu ada manusia dalam alur yang bisa menolak pemanggilan tool. Host menampilkan konfirmasi sebelum mengirim tools/call. Sumber: spesifikasi tool MCP.

Tahap 5: klien mengirim tools/call dengan argumen

Klien mengirim tools/call berisi nama tool dan argumen sesuai skema input tool itu. Server menjalankan fungsi ke sistem sumber, misalnya database atau APIAPIPintu resmi yang dipakai 2 sistem untuk saling mengirim data, tanpa orang menyalin data secara manual.Buka glosarium internal.

Tahap 6: server mengembalikan hasil atau isError

Hasil tool punya 2 jenis error: error protokol untuk pesan yang salah bentuk, dan error eksekusi tool dengan isError: true. Error eksekusi kembali ke model, dan model bisa memakainya untuk memperbaiki argumen. Sumber: spesifikasi tool MCP.

Tahap 7: model menyusun jawaban untuk pengguna

Model membaca hasil tool, lalu menyusun jawaban dalam bahasa pengguna. Jika hasilnya isError, model boleh mencoba lagi dengan argumen yang diperbaiki, atau bertanya balik ke pengguna.

Revisi 2026-07-28 menghapus sesi protokol dan handshake initialize; tiap request membawa versi dan kemampuannya sendiri. MCP juga tidak punya sesi di level protokol, jadi state lintas panggilan memakai handle eksplisit yang dikirim sebagai argumen tool, bukan sesi tersembunyi. Sumber: changelog resmi MCP dan spesifikasi tool MCP.

Anatomi 1 tool: nama, deskripsi, inputSchema, anotasi

Definisi 1 tool punya 6 bagian: name, title, description, inputSchema berbentuk JSON SchemaSchemaKeterangan tambahan dalam kode halaman yang memberi tahu mesin pencari jenis isi halaman, misalnya artikel, layanan, atau tanya jawab.Buka glosarium, serta outputSchema dan annotations yang sifatnya pilihan. Sumber: spesifikasi tool MCP.

Nama tool sebaiknya 1 sampai 128 karakter: huruf, angka, garis bawah, tanda hubung, dan titik. Nama harus unik dalam 1 server, jadi model tidak salah pilih tool yang mirip.

Ada 4 anotasi tool: readOnlyHint dengan bawaan salah, destructiveHint dengan bawaan benar, idempotentHint dengan bawaan salah, dan openWorldHint dengan bawaan benar. Anotasi hanya petunjuk; klien tidak boleh mengambil keputusan dari anotasi server yang tidak tepercaya. Sumber: skema TypeScript resmi MCP.

{
  "name": "cek_stok",
  "title": "Cek stok barang",
  "description": "Baca jumlah stok 1 SKU dari sistem gudang.",
  "inputSchema": {
    "type": "object",
    "properties": { "sku": { "type": "string" } },
    "required": ["sku"]
  },
  "annotations": { "readOnlyHint": true, "openWorldHint": false }
}

Deskripsi tool bukan hanya dokumentasi; deskripsi itu bagian dari prompt yang model baca sebelum memilih tool. Artikel prompt engineering untuk AI agent kami membahas cara menulis deskripsi dan skema yang model pahami dengan benar.

Tool vs resource vs prompt vs elicitation

MCP server bisa menawarkan 4 fitur, dan tiap fitur dikendalikan pihak yang berbeda. Tabel berikut merangkum kapan tiap fitur dipakai.

Diagram siapa yang mengendalikan tiap fitur MCP: tool oleh model, resource oleh aplikasi host, prompt oleh pengguna, elicitation oleh server lewat klien; sampling dan roots deprecated
Pengendali berbeda pada baris (1) sampai (4) berarti kebijakan persetujuan berbeda. Baris abu (5) menandai fitur yang tidak boleh dipakai pada server baru.
FiturPengendaliDipakai saatBentuk dataContoh bisnis
ToolModel; host meminta persetujuanModel perlu data atau aksiFungsi dengan skema inputcek_stok, draf_invoice
ResourceAplikasi hostAplikasi menyiapkan konteksData dengan URI unikdaftar harga, skema tabel
PromptPenggunaPengguna memilih templatTemplat pesanringkas keluhan pelanggan
ElicitationServer, lewat klienServer butuh data tambahanForm atau URLminta konfirmasi nomor PO

Sumber: gambaran umum fitur server MCP, spesifikasi tool MCP, dan spesifikasi elicitation MCP.

Sampling dan Roots berstatus tidak berlaku lagi sejak revisi 2026-07-28; implementasi baru tidak boleh memakai keduanya. Fitur yang tidak berlaku lagi tetap ada sekurang-kurangnya 12 bulan sebelum boleh dihapus. Sumber: status Sampling dan status Roots.

2 transport: stdio dan Streamable HTTP

MCP mendefinisikan 2 transport standar: stdio dan Streamable HTTP. Transport menentukan cara pesan berpindah, bukan isi pesannya. Sumber: spesifikasi transport MCP.

stdio menjalankan server sebagai subprocess lokal di mesin pengguna. Pesan JSON-RPC berjalan 1 baris untuk 1 pesan lewat stdin dan stdout. Server tidak boleh menulis apa pun selain pesan MCP ke stdout; catatan log wajib memakai stderr. Sumber: spesifikasi transport stdio.

Streamable HTTP memakai 1 endpoint HTTP dengan 1 permintaan POST untuk 1 pesan. Server modern menjawab tiap permintaan dengan 1 objek JSON atau 1 aliran khusus permintaan itu. Tiap permintaan wajib membawa header versi protokol dan nama metode. Sumber: spesifikasi Streamable HTTP.

Tidak semua klien mendukung kedua transport dengan cara yang sama. Artikel klien MCP 2026 kami membandingkan dukungan stdio dan Streamable HTTP pada 10 klien populer. Pilihan hosting untuk Streamable HTTP ada pada artikel terpisah, jadi tidak diulang di sini.

Contoh: 1 panggilan cek_stok dari awal sampai akhir

Simulasi berikut memakai data dummy pada transport Streamable HTTP. SKU dan angka pada tabel ini bukan data pelanggan nyata.

Input (pesan yang dikirim)Tercatat di MCP serverOutput (yang kembali)
server/discoverVersi 2026-07-28, kemampuan tools, nama server "stok-toko"Daftar versi dan kemampuan server
tools/list2 tool: cek_stok dan cek_harga, keduanya readOnlyHint benarDefinisi tool dengan skema input
tools/call cek_stok, SKU KA-250, setelah persetujuanQuery ke spreadsheet stok; hasil 42; log mencatat waktu, tool, dan aktorHasil teks "42 unit" untuk model
tools/call cek_stok, SKU KA-999SKU tidak ditemukan; isError benar; pesan "SKU tidak ada"Model bertanya ulang SKU yang benar ke pengguna

Pesan ini disederhanakan; field _meta dan header HTTP tidak ditampilkan. Baris terakhir menunjukkan cara model memakai isError untuk memperbaiki argumen, bukan berhenti begitu saja. Sumber: spesifikasi tool MCP.

Checklist memahami alur sebelum memesan server

Tinjau 6 hal berikut sebelum tim Anda memesan atau membangun 1 MCP server.

  1. Tim bisa menggambar 7 tahap panggilan tool untuk 1 kasus nyata. Pemilik: product manager. Bukti: 1 diagram atau tabel.
  2. Setiap tool punya nama unik, deskripsi 1 kalimat, dan skema input. Pemilik: developer. Bukti: daftar tool.
  3. Tool tulis ditandai readOnlyHint salah, dan punya titik persetujuan di host. Pemilik: kepala IT. Bukti: tangkapan layar prompt persetujuan.
  4. State lintas panggilan memakai handle eksplisit, bukan sesi. Pemilik: developer. Bukti: contoh argumen handle.
  5. Tim memilih transport: stdio untuk lokal, Streamable HTTP untuk jarak jauh. Pemilik: kepala IT. Bukti: keputusan tertulis.
  6. Kriteria berhenti: bila 1 tool tidak bisa dijelaskan dalam 1 kalimat, tim memecah atau menghapus tool itu.

Pertanyaan yang sering diajukan

Apakah MCP server bisa membaca seluruh percakapan? Tidak. Prinsip desain MCP melarangnya. Server hanya menerima argumen tool yang klien kirim, bukan riwayat percakapan penuh.

Apa bedanya error protokol dan isError? Error protokol berarti pesan JSON-RPC salah bentuk. isError berarti eksekusi tool gagal, dan model bisa memakai pesan itu untuk memperbaiki argumen.

Apakah ada sesi di MCP? Tidak, pada revisi 2026-07-28. State lintas panggilan memakai handle eksplisit yang dikirim sebagai argumen tool, bukan sesi tersembunyi.

Apakah anotasi tool bisa dipercaya? Anotasi hanya petunjuk. Klien tidak boleh mengambil keputusan dari anotasi tool pada server yang tidak tepercaya.

Apa itu elicitation? Elicitation adalah cara server meminta data tambahan dari pengguna lewat klien, dalam mode form atau URL. Klien wajib menunjukkan server mana yang meminta.

Langkah berikutnya

Memahami 7 tahap ini adalah titik awal, bukan titik akhir. Artikel ini tidak membahas cara menulis kode server, dan tidak membandingkan klien secara rinci; artikel MCP vs API biasa vs plugin vs RAG kami membantu menilai kapan MCP layak dipakai untuk kasus Anda. Jika tim Anda ingin memesan Jasa Pembuatan MCP Server yang mengikuti alur ini, Kirim kebutuhan. Jika Anda ingin bertanya dulu, Jadwalkan konsultasi gratis.

Sumber