परिचय
Uber में AI agents को तेज़ी से अपनाने ने यह पूरी तरह बदल दिया है कि टीमें code, data और operational systems के साथ कैसे काम करती हैं। MCP (Model Context Protocol) के शुरुआती ad-hoc integrations ने अपना साफ़ फ़ायदा दिखाया: जब agents लाइव बिज़नेस context तक पहुँच सके, internal services से query कर सके और यूज़र्स की तरफ़ से ज़रूरी actions ले सके, तो उनकी क्षमताएँ कई गुना बढ़ गईं। इन शुरुआती सफलताओं ने यह साबित किया कि Uber के अंदर agentic systems बनाने के लिए MCP एक बेहद ताक़तवर abstraction है।
लेकिन जैसे-जैसे इसे अपनाने की रफ़्तार बढ़ी, कुछ बड़ी चुनौतियाँ भी सामने आईं। अलग-अलग टीमों ने अपनी-अपनी integrations बनाईं, जिससे tooling में बिखराव आया और infrastructure दोहराया जाने लगा। MCP tools को ढूँढना मुश्किल था, उन्हें भरोसेमंद तरीक़े से चलाना कठिन था, और वे किसी ख़ास service या agent implementation से बहुत ज़्यादा जुड़े हुए थे। छोटे स्तर पर ये तरीक़े काम कर गए, लेकिन जब सैकड़ों टीमों ने agentic workflows आज़माने शुरू किए, तो ये Uber की ज़रूरतों पर खरे नहीं उतरे। एक unified architecture के बिना, MCP को scale करने से operational complexity, security risk और developer friction बढ़ता, जो आख़िरकार इसके असर को सीमित कर देता।
Uber के पैमाने पर MCP की पूरी ताक़त का इस्तेमाल करने के लिए हमें एक centralized, scalable solution चाहिए था, जो यह तय करे कि AI agents मौजूदा back-end systems से कैसे बात करें—और साथ ही टीमों को लचीलापन भी मिलता रहे। इस solution को protocol differences (HTTP, gRPC™, TChannel) को छुपाना था, security और observability के एक जैसे guarantees लागू करने थे, और पूरे कंपनी में MCP tools को बनाना, ढूँढना और दोबारा इस्तेमाल करना आसान बनाना था।
इसी ज़रूरत को पूरा करने के लिए हमने MCP Gateway बनाया। यह एक foundational microservice है जो Uber में सभी MCP interactions को पावर करता है, और AI agents, मौजूदा back-end services और native MCP servers के बीच orchestration और routing layer का काम करता है। MCP logic को एक single gateway में centralize करके, हम agent-to-service interactions के लिए एक consistent execution model देते हैं, और टीमों को core infrastructure बार-बार बनाने की ज़रूरत नहीं पड़ती। मौजूदा APIs को बिना किसी झंझट के MCP tools के रूप में expose किया जा सकता है, एक ही जगह से manage और operate किया जा सकता है, और कई agents एक समान तरीक़े से उनका इस्तेमाल कर सकते हैं। MCP Gateway ने Uber के अंदर AI agents बनाने का एक scalable, तेज़ और consistent रास्ता खोल दिया है, और आज यह 800 से ज़्यादा MCP servers और 5000 से ज़्यादा tools होस्ट कर रहा है।
चित्र 1: MCP Gateway (APIs as tools)।
इस ब्लॉग में, हम MCP Gateway के design को देखेंगे, जिसमें Proxy Layer (MCP को मौजूदा protocols में और वापस translate करना), Discovery Layer (MCP Registry और API crawling), और इसका control plane (authoring) शामिल हैं।
Gateway
MCP Gateway एक microservice-based architecture पर काम करता है, जहाँ gateway, AI-enabled systems और Uber की back-end services के बीच central integration point का काम करता है। इस platform में दो मुख्य components हैं: MCP Registry, जो control plane का काम करता है, और Proxy Gateway, जो data plane बनाता है।
MCP Registry में internal services द्वारा सपोर्ट किए गए सैकड़ों MCP servers और हज़ारों MCP tools का catalog होता है। इन tools में ऐसे no-code definitions शामिल हैं जो मौजूदा APIs को MCP tools के रूप में expose करते हैं, और ऐसे fully native implementations भी हैं जिन्हें ख़ास तौर पर MCP specification के हिसाब से बनाया गया है। यह registry पूरे ecosystem में discovery, ownership और enablement के लिए single source of truth का काम करता है।
Proxy Gateway runtime पर MCP requests execute करने के लिए ज़िम्मेदार है। यह MCP protocol calls को HTTP, gRPC, या TChannel requests में translate करता है, उन्हें सही back-end service तक पहुँचाता है, और responses को वापस MCP-compatible results में बदल देता है। इस translation layer की वजह से AI agents मौजूदा systems से एक consistent MCP interface के ज़रिए बात कर सकते हैं, बिना underlying services में कोई बदलाव किए।
Control Plane
Uber एक microservice architecture इस्तेमाल करता है और हज़ारों internal services चलाता है जो HTTP, gRPC और TChannel पर APIs expose करती हैं। ये APIs किसी AI system को बहुत काम का context देती हैं, लेकिन टीमों से manually MCP server लिखवाना धीमा और मुश्किल काम होता। इस समस्या को सुलझाने के लिए हमने AutoCrawler बनाया, जो लगातार Uber की IDL registry को scan करके APIs ढूँढता है, उन्हें translate करता है और registry में update करता रहता है। यह native MCP servers से भी query करता है और उन्हें registry में जोड़ता है।
AutoCrawler: Discovery Engine
Autocrawler एक Cadence-powered distributed workflow system है, जो Uber की IDL registry और internal service signals से जुड़ा हुआ है। एक तय schedule पर, एक cron job Cadence workflow को trigger करता है, जो नए जुड़े services, APIs और schema changes को scan करता है।
ढूँढी गई हर entity के लिए, AutoCrawler ये काम करता है:
- MCP server representations बनाना या update करना
- Tool definitions और schemas generate करना या fetch करना
- Tools को MCP Registry में disabled-by-default state में register करना
यह shared foundation MCP discovery को हज़ारों services तक scale करने में मदद करता है, और service teams को critical path से बाहर रखता है।
चित्र 2: Auto Crawler।
IDL-Backed Services के लिए Discovery
Protobuf या Thrift IDLs से define की गई traditional back-end services के लिए, AutoCrawler सीधे IDL Registry से MCP servers और tools निकालता है। हर service: API group के लिए, AutoCrawler ये steps follow करता है:
- Upsert MCP server: ढूँढी गई service के हिसाब से एक virtual MCP server बनाता या update करता है।
- Parse IDL definitions: Method names, request और response schemas, और documentation comments निकालने के लिए जुड़ी हुई protobuf या Thrift files को parse करता है।
- Generate tool descriptions: निकाले गए schemas और comments के आधार पर, एक LLM का इस्तेमाल करके agent-friendly, बेहतर MCP tool descriptions बनाता है।
- Schema translation: Protobuf या Thrift schemas को MCP-compatible JSON-RPC 2.0 schemas में translate करता है।
- Upsert MCP tools: बनाए गए MCP tools को MCP Registry में disabled-by-default state में register या update करता है।
Native Servers के लिए Discovery
IDL-backed services के अलावा, MCP Gateway native MCP servers को भी support करता है—ऐसी services जो सीधे MCP protocol implement करती हैं और agent-optimized tools expose करती हैं।
MCPFx वह framework है जिसका इस्तेमाल Uber native MCP servers बनाने के लिए करता है। हर native MCP server एक heartbeat metric emit करता है जो उसकी मौजूदगी और readiness बताता है। AutoCrawler लगातार इन heartbeat signals को monitor करता है ताकि नए native MCP servers अपने आप ढूँढे जा सकें। जब कोई native MCP server मिलता है, तो AutoCrawler एक अलग discovery path अपनाता है:
- यह native MCP server पर listTools call करता है ताकि उसके explicitly expose किए गए tools और उनके schemas मिल सकें।
- यह MCP Registry में एक virtual proxy MCP server बनाता है जिसमें सभी ढूँढे गए tools और उनके schemas होते हैं, और यह disabled-by-default state में होता है।
3P MCP Servers
MCP Gateway, Uber में सभी MCP interactions के लिए centralized orchestration layer का काम करता है, और Jira और Google जैसे third-party integrations को भी बिना किसी रुकावट के support करता है।
Third-party MCP servers को provision करने के लिए दो मुख्य components का साथ काम करना ज़रूरी है:
- MCP Gateway: Caller का user token downstream भेजता है, और साथ ही authorization, rate limiting, और sensitive data redaction जैसी ज़रूरी gateway capabilities लागू करता है।
- Third-Party MCP Service: Request को external MCP server पर भेजने से पहले, internal user token को matching third-party authentication token से exchange करता है।
Authoring और Enablement
भले ही हम service team को शामिल किए बिना MCP servers बना लें, लेकिन MCP server की ownership और control service team के पास ही होना चाहिए। MCP Gateway का एक core design principle यह है कि ढूँढ लेना मतलब expose करना नहीं है। हर MCP server और tool disabled state में शुरू होता है, और owning team को उसे explicitly review करके enable करना पड़ता है। Service owners generated tool definitions को enable करने से पहले review और refine कर सकते हैं।
Tool description में हर बदलाव एक config change diff trigger करता है, जिसे server owners को approve करना होता है। Owners config change को approve और deploy कर सकते हैं, और ज़रूरत पड़ने पर पिछले known version पर roll back भी कर सकते हैं।
चित्र 3: MCP Registry UI।
चित्र 4: MCP tool UI।
Data Plane
MCP Gateway data plane वह core runtime service है जो MCP requests execute करने के लिए ज़िम्मेदार है। यह लगातार control plane से server और tool configurations consume करता है और एक तय cadence पर अपनी in-memory state refresh करता है, जिससे tool updates या enablement changes जैसे configuration changes बिना service restart या redeploy किए real time में लागू हो जाते हैं।
इसी configuration के आधार पर, data plane dynamically virtual MCP servers materialise करता है। हर virtual server के लिए, Gateway एक single /<service-name>/mcp endpoint expose करता है जो AI agent execution का entry point होता है। आने वाली requests एक built-in proxy server के ज़रिए अपने matching server handlers तक पहुँचाई जाती हैं।
चित्र 5: MCP Gateway Data Plane।
Protocol Translation और Execution
MCP Gateway में protocol translation Proxy Gateway के अंदर server handlers संभालते हैं। हर server handler tool-aware और downstream-aware होता है, जिससे वह runtime पर MCP requests को सही तरीक़े से route और execute कर सकता है।
Security
MCP Gateway सभी servers के लिए tool-level granularity पर built-in authorization और redaction देता है। MCP Gateway, detected caller actors (humans, services, और agents) पर configured अलग-अलग charter policies लागू करने के लिए Uber के internal Access Control System का इस्तेमाल करता है। Charter policies server level पर बनाई जाती हैं, और ज़रूरत होने पर tool-level overrides का विकल्प भी होता है।
MCP Gateway tool responses से किसी भी PII या sensitive data को out-of-the-box redact भी करता है।
IDL-Backed Downstream Services
मौजूदा back-end services पर चलने वाले tools के लिए, server handler एक in-memory mapping रखता है जो downstream destination बताता है, जैसे HTTP endpoint config या gRPC/TChannel procedures।
जब कोई MCP request आती है, तो handler:
- आने वाले JSON payload को सही wire format में translate करता है।
- Request को Protobuf या Thrift bytes में serialize करता है।
- Request को downstream service तक forward करता है।
- Protobuf या Thrift byte responses को वापस MCP-compatible JSON में translate करता है और calling agent को लौटाता है।
असली downstream request Muttley के ज़रिए execute होती है, जो Uber का service mesh sidecar है और सभी back-end services के साथ चलता है। Request execution को Muttley को सौंपकर, MCP Gateway को automatically मौजूदा service-to-service routing capabilities का फ़ायदा मिल जाता है।
Native MCP Servers
Native MCP servers भी MCP registry में virtual servers के रूप में register होते हैं, जो original server के लिए proxy का काम करता है। Runtime पर, native MCP requests transparently downstream server तक proxy होती हैं, और responses वापस caller तक proxy होकर आते हैं।
Gateway के फ़ायदे
MCP-Gateway बनाकर, Uber ने agentic systems बनाने का एक scalable और unified तरीक़ा हासिल कर लिया है, जिसके सबसे बड़े फ़ायदे ये हैं:
- आसान discovery और installation
- मौजूदा APIs के लिए no-code approach
- Built-in observability और security
- Centralized ownership और governance
Gateway को आगे बढ़ाना
MCP Gateway को सैकड़ों servers और हज़ारों tools तक scale करने से वो समस्याएँ सामने आईं जो छोटे स्तर पर नहीं दिखतीं। Context Bloat और बहुत ज़्यादा Cost
Runtime Discovery
MCP में cross-server search का कोई native concept नहीं है। Agent को पहले से पता होना चाहिए कि किस server से बात करनी है, तभी वह पूछ सकता है कि कौन से tools available हैं। किसी agent को MCP server इस्तेमाल करने के लिए configure करने में server URL, credentials और tool list को explicitly जोड़ना पड़ता है। सैकड़ों servers के लिए ऐसा करना scale नहीं हो सकता, क्योंकि इतना सारा context model की context limit खा जाएगा। हमने इस समस्या को इस तरह सुलझाया:
- Omni MCP - एक single proxy server जो MCP clients को gradual discovery pattern के साथ MCP Gateway के किसी भी server तक पहुँचने देता है, और incremental discovery के ज़रिए context/token optimization का रास्ता भी खोलता है। Omni MCP ये tools expose करता है।
- discover_server - query intent के आधार पर MCP server ढूँढना
- discover_tools - किसी server के लिए tools lookup करना
- get_tool_schema - किसी tool का json schema पाना
- invoke_tool - किसी tool को invoke करना
मिलकर, ये tools built-in access control और बाकी gateway features के साथ सभी MCP servers की incremental discovery और access को मुमकिन बनाते हैं।
- Response Projection - MCP Gateway, Response Projection भी देता है, जो MCP tools के लिए GraphQL जैसा calling pattern है। यह tool request schema में एक नया field inject करके काम करता है, जो gateway को निर्देश देता है कि सभी fields नहीं, सिर्फ़ ज़रूरी fields माँगी जाएँ। LLM उन fields को पढ़ता है और सिर्फ़ ज़रूरी fields के nested paths की एक array inject करता है। फिर Gateway runtime पर projected fields को ही रखकर response को trim कर देता है। इसने हमें enterprise level पर MCP के लिए API schema compatibility scale करने में मदद की है।
- Code Mode - Coding agents अक्सर shell environments में काम करते हैं, जहाँ tool output को सीधे files में लिखना, पूरे responses को model context में load करने से ज़्यादा efficient होता है। Code Mode aifx (agentic operations के लिए Uber का CLI) के ज़रिए इस pattern को support करता है, और बिना किसी MCP server install किए MCP calls को gateway से route करता है। यह agents को बिना context में MCP definition रखे, काम के लिए सही MCP tools ढूँढने में मदद करता है। aifx तीन commands expose करता है:
- aifx mcp list - available MCP servers की list दिखाना
- aifx mcp search - सभी MCP servers में tools search करना
- aifx mcp call - MCP Gateway के ज़रिए किसी MCP tool को invoke करना
Agents इन्हें एक single command में chain कर सकते हैं और output को files में लिख सकते हैं, जिन्हें filesystem agents selectively grep करते हैं और context में सिर्फ़ वही load करते हैं जिसकी उन्हें ज़रूरत है। Coding agents में MCP tool use के लिए Code Mode अब कंपनी का default बन चुका है।
निष्कर्ष
MCP Gateway बनाने ने Uber में AI agents के काम करने का तरीक़ा पूरी तरह बदल दिया है। जो शुरुआत में एक बिखराव की समस्या थी—जहाँ दर्जनों टीमें inconsistent tooling, बिना shared security guarantees और duplicated infrastructure के साथ अपनी-अपनी MCP integrations जोड़ रही थीं—वह अब एक unified, scalable platform बन चुका है जिससे कोई भी टीम मिनटों में जुड़ सकती है।
हमारे design को आगे बढ़ाने वाली core insight बहुत simple थी: किसी agent को tools देने का सबसे तेज़ रास्ता मौजूदा APIs ही हैं। टीमों से agentic world के लिए अपनी services दोबारा लिखवाने के बजाय, MCP Gateway उन्हें वहीं मिलता है जहाँ वे हैं—HTTP, gRPC और TChannel calls को Muttley के ज़रिए transparently MCP-compatible interactions में translate करता है, बिना downstream services में कोई बदलाव किए।
अगर आप बड़े पैमाने पर agentic systems बना रहे हैं, तो सबसे मुश्किल हिस्सा AI नहीं है। सबसे मुश्किल है वह connective tissue बनाना—discovery, security, reliability—जो agents को इतना भरोसेमंद बनाता है कि वे production environment में real users की तरफ़ से action ले सकें। MCP Gateway इसी चुनौती का हमारा जवाब है, और हमें उम्मीद है कि यहाँ बताए गए design decisions उन लोगों के काम आएँगे जो इसी समस्या से जूझ रहे हैं।
आभार
कवर फ़ोटो क्रेडिट: OpenAI के ChatGPT से generate किया गया; किसी बाहरी image, logo या third-party asset का इस्तेमाल नहीं किया गया।
gRPC, The Linux Foundation का trademark है।
Uber Engineering की ताज़ा ख़बरों से जुड़े रहें—हमारे नए ब्लॉग पोस्ट और insights के लिए LinkedIn पर हमें follow करें।
