Menelaah MCP Secara Kritis

• MCP adalah protokol berbasis JSON-RPC yang bertujuan membuat LLM/Agent menangani alat eksternal dan sumber data dengan cara standar, tetapi dikritik karena desain transport HTTP dan kualitas dokumentasinya meningkatkan beban implementasi
• Isu terbesarnya adalah bahwa saat mengimplementasikan komunikasi dua arah sederhana di HTTP, MCP merekonstruksi secara tidak langsung perilaku yang mirip WebSocket melalui HTTP+SSE dan Streamable HTTP
• Streamable HTTP membagi jalur pembuatan sesi, koneksi SSE, dan pengiriman respons menjadi beberapa cabang, sehingga menambah beban manajemen state, debugging, interoperabilitas, skalabilitas, dan keamanan
• Transport HTTP disertai persyaratan otorisasi yang berpusat pada OAuth2, tetapi stdio dirancang untuk mengambil kredensial dari variabel lingkungan, sehingga model autentikasi berbeda untuk tiap metode transport
• Transport HTTP sebaiknya disederhanakan menjadi WebSocket, yang paling dekat dengan stream input/output pada stdio, dan desainnya perlu dioptimalkan untuk kasus penggunaan umum daripada kasus pengecualian

---

MCP yang menyebar cepat

• MCP(Model Context Protocol) adalah protokol terbuka yang menstandarkan cara aplikasi menyediakan konteks kepada LLM
• Anthropic mengibaratkan MCP sebagai port USB-C untuk aplikasi AI, dan menjelaskannya sebagai cara standar untuk menghubungkan model AI ke berbagai sumber data dan alat
• Dalam sebulan terakhir MCP menyebar dengan cepat, dan MCP Server serta Client dibuat setiap hari; ini dapat dilihat di situs seperti mcp.so dan pulsemcp.com
• IBM merilis Agent Communication Protocol(ACP) sebagai “standar yang ortogonal” terhadap MCP, dan Google juga mengumumkan Agent2Agent(A2A)
• Kritik utamanya tetap bahwa meski perusahaan besar menghabiskan biaya sangat besar untuk pelatihan dan tuning model, kematangan dokumentasi, SDK, dan panduan implementasinya masih rendah

Protokol itu sendiri dan lapisan transport

• MCP adalah protokol JSON-RPC dengan metode dan endpoint yang telah didefinisikan sebelumnya untuk digunakan bersama LLM
• Metode transport utamanya terbagi menjadi stdio, yang dekat dengan eksekusi lokal, dan transport berbasis HTTP

  • stdio

    • Menjalankan MCP Server lokal, menghubungkan pipe stdout dan stdin dengan Client untuk bertukar JSON, serta menggunakan stderr untuk logging
    • Penggunaan paradigma pipe Unix/Linux untuk komunikasi dua arah memang bisa dikritik, tetapi mudah dipahami karena berjalan dengan mudah di semua sistem operasi dan tidak membutuhkan penanganan socket

  • Transport berbasis HTTP

    • Metode yang berjalan di atas HTTP, mencakup HTTP+SSE dan Streamable HTTP yang dimaksudkan untuk menggantikannya
    • Keduanya mencoba mengimplementasikan pertukaran pesan dua arah sederhana dengan kombinasi request HTTP dan koneksi SSE, sehingga kompleksitasnya meningkat

Kritik terhadap HTTP+SSE dan Streamable HTTP

• Transport HTTP yang ada adalah metode HTTP+SSE(Server-Sent Events), dan spesifikasi baru mencoba menggantinya dengan Streamable HTTP
• Untuk membuat full duplex, HTTP+SSE membuat Client membuka sesi SSE untuk membaca lewat request seperti GET /sse, menerima URL untuk menulis pada respons pertama, lalu mengirim request seperti POST /a-endpoint?session-id=1234
  • Server mengembalikan 202 Accepted dengan body kosong
  • Respons sebenarnya harus dibaca dari koneksi /sse yang sudah terbuka
• Streamable HTTP menangani session ID lewat header HTTP, bukan endpoint terpisah, dan dapat membuka sesi SSE dengan GET atau POST /mcp
  • Respons dapat datang sebagai stream SSE baru
  • Respons dapat datang sebagai body respons POST dengan 200
  • Respons dapat dikirim belakangan melalui salah satu stream SSE yang sudah ada
• Desain ini dekat dengan struktur yang mencoba berperilaku seperti WebSocket di atas SSE, dan alasan untuk tidak memakai WebSocket sungguhan dibahas di modelcontextprotocol/pull/206
• Transport HTTP mencoba meniru stdio, tetapi karena bukan socket sungguhan, implementasi server harus menanggung beban untuk menggabungkan(join) berbagai pemanggilan dan koneksi HTTP

Masalah dokumentasi dan SDK yang terlihat dari pengalaman implementasi

• Dalam upaya mengimplementasikan MCP Server dengan Go, tidak ada SDK Go resmi, dan untuk memahami protokol pada dasarnya diperlukan rekayasa balik
• Dokumentasi di modelcontextprotocol.io melewatkan atau menghilangkan detail protokol penting, dan tidak menyediakan contoh alur percakapan
• Situs webnya cenderung mengarahkan pembaca ke tutorial implementasi SDK daripada membaca standar itu sendiri
• Server contoh diimplementasikan dengan Python atau JavaScript, dan mengasumsikan eksekusi lokal melalui stdio
  • Python dan JavaScript dikritik sebagai pilihan yang kurang baik untuk alat lokal yang harus berjalan stabil di komputer orang lain
  • Fakta bahwa contohnya juga disediakan sebagai kontainer Docker tampaknya merupakan hasil dari pengakuan terhadap masalah ini sampai batas tertentu
• Untuk eksekusi MCP lokal, dinilai bahwa bahasa yang lebih portabel seperti Rust, Go, Java, C#, atau pilihan berbasis VM lebih cocok

Kompleksitas yang dibuat Streamable HTTP

• Dalam Streamable HTTP, sesi baru dapat dibuat dengan tiga cara
  • Request GET kosong
  • Request POST kosong
  • Request POST yang berisi pemanggilan RPC
• SSE juga dapat dibuka melalui empat jalur
  • GET untuk inisialisasi
  • GET untuk bergabung ke sesi sebelumnya
  • POST untuk inisialisasi sesi
  • POST yang berisi request dan merespons melalui SSE
• Respons request kembali dapat dikirim dengan tiga cara
  • Respons HTTP dari POST yang berisi pemanggilan RPC
  • Event SSE yang dibuka sebagai respons terhadap POST tersebut
  • Event SSE mana pun yang sudah dibuka sebelumnya
• Semakin banyak jalur untuk mendapatkan hasil yang sama, semakin besar beban kognitif, tingkat kesulitan debugging, dan beban pemeliharaan
• Jika Client dan Server masing-masing hanya mengimplementasikan sebagian yang mereka anggap perlu, akan muncul masalah interoperabilitas dan dapat berujung pada perilaku tak terduga
• Dalam konfigurasi server yang tersebar di banyak mesin, pengelolaan status koneksi dan mekanisme respons dapat menjadi bottleneck skalabilitas

Masalah keamanan dan otorisasi

• Fleksibilitas Streamable HTTP menimbulkan beberapa kekhawatiran keamanan
  • Manajemen state sesi yang melintasi HTTP dan SSE itu kompleks, dan dapat membuka kemungkinan pembajakan sesi, serangan replay, serta DoS
  • Titik masuk untuk pembuatan sesi dan koneksi SSE bertambah banyak, sehingga permukaan serangan melebar
  • Beragam cara memulai sesi dan mengirim respons dapat dipakai untuk menyembunyikan aktivitas berbahaya
• Spesifikasi authorization pada protokol terbaru merekomendasikan agar implementasi transport berbasis HTTP mengikuti spesifikasi tersebut
• Dalam spesifikasi yang sama, implementasi transport STDIO direkomendasikan untuk tidak mengikuti spesifikasi tersebut, melainkan mengambil kredensial dari lingkungan
• Dalam struktur ini muncul keluhan bahwa jika menggunakan transport HTTP, orang harus mengimplementasikan prosedur OAuth2, sementara pada stdio tampak memungkinkan pendekatan setingkat API key

Usulan: sederhanakan transport HTTP menjadi WebSocket

• MCP memiliki satu protokol JSON-RPC, dan stdio tampaknya menjadi metode transport yang jelas lebih disukai
• Transport HTTP harus dibuat semirip mungkin dengan stdio, dan hanya dibuat berbeda ketika benar-benar diperlukan
• Variabel lingkungan pada stdio dapat dipadankan dengan header HTTP pada HTTP
• Stream input/output yang mirip socket pada stdio dapat dipadankan dengan WebSocket pada HTTP
• Dengan WebSocket, manajemen state antarsserver yang rumit untuk sesi dan banyak corner case dapat dikurangi
• Namun otorisasi bisa menjadi lebih kompleks dalam beberapa kasus, sebagian firewall dapat memblokir WebSocket, sesi singkat dapat memiliki overhead, dan melanjutkan sesi yang terputus bisa lebih sulit
• Spesifikasi MCP sendiri juga menyatakan bahwa MCP adalah protokol transport-agnostic yang dapat diimplementasikan pada kanal komunikasi apa pun yang mendukung pertukaran pesan dua arah
• Industri perlu mengoptimalkan untuk kasus penggunaan yang paling umum, bukan untuk corner case

Evaluasi tambahan tentang ACP dan A2A

• MCP adalah protokol untuk mengekspos API kepada LLM, sedangkan ACP dan A2A lebih dekat ke protokol untuk mengekspos Agent kepada LLM
• Melihat spesifikasi A2A, kebutuhannya tampak terbatas, dan banyak fitur A2A tampaknya bisa ditangani apa adanya oleh MCP atau dengan sedikit tambahan
• ACP dan A2A juga dapat diimplementasikan sebagai alat pada MCP Server, bukan sebagai protokol terpisah
• IBM juga menyampaikan sudut pandang bahwa ACP Agent dapat dilihat sebagai resource MCP dan dipanggil sebagai alat MCP dalam dokumen MCP adapter
• ACP dinilai tampak memiliki sifat promosi untuk BeeAI, yaitu agent-building-tool dari IBM
• Keunggulan yang dibawa ACP dan A2A adalah lapisan transport yang lebih utuh dan cara menemukan Agent