Designing MCP Gateway: Uber's MCP Management Platform

Bài tóm tắt Uber 2026 3. Quy mô lớn Độ khó: Trung bình

Uber · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

  • Tích hợp MCP (Model Context Protocol, giao thức để agent gọi tool) ban đầu ở Uber là ad-hoc: agent mạnh lên rõ khi đọc được ngữ cảnh nghiệp vụ trực tiếp, gọi service nội bộ và hành động thay người dùng. Khi hàng trăm team cùng làm, mỗi team tự tích hợp: công cụ phân mảnh, hạ tầng trùng lặp, tool khó tìm, khó vận hành, gắn chặt với một service hay một agent; thêm rủi ro bảo mật và ma sát cho developer.

Thay đổi chính

  • MCP Gateway, một service trung tâm giữa agent với backend và các MCP server native. Lúc viết: hơn 800 MCP server, hơn 5.000 tool.
  • Control plane (MCP Registry): danh mục server và tool, nguồn sự thật cho tìm kiếm, ownership, bật/tắt. AutoCrawler (workflow Cadence chạy theo lịch) quét IDL registry của Uber (service Protobuf/Thrift trên HTTP, gRPC, TChannel): với mỗi nhóm service:API, tạo hoặc cập nhật một MCP server ảo, parse IDL lấy tên method, schema request/response và comment, dùng LLM sinh mô tả tool dễ hiểu cho agent, dịch schema sang JSON-RPC 2.0 của MCP. Server native (dựng bằng framework MCPFx) phát heartbeat metric; AutoCrawler thấy heartbeat thì gọi listTools và tạo server proxy ảo.
  • Phát hiện không có nghĩa là phơi ra: mọi server và tool sinh ra ở trạng thái tắt; team sở hữu service phải xem, sửa mô tả, rồi bật. Mỗi thay đổi mô tả là một diff cấu hình cần chủ server duyệt, có rollback về bản trước.
  • Data plane (Proxy Gateway): đọc cấu hình từ control plane và làm mới trạng thái trong bộ nhớ theo chu kỳ, nên thay đổi có hiệu lực không cần restart; mỗi server ảo có endpoint /<service-name>/mcp. Với tool từ IDL: dịch JSON sang wire format, serialize Protobuf/Thrift, gọi hạ nguồn qua Muttley (sidecar service mesh, thừa hưởng định tuyến sẵn có), dịch kết quả về JSON. Server native thì proxy thẳng.
  • Bảo mật: phân quyền và che dữ liệu nhạy cảm (PII) ở mức từng tool cho mọi server; dùng hệ Access Control nội bộ để áp charter policy theo loại caller phát hiện được (người, service, agent), đặt ở mức server, có thể ghi đè theo tool. Với MCP bên thứ ba (Jira, Google): gateway chuyển token của người gọi xuống, kèm phân quyền, rate limit, che dữ liệu; một dịch vụ riêng đổi token nội bộ lấy token của bên thứ ba trước khi gọi ra.
  • Vấn đề ở quy mô lớn: phình ngữ cảnh và chi phí. MCP không có tìm kiếm xuyên server; nối sẵn hàng trăm server vào agent sẽ ăn hết context. Ba lời giải: Omni MCP, một server proxy duy nhất với bốn tool discover_server, discover_tools, get_tool_schema, invoke_tool để khám phá dần; Response Projection, kiểu GraphQL: thêm một trường vào schema request để LLM khai báo các đường dẫn trường cần, gateway cắt response chỉ giữ chúng; Code Mode qua CLI aifx (mcp list, mcp search, mcp call), agent nối lệnh và ghi output ra file rồi grep phần cần, không cần cài MCP server nào, nay là mặc định toàn công ty cho coding agent.

Vì sao

  • Theo Uber, API sẵn có là đường nhanh nhất để có tool cho agent; thay vì bắt team viết lại service cho thế giới agent, gateway gặp họ ở chỗ họ đang đứng, dịch giao thức trong suốt mà không đổi service hạ nguồn. Phần khó nhất khi dựng agent ở quy mô lớn không phải AI mà là mô liên kết: khám phá, bảo mật, độ tin cậy.

Bài học cho SWE

  • Sinh tool từ đặc tả sẵn có (IDL) thay vì bắt từng team viết server; nhưng bật lên phải do chủ service quyết.
  • Đặt phân quyền, che dữ liệu, quan sát ở một gateway chung, phân biệt caller là người, service hay agent.
  • Danh mục tool lớn phải được khám phá dần và cắt response; nạp sẵn tất cả là trả chi phí ngữ cảnh ở mỗi lượt.
  • Tách control plane (danh mục, duyệt, phiên bản) khỏi data plane (dịch, gọi) để đổi cấu hình không cần deploy.

Liên quan