Uber Bangun MCP Gateway untuk 800 Server dan 5.000 Tool Agen

Uber membangun MCP Gateway sebagai lapisan tunggal untuk lebih dari 800 server MCP dan 5.000 tool agen, sehingga agen internal tidak lagi menyambung langsung ke tiap layanan. Gateway itu memisahkan registry sebagai control plane dari proxy sebagai jalur eksekusi, dan menerjemahkan permintaan MCP menjadi panggilan HTTP, gRPC, atau TChannel tanpa mengubah layanan di belakangnya. Arsitektur lengkapnya dipublikasikan lewat InfoQ pada 2 November 2026, dengan rujukan ke tulisan tim engineering Uber.

TL;DR

• Uber mengelola lebih dari 800 server MCP dan 5.000 tool dari satu gateway, bukan dari konfigurasi per tim.
• Registry menyimpan definisi tool, skema, pemilik, dan status aktif; proxy mengeksekusi dan menormalkan respons.
• AutoCrawler memakai Cadence untuk memindai registry IDL, membuat skema MCP dari protobuf dan Thrift, lalu memakai model bahasa untuk menulis deskripsi tool.
• Tool hasil penemuan otomatis tetap nonaktif sampai tim pemiliknya meninjau dan menyalakan sendiri.
• Omni MCP dan Response Projection memangkas konteks: agen mencari tool yang relevan dan meminta field tertentu, bukan menerima seluruh payload.

Apa yang sebenarnya dibangun Uber dan kenapa?

Yang dibangun adalah satu lapisan bersama untuk penemuan, penerjemahan protokol, otorisasi, dan eksekusi tool. Sebelumnya, integrasi tersebar di banyak tim, infrastruktur digandakan, dan praktik keamanan tidak seragam. Semakin banyak agen dipakai, semakin mahal konsekuensi dari ketidaksamaan itu.

Model konseptualnya mirip API gateway yang sudah dikenal di dunia mikroservis, dengan satu perbedaan penting: konsumennya bukan aplikasi yang perilakunya ditentukan programmer, tapi model bahasa yang memilih sendiri tool mana yang dipanggil. Pilihan itu tidak selalu bisa diprediksi, sehingga batas kewenangan harus ditegakkan di lapisan yang tidak bisa dilewati model.

Spesifikasi Model Context Protocol sendiri terbuka dan bisa dibaca di dokumentasi resmi MCP. Yang Uber tambahkan adalah tata kelola di atas protokol itu: siapa boleh memanggil apa, dengan kredensial siapa, dan bagaimana hasilnya dibersihkan sebelum sampai ke model.

Bagaimana registry dan proxy bekerja?

Registry berperan sebagai control plane. Ia menyimpan definisi tool, skema, pemilik, dan setelan aktif atau tidak. Proxy berperan sebagai data plane: ia menerima permintaan MCP, menerjemahkannya menjadi panggilan HTTP, gRPC, atau TChannel ke layanan yang sudah ada, lalu mengubah respons kembali ke bentuk yang dipahami klien MCP.

Komponen	Peran	Yang dijaga
MCP Registry	Menyimpan definisi tool, skema, pemilik, status	Kebenaran katalog dan kepemilikan
Proxy Gateway	Menerjemahkan MCP ke HTTP, gRPC, TChannel	Kompatibilitas tanpa ubah layanan asal
AutoCrawler	Memindai IDL, membuat skema, menulis deskripsi	Kelengkapan katalog
Sistem akses internal	Otorisasi level server dan tool	Batas kewenangan agen
Penukar token	Menukar token pengguna internal ke penyedia pihak ketiga	Kredensial tidak berpindah tangan sembarangan

Perubahan konfigurasi di registry disebarkan ke data plane tanpa perlu restart atau redeploy layanan. Bagi organisasi besar, ini yang membuat tata kelola bisa berjalan: kalau menonaktifkan satu tool menuntut deploy ulang, tidak ada tim yang akan melakukannya dengan rapi.

Kenapa tool hasil penemuan otomatis harus dimatikan dulu?

Karena tool yang ada di katalog belum tentu layak dipanggil model. AutoCrawler memindai registry IDL internal, mengambil definisi API dari skema protobuf dan Thrift, lalu menghasilkan skema yang kompatibel dengan MCP. Deskripsi tool-nya ditulis memakai model bahasa, dan deskripsi karangan model bisa melebih-lebihkan kemampuan sebuah endpoint.

Karena itu tool baru tetap nonaktif sampai tim pemiliknya meninjau dan menyalakannya secara eksplisit. Ini keputusan desain yang layak ditiru: penemuan otomatis dipakai untuk mengurangi pekerjaan manual, bukan untuk memindahkan tanggung jawab. Tim yang memiliki endpoint tetap yang menanggung risiko kalau tool itu dipanggil dengan parameter keliru.

Untuk otomatisasi pemindaian, Uber memakai Cadence, sistem workflow yang tahan terhadap kegagalan proses di tengah jalan. Pemindaian ribuan definisi antarmuka adalah pekerjaan panjang dan berulang, dan pekerjaan semacam itu tidak cocok dijalankan sebagai satu skrip sekali jalan.

Bagaimana konteks agen dihemat saat tool mencapai ribuan?

Dengan tidak memuat semuanya. Memasukkan definisi 5.000 tool ke context window bukan hanya mahal, tapi juga menurunkan kualitas pemilihan: semakin banyak pilihan serupa, semakin besar peluang model memilih yang salah. Uber menjawabnya lewat Omni MCP, yang memungkinkan agen mencari server, menemukan tool yang relevan, mengambil skema satu tool, lalu memanggilnya.

Ada juga Response Projection, yang membuat agen meminta field tertentu saja alih-alih menerima payload penuh. Untuk endpoint internal yang mengembalikan objek besar, ini memangkas token secara langsung, dan pada saat yang sama mengurangi peluang data sensitif ikut terbawa ke model.

Selain itu ada antarmuka baris perintah aifx yang dipakai agen koding untuk menemukan dan memanggil tool, lalu menuliskan hasilnya ke berkas agar bisa diperiksa sebagian. Pola ini menarik karena membalik kebiasaan: hasil besar tidak dimasukkan ke konteks, tapi disimpan, dan agen hanya membaca bagian yang perlu.

Apa yang dijaga di sisi keamanan?

Otorisasi ditegakkan di dua tingkat: server dan tool. Artinya agen yang boleh memakai satu server belum tentu boleh memanggil semua tool di dalamnya. Untuk katalog sebesar 5.000 tool, pembedaan ini bukan detail administratif, karena satu tool bisa membuka akses tulis sementara tool lain hanya membaca.

Gateway juga mendukung penyuntingan informasi pribadi dan data sensitif lain pada respons tool. Ini penting karena agen sering tidak butuh nama lengkap, alamat surel, atau nomor identitas untuk menyelesaikan tugasnya. Menghapus di lapisan gateway lebih aman daripada mengandalkan setiap tool menuliskannya dengan benar.

Untuk integrasi pihak ketiga seperti Jira dan Google, ada layanan terpisah yang menukar token pengguna internal dengan token autentikasi pihak ketiga. Dengan begitu, kredensial eksternal tidak perlu disimpan di setiap agen, dan pencabutan akses cukup dilakukan di satu tempat.

Apakah model gateway seperti ini cocok untuk tim kecil?

Belum tentu. Biaya membangun registry, crawler, dan jalur otorisasi hanya terbayar kalau jumlah tool dan jumlah tim sudah banyak. Tim dengan lima tool dan satu pemilik bisa menyelesaikannya dengan konfigurasi biasa tanpa kehilangan apa pun.

Yang tetap relevan untuk tim kecil adalah tiga prinsipnya. Pertama, satu tempat untuk mendaftar tool beserta pemiliknya, karena katalog yang tersebar selalu berakhir dengan tool tak bertuan. Kedua, otorisasi di lapisan yang tidak bisa dilewati agen, bukan di prompt. Ketiga, tool baru berstatus nonaktif sampai ada yang meninjau, karena penemuan otomatis tanpa persetujuan manusia adalah cara tercepat memasukkan endpoint yang salah ke jalur produksi.

Prinsip keempat menyangkut konteks: sediakan cara meminta sebagian data. Selama ini banyak integrasi dirancang dengan asumsi konsumennya program yang tidak peduli ukuran payload. Model bahasa peduli, dan biayanya dibayar per token.

Bagaimana posisi arsitektur ini dibanding API gateway biasa?

Secara pola mirip, dan beberapa praktisi menyebutnya begitu. Perbedaan pokoknya ada pada ketidakpastian konsumen. API gateway konvensional melayani klien yang memanggil endpoint tertentu karena kodenya memang begitu ditulis. MCP gateway melayani agen yang memilih endpoint berdasarkan deskripsi, sehingga kualitas deskripsi, kelengkapan skema, dan pembatasan konteks menjadi bagian dari keamanan, bukan sekadar kenyamanan.

Karena itu, masalah yang muncul juga berbeda. Pada API gateway, kesalahan umum adalah endpoint yang terlalu terbuka. Pada gateway tool agen, kesalahan umum adalah tool yang deskripsinya menyesatkan, atau daftar tool yang terlalu panjang sampai model memilih yang salah. Keduanya tidak bisa ditutup dengan menambah aturan jaringan.

Kapan gateway MCP sebaiknya tidak dipakai?

Kalau semua agen berjalan di dalam satu tim dan menyentuh layanan yang sama, gateway hanya menambah satu titik yang harus dioperasikan. Diagnostik jadi lebih rumit: kegagalan panggilan bisa berasal dari agen, dari gateway, atau dari layanan tujuan, dan tim kecil biasanya belum punya observabilitas untuk memisahkan ketiganya dengan cepat.

Kondisi lain adalah ketika belum ada kebutuhan otorisasi yang berbeda antar pengguna. Gateway paling bernilai saat ia menegakkan batas yang tidak bisa ditegakkan di tempat lain. Kalau semua pemanggil punya hak yang sama, lapisan itu belum memberi banyak selain penerjemahan protokol.

Yang juga perlu dipertimbangkan adalah biaya pemeliharaan katalog. Registry berisi 800 server bukan pekerjaan sekali jadi; ia menuntut pemilik untuk tiap tool, mekanisme penonaktifan, dan peninjauan berkala terhadap tool yang sudah usang. Organisasi yang tidak siap merawat katalog akan berakhir dengan daftar besar yang isinya tidak lagi dipercaya.

Apa yang sebaiknya diukur dari gateway semacam ini?

Metrik pertama bukan jumlah tool, tapi jumlah tool yang benar-benar dipanggil dalam sebulan. Katalog yang membesar tanpa pemakaian hanya menambah beban konteks dan permukaan risiko. Tool tanpa pemanggilan selama beberapa bulan layak ditinjau, bukan dibiarkan menumpuk.

Metrik kedua adalah tingkat kegagalan panggilan yang disebabkan parameter salah. Angka itu menunjukkan kualitas deskripsi tool, bukan kualitas layanan di belakangnya. Kalau naik setelah katalog bertambah, penyebabnya hampir selalu penemuan otomatis yang menghasilkan deskripsi terlalu umum.

Metrik ketiga adalah ukuran konteks yang dipakai per tugas. Gateway yang berhasil membuat agen meminta skema satu tool dan sebagian field akan menurunkan angka ini, dan penurunan itu berdampak langsung ke biaya per tugas serta ke kualitas pemilihan tool.

FAQ

Berapa jumlah server dan tool yang dikelola gateway ini?

Lebih dari 800 server MCP dan lebih dari 5.000 tool. Angka itu disebut dalam laporan InfoQ dan tulisan tim engineering Uber sebagai cakupan gateway.

Apakah layanan di belakang harus diubah jadi server MCP?

Tidak. Gateway menerjemahkan permintaan MCP menjadi panggilan HTTP, gRPC, atau TChannel ke API yang sudah ada, sehingga layanan tidak perlu ditulis ulang.

Apa fungsi model bahasa di AutoCrawler?

Model dipakai untuk menulis deskripsi tool dari definisi API yang ditemukan. Karena deskripsi itu memengaruhi cara agen memilih tool, hasilnya tetap harus ditinjau pemilik sebelum diaktifkan.

Bagaimana data sensitif dicegah masuk ke model?

Gateway menyunting informasi pribadi dan data sensitif pada respons tool. Selain itu Response Projection membuat agen hanya meminta field yang dibutuhkan, sehingga payload penuh tidak perlu dikirim.

Apakah tool baru langsung bisa dipakai begitu ditemukan?

Tidak. Tool hasil penemuan otomatis berstatus nonaktif sampai tim pemiliknya meninjau dan menyalakannya. Perubahan konfigurasi berlaku tanpa restart layanan.