Pada tulisan sebelumnya, kita bahas kenapa MCP muncul dan kenapa ini relevan untuk SOC. Sekarang pertanyaannya lebih teknis, kalau MCP adalah protokol standar, sebenarnya dia bekerja seperti apa?

Sebelum masuk terlalu dalam, saya ingin memisahkan dua hal yang sering tercampur ketika membaca dokumentasi MCP: 1. Siapa saja yang terlibat 2. Bagaimana mereka berkomunikasi

1. Komponen: Bukan Sekadar "Model Panggil Tool"

Waktu pertama kali baca dokumentasinya, saya sempat mengira MCP itu cuma standardisasi tool calling. Tapi ternyata strukturnya lebih rapi karena MCP mengikuti pola Host → Client → Server Bukan cuma dua layer, berikut komponen yang ada pada MCP

Host: Tempat Model "Berpikir"

Host itu environment tempat model berjalan contohnya

  • Claude Desktop
  • IDE dengan AI assistant
  • Agent internal untuk SOC
  • Chat interface dengan tool integration

Host mengelola:

  • Konteks percakapan
  • Reasoning model
  • Keputusan kapan perlu memanggil tool

Kalau dianalogikan ke SOC: Host itu seperti analis yang memutuskan, "Ini perlu cek SIEM dulu." "Atau langsung pivot ke threat intel?"

Host bukan eksekutor. Dia pengambil keputusan.

Client: Layer yang Sering Terlewat

Ini bagian yang sering tidak disadari. Setiap koneksi ke MCP Server diwakili oleh satu client. Artinya Kalau host terhubung ke:

  • QRadar
  • OpenCTI
  • REMnux

Maka ada tiga client berbeda. Kenapa tidak langsung host ke server? Karena tiap server bisa punya:

  • Transport berbeda
  • Capability berbeda
  • Lifecycle session berbeda

Client ini seperti adaptor khusus per sistem.

Kalau kita analogikan ke SOC: Client itu seperti connector API yang dedicated untuk tiap tool.

Server: Penyedia Capability, Bukan Otak

MCP Server tidak melakukan reasoning. Dia tidak "memutuskan". Dia hanya menyediakan capability. Dan capability itu tidak cuma berupa tools. Di dokumentasi resmi MCP, server menyediakan yang disebut primitives:

  • Tools
  • Resources
  • Prompts
  • Notifications

Artinya komunikasi bukan cuma "jalankan fungsi". Ada struktur lebih luas dari itu.

2. Layer: MCP Dibangun di Atas JSON-RPC

Kalau komponen menjelaskan siapa yang terlibat, layer menjelaskan bagaimana komunikasi terjadi. Di antara client dan server terdapat stack komunikasi.

Terdapat beberapa lapisan yang masing-masing punya tanggung jawab berbeda. Semua komunikasi di data layer menggunakan JSON-RPC. Artinya setiap request dan response punya struktur formal. Layer ini adalah mekanisme komunikasi yang digunakan client dan server.

Transport Layer

Ini lapisan paling bawah.Fungsinya sederhana untuk mengirim dan menerima pesan. Transport bisa berupa:

  • stdio untuk koneksi lokal
  • Streamable HTTP untuk koneksi remote

Transport tidak peduli isi pesan. Dia tidak tahu itu tool call atau negotiation. Dia hanya memastikan byte sampai dari satu sisi ke sisi lain. Pemisahan ini penting karena membuat protokol fleksibel. Kalau suatu saat transport berubah, data layer tidak perlu diubah.

Data Layer

Di atas transport ada data layer. MCP menggunakan JSON-RPC sebagai mekanisme encoding pesan. Artinya, setiap pesan memiliki struktur formal. Kalau belum familiar, JSON-RPC merupakan protokol sederhana berbasis JSON untuk melakukan remote procedure call. Intinya, satu pihak bisa "memanggil metode" di pihak lain dengan format yang terstruktur. Strukturnya selalu konsisten:

  • method → apa yang ingin dipanggil
  • params → parameter yang dikirim
  • id → identifier untuk mencocokkan request dan response
  • result atau error → hasil eksekusi

Contoh minimal request:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools.call",
  "params": {
    "name": "search_logs",
    "arguments": {
      "host": "srv-prod-01"
    }
  }
}

Dan response-nya:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "event_count": 42
  }
}

Kenapa ini penting? Karena JSON-RPC membuat komunikasi:

  • Deterministik
  • Bisa divalidasi
  • Tidak ambigu
  • Lebih mudah di-handle secara programatik

Ini bukan sekadar detail teknis. Dalam sistem yang akan terhubung ke banyak tool dan mungkin sistem kritikal, komunikasi yang terstruktur jauh lebih aman dibanding parsing teks bebas.

Application Layer (Protocol Primitives)

Selain 2 Layer sebelumnya, terdapat satu layer lagi yang cukup penting, yakni Application Layer. Kalau sebelumnya transport menjawab "lewat mana pesan dikirim", dan data layer menjawab "format pesannya seperti apa", maka application layer menjawab sebenarnya mereka sedang membicarakan apa?

Di layer inilah komunikasinya terjadi. MCP menyebut hal-hal yang bisa dikomunikasikan ini sebagai primitives. Yang paling sering dibahas tentu saja tools. Tools adalah fungsi yang bisa dipanggil oleh host. Contohnya dalam konteks SOC:

  • search_logs
  • query_indicator
  • analyze_file

Host memutuskan tool mana yang dipanggil, lalu server mengeksekusinya. Tapi MCP tidak berhenti di tools. Ada juga resources. Resources lebih ke sumber data yang bisa diambil, bukan aksi yang dieksekusi. Misalnya daftar rule, daftar indikator, atau metadata tertentu.

Lalu ada prompts. Ini memungkinkan server menyediakan template atau struktur interaksi tertentu yang bisa digunakan oleh host. Dan ada juga notifications. Server bisa memberi tahu host kalau ada perubahan, misalnya daftar tools diperbarui atau resource berubah. Artinya, komunikasi di layer ini bukan sekadar "Jalankan fungsi dan beri hasil." Tapi lebih luas, ada konsep capability yang bisa ditemukan, diambil, dipanggil, dan diperbarui.

Kalau ditarik ke dunia SOC, ini mirip seperti perbedaan antara:

  • Menjalankan query ke SIEM (aksi aktif)
  • Mengambil daftar rule yang tersedia (data statis)
  • Mendapat notifikasi kalau rule berubah

Semua itu berbeda jenis interaksi dan MCP memodelkannya secara eksplisit. Itulah kenapa disebut application layer. Karena di sinilah semantik sistem didefinisikan.

Transport dan JSON-RPC hanya cara berbicara Primitives adalah isi pembicaraannya

Kontekstualisasi ke Workflow SOC

Supaya tidak berhenti di konsep, mari kita tarik semua komponen dan layer tadi ke satu contoh konkret. Ambil skenario sederhana.

Alert masuk dari EDR > Ada file hash yang mencurigakan > Get malicious file >Analis ingin melakukan analisis cepat

Sekarang bayangkan environment ini sudah terintegrasi dengan REMnux MCP Server.

Dari Sisi Komponen

Host Host bisa berupa AI agent SOC, IDE Agent, atau Claude Desktop yang sudah terhubung ke beberapa MCP server. Di sinilah model melakukan reasoning. Model melihat konteks file sesuai prompt yang dilakukan analis untuk dianalisis lebih lanjut.

Client Karena REMnux adalah sistem terpisah, koneksinya direpresentasikan oleh satu client khusus. Client ini menangani koneksi ke REMnux MCP Server, misalnya lewat stdio jika berjalan lokal.

Server REMnux MCP Server membungkus berbagai capability yang ada di REMnux:

  • Static analysis tool
  • String extraction
  • PE analysis
  • IOC extraction

Server tidak berpikir. Dia hanya menyediakan capability tersebut sebagai primitives.

Dari Sisi Layer

Sekarang lihat dari layer komunikasi

Application Layer Host memanggil tool, misalnya:

  • analyze_file
  • extract_ioc
  • identify_file_type

Ini adalah primitives yang tersedia di REMnux MCP Server. Di layer ini, yang terjadi adalah interaksi dimana host meminta analisis file tertentu.

Data Layer (JSON-RPC) Permintaan itu tidak dikirim sebagai teks bebas. Dia dikirim sebagai structured request:

  • Method yang jelas
  • Parameter terdefinisi
  • ID untuk tracking response

Secara teknis ini bukan "model ngomong ke tool". Ini adalah pemanggilan metode yang terstruktur dan bisa diaudit.

Transport Layer Kalau REMnux berjalan di mesin lokal analis, komunikasi bisa lewat stdio. Kalau REMnux berada di server terpisah, bisa lewat HTTP

Selanjutnya : MCP dalam Workflow SOC

Sampai di sini, kita sudah membedah dua hal penting dalam arsitektur MCP

  • Siapa saja yang terlibat (Host, Client, Server)
  • Bagaimana mereka berkomunikasi (Application, Data, dan Transport layer)

Kalau dilihat sekilas, strukturnya emang terlihat teknis. Tapi ketika dikaitkan dengan workflow SOC yang memang penuh dengan multi-tool integration, desain ini akan terasa masuk akal.

Di tulisan berikutnya, kita akan berhenti membahas konsep dan akan mencoba eksplorasi alur konkretnya. Kita akan ambil contoh workflow SOC sederhana, lalu melihat bagaimana MCP benar-benar bekerja end-to-end menggunakan tools seperti REMnux MCP.