Belajar MCP - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Setelah memahami sejarah dan motivasi MCP di episode 1, sekarang saatnya membedah bagaimana protokol ini sebenarnya bekerja. Episode ini adalah fondasi paling penting di seluruh series: arsitektur tiga lapis dan primitives yang akan kita pakai terus sampai episode terakhir.

Kalian akan belajar siapa berperan sebagai apa (Host, Client, Server), apa saja yang bisa di-expose oleh server (tools, resources, prompts), dan lewat media apa mereka berkomunikasi (transport). Paham episode ini, dan semua episode berikutnya — dari SDK sampai deployment — tinggal soal detail implementasi.

#Arsitektur Tiga Lapis: Host, Client, dan Server

MCP dibangun di atas tiga peran yang tegas:

Aturan emasnya: satu client terhubung ke satu server. Jika host ingin berbicara dengan banyak server, host punya banyak client — masing-masing dengan koneksinya sendiri. Tidak ada satu client yang terhubung ke banyak server sekaligus.

Alur komunikasi dari sudut pandang model: model hidup di dalam host, host memakai client untuk memanggil server, dan server menjawab lewat client kembali ke host. Kalian bisa membayangkan client sebagai "kabel" dan server sebagai "colokan" — setiap kabel menancap ke satu colokan.

#Primitives: Apa yang Bisa Di-expose Server

Server MCP men-expose tiga primitives utama:

#Tools

Tools adalah fungsi yang bisa dipanggil model untuk melakukan aksi: menulis file, mengirim email, menjalankan query, memanggil API eksternal. Tools digambarkan dengan JSON Schema sehingga model tahu parameter apa yang harus diisi. Kita akan membedah tools secara mendalam di episode 4.

#Resources

Resources adalah data konteks yang bisa dibaca model — seperti isi file, hasil query, atau dokumentasi. Berbeda dengan tools yang melakukan aksi, resources bersifat pasif: model membaca, bukan mengeksekusi. Contoh method-nya: resources/read. Episode 5 akan membahasnya.

#Prompts

Prompts adalah template reusable yang dirancang untuk menyelesaikan tugas tertentu — misalnya template "rangkum meeting" atau "generate commit message". Host menampilkan daftar prompt kepada pengguna, lalu template dengan argumen tertentu dikirim ke model. Detailnya di episode 5.

#Transport: Media Komunikasi Server

Primitives hanya masuk akal kalau ada media yang menghubungkannya. MCP punya tiga pilihan transport:

#Streamable HTTP (Modern)

Streamable HTTP adalah transport standar untuk server remote di era modern. Ia memakai request/response JSON-RPC biasa di atas HTTP, ditambah SSE stream untuk notifikasi dan streaming hasil yang panjang. Server bisa stateless, mudah di-scale, dan menjadi fondasi era 2026-07-28.

#SSE (Legacy)

Server-Sent Events (SSE) adalah transport asli MCP saat pertama dirilis 2024-11-05. Ia mengandalkan koneksi SSE yang panjang dan dianggap legacy sejak 2025-03-26 — masih didukung untuk kompatibilitas, tapi bukan pilihan untuk server baru. Tiap SSE endpoint hanya melayani satu client, yang membatasi skalabilitas.

#stdio (Lokal)

stdio menjalankan server sebagai subprocess lokal dan berkomunikasi lewat stdin/stdout. Ini transport paling sederhana dan cocok untuk integrasi lokal — misalnya CLI agents, editor, dan tooling developer. Data hanya dikirim sebagai JSON per baris, tanpa perlu jaringan.

#Satu Contoh Alur Lengkap

Mari kita ikuti satu percakapan MCP sederhana dari awal sampai akhir. Bayangkan model (di dalam host) ingin tahu cuaca hari ini:

1. Host memanggil tools/list lewat client untuk melihat tool apa yang tersedia di server cuaca.
2. Server menjawab dengan daftar tool, salah satunya get_weather yang membutuhkan parameter city.
3. Model memutuskan memakai tool itu dan meminta host memanggil tools/call dengan argumen kota pengguna.
4. Client mengirim request ke server, server mengeksekusi logika cuaca, lalu mengembalikan hasilnya.
5. Host memberikan hasil ke model, dan model menyusun jawaban akhir untuk pengguna.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Ambil cuaca terkini untuk sebuah kota",
        "inputSchema": {
          "type": "object",
          "properties": {
            "city": { "type": "string" }
          },
          "required": ["city"]
        }
      }
    ]
  }
}

Semua langkah itu tidak lain adalah request/response JSON-RPC — seperti yang sudah kalian kenal di episode 0. Transport hanya menentukan di mana JSON-RPC ini dikirim: lewat HTTP, SSE, atau stdin. Nanti di episode 7 kita akan mengamati alur ini secara langsung lewat npx @modelcontextprotocol/inspector.

#Penutup

Pada episode 2 ini kalian sudah memahami arsitektur tiga lapis MCP (Host, Client, Server), tiga primitives utama (tools, resources, prompts), primitives yang didepresiasi (roots, sampling, logging), dan tiga pilihan transport (Streamable HTTP, SSE, stdio) beserta kapan memakainya.

Inti yang harus dibawa pulang:

• Satu client selalu terhubung ke satu server; host bisa memiliki banyak client.
• Tools melakukan aksi, Resources menyediakan konteks, Prompts menyediakan template.
• Transport modern adalah Streamable HTTP; SSE adalah legacy; stdio untuk integrasi lokal.
• Semua komunikasi berbasis JSON-RPC 2.0, apapun transportnya.

Di episode 3 berikutnya kita akan membahas lifecycle koneksi MCP — bagaimana koneksi dimulai, apa itu session state pada era legacy, dan bagaimana era stateless 2026-07-28 mengubah segalanya lewat server/discover. Sampai jumpa di episode 3!