Backend
Transport MCP: stdio vs Streamable HTTP
Agustus 20268 menit baca
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.
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.
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.
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.
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.
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 |
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"]
}
}
}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.
Keputusannya mengikuti di mana server perlu hidup dan siapa yang harus menjangkaunya:
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.
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.