Apa dua transport MCP itu?

Model Context Protocol mendefinisikan stdio dan Streamable HTTP. stdio menjalankan server sebagai subprocess lokal yang berkomunikasi lewat standard input dan output, sedangkan Streamable HTTP menjalankannya sebagai layanan remote yang dijangkau lewat jaringan dengan respons yang mengalir. Pesan protokolnya identik di keduanya; hanya di mana server berjalan dan bagaimana ia dijangkau yang berubah.

Kapan sebaiknya memakai stdio alih-alih Streamable HTTP?

Pakai stdio untuk tool developer lokal, akses filesystem, dan apa pun yang sebaiknya berjalan pribadi di satu mesin, karena ia tidak butuh jaringan, port, atau deployment terpisah. Pilih Streamable HTTP hanya ketika sebuah server benar-benar perlu dibagikan, dihosting, atau dijangkau banyak klien lewat jaringan.

Bisakah satu server MCP melayani banyak klien?

Dengan Streamable HTTP, bisa: satu layanan yang di-deploy bisa melayani banyak klien dan pengguna sekaligus, yang persis dibutuhkan integrasi terhosting. Dengan stdio, tiap klien menjalankan subprocess pribadinya sendiri, sehingga tidak ada berbagi lintas klien atau mesin.

Transport MCP: stdio vs Streamable HTTP

Q: Apakah server MCP remote merupakan risiko keamanan?

Server Streamable HTTP adalah layanan jaringan yang terpapar dan harus diamankan seperti layanan. Spesifikasi menyoroti risiko nyata, termasuk memvalidasi asal permintaan, menghindari penerusan token, dan memblokir akses ke alamat metadata internal. Jangan pernah merilis server MCP remote tanpa autentikasi dan validasi asal terpasang.

Q: Apakah saya harus menulis ulang server untuk mengganti transport?

Tidak. Transport bukanlah protokol, jadi mana pun yang Anda pilih, server memaparkan tools, resources, dan prompts yang sama dan klien membuat panggilan yang sama. Berpindah transport nanti sebagian besar mengubah konfigurasi dan deployment, bukan logika server, sehingga Anda bisa mengembangkan lokal lewat stdio dan menghosting kode yang sama lewat HTTP kemudian.

MCP mendefinisikan dua transport: stdio untuk server subprocess lokal dan Streamable HTTP untuk layanan remote. Berikut perbedaannya dan kapan memakai masing-masing.

Ringkasan Utama

Model Context Protocol mendukung dua transport standar. stdio menjalankan server sebagai subprocess lokal yang bicara lewat standard input dan output, ideal untuk tool lokal. Streamable HTTP menjalankan server sebagai layanan remote yang dijangkau lewat jaringan, cocok untuk deployment bersama dan terhosting. Pesan protokolnya identik; hanya pipa penyalurnya yang berbeda.

Ketika Anda menyambungkan server MCP ke klien seperti Claude Code, Anda memilih bagaimana kedua proses itu bicara. Pilihan itu adalah transport, dan protokol mendefinisikan dua: stdio dan Streamable HTTP. Pesan yang mereka bawa adalah panggilan prosedur jarak jauh yang sama, sehingga keputusannya sebenarnya soal di mana server Anda berjalan dan siapa yang perlu menjangkaunya.

Menetapkan transport dengan benar sejak awal menghemat kesulitan kemudian, karena ia membentuk deployment, autentikasi, dan berapa banyak klien yang bisa dilayani satu server. Perbandingan ini menjelaskan apa yang dilakukan tiap transport, menunjukkan konfigurasi klien untuk keduanya, dan memberi patokan untuk memilih di antaranya.

Dimensi	stdio	Streamable HTTP
Di mana server berjalan	Subprocess lokal di mesin yang sama	Layanan remote lewat jaringan
Saluran komunikasi	Aliran standard input dan output	Permintaan HTTP, dengan respons yang mengalir
Penyiapan	Arahkan klien ke sebuah perintah untuk dijalankan	Arahkan klien ke sebuah endpoint URL
Autentikasi	Mewarisi pengguna lokal, tanpa auth jaringan	Butuh auth jaringan yang benar, seperti token
Banyak klien	Satu subprocess per klien	Satu server bisa melayani banyak klien

stdio: subprocess lokal

Dengan transport stdio, klien menjalankan server Anda sebagai proses anak dan bertukar pesan lewat standard input dan output-nya. Tidak ada jaringan, tidak ada port, dan tidak ada listener; pipanya adalah koneksi sistem operasi antara dua proses di mesin yang sama. Itu menjadikannya cara paling sederhana menjalankan server untuk tool dan berkas lokal.

Mengonfigurasinya berarti memberi tahu klien perintah apa yang harus dijalankan. Sebuah server lokal yang didaftarkan lewat perintah tampak seperti ini:

{
  "mcpServers": {
    "local-fs": {
      "command": "node",
      "args": ["./dist/server.js"]
    }
  }
}

Menyalakannya sepele karena tidak ada server untuk di-deploy atau dijaga tetap hidup; klien menjalankannya sesuai kebutuhan.
Keamanan bersandar pada pengguna lokal, karena proses berjalan dengan izin yang sama dan tidak ada jaringan yang terpapar.
Ia tidak berbagi lintas mesin, sehingga tiap klien mendapat subprocess pribadinya sendiri.

Streamable HTTP: layanan remote

Transport Streamable HTTP menjalankan server Anda sebagai layanan mandiri yang dijangkau klien lewat HTTP, dengan respons yang bisa mengalir kembali secara bertahap. Anda mengarahkan klien ke sebuah URL alih-alih sebuah perintah:

{
  "mcpServers": {
    "remote-api": {
      "type": "http",
      "url": "https://mcp.example.com/mcp"
    }
  }
}

Karena ia layanan jaringan sungguhan, satu deployment bisa melayani banyak klien dan banyak pengguna sekaligus, yang persis Anda inginkan untuk integrasi terhosting. Ia juga mewarisi setiap kekhawatiran memaparkan layanan di jaringan, sehingga autentikasi dan pemeriksaan asal berpindah dari opsional menjadi wajib.

Mulailah lokal dengan stdio saat Anda membangun dan menguji, lalu pindah ke Streamable HTTP hanya ketika sebuah server benar-benar perlu dibagikan atau dihosting. Mengembangkan terhadap subprocess mengeluarkan jaringan dan auth dari lingkaran, sehingga Anda men-debug protokol dulu dan deployment belakangan.

Memilih transport

Keputusannya mengikuti di mana server perlu hidup dan siapa yang harus menjangkaunya:

Pilih stdio untuk tool developer lokal, akses filesystem, dan apa pun yang sebaiknya berjalan pribadi di satu mesin.
Pilih Streamable HTTP untuk layanan bersama, server terhosting, dan integrasi yang dipanggil banyak pengguna atau klien.
Saat ragu, utamakan transport lokal yang lebih sederhana sampai kebutuhan konkret akan akses remote memaksa perubahan.

Server MCP remote adalah layanan yang terpapar dan harus diamankan seperti layanan. Spesifikasi menyebut risiko nyata, termasuk memvalidasi asal permintaan, menghindari penerusan token, dan memblokir akses ke alamat metadata internal. Jangan pernah merilis server Streamable HTTP tanpa autentikasi dan validasi asal terpasang.

Protokol sama, saluran berbeda

Membantu untuk mengingat bahwa transport bukanlah protokol. Mana pun yang Anda pilih, server memaparkan tools, resources, dan prompts yang sama, dan klien membuat panggilan yang sama. Berpindah transport nanti sebagian besar mengubah konfigurasi dan deployment, bukan logika server yang Anda tulis.

Pemisahan itu disengaja. Ia membuat Anda bisa mengembangkan server secara lokal lewat stdio lalu menghosting implementasi yang identik lewat HTTP untuk audiens lebih luas, tanpa menulis ulang cara kerja tool. Pilih transport untuk kebutuhan hari ini dan ketahui pintu ke yang lain tetap terbuka.

stdio dan Streamable HTTP adalah dua pipa untuk pesan MCP yang sama: satu lokal dan sederhana, satu remote dan bisa dibagikan. Mulai lokal, naik ke HTTP saat berbagi menuntutnya, amankan apa pun yang Anda paparkan, dan biarkan di mana server harus hidup yang menentukan pilihannya.

Sumber & bacaan lanjutan

Pertanyaan Umum

Transport MCP: stdio vs Streamable HTTP

Pertanyaan Umum

Transport MCP: stdio vs Streamable HTTP

stdio: subprocess lokal

Streamable HTTP: layanan remote

Memilih transport

Protokol sama, saluran berbeda

stdio: subprocess lokal

Streamable HTTP: layanan remote

Memilih transport

Protokol sama, saluran berbeda