ToolHive: nền tảng MCP bảo mật cho công cụ AI

ToolHive là gì?

ToolHive là nền tảng mã nguồn mở của Stacklok, chạy từng Model Context Protocol (MCP) server trong một container cô lập riêng, thay vì để nó chạy như tiến trình trần trên máy. ToolHive nằm giữa các AI client như Claude Desktop, Cursor hay VS Code và các MCP server mà chúng gọi tới, thực thi chính sách danh tính, truy cập theo từng request khi bạn cấu hình nguồn xác thực, đồng thời cho đội platform khả năng quan sát để biết điều gì đang chạy.

Bài toán quản lý công cụ AI

Phần lớn đội ngũ dùng MCP server theo kiểu mạnh ai nấy làm: một developer tìm được một server trên GitHub, chạy nó ở máy cá nhân với bất kỳ thông tin xác thực nào đang có sẵn, và không ai bên đội bảo mật biết server đó tồn tại. Đây chính là khoảng trống ToolHive nhắm tới — không có điểm kiểm soát nào bắt buộc kiểm tra danh tính trước khi server chạy, ghi lại những gì server đã đụng tới, hay chặn ai đó chạy một server với quyền hạn mở toang. Các đội platform trên Kubernetes gặp vấn đề ngược lại: họ đã vận hành mọi thứ qua CRD, OIDC và Prometheus, và muốn MCP server đi theo đúng khuôn mẫu đó thay vì trở thành một ngoại lệ riêng lẻ.

Ai nên dùng ToolHive?

ToolHive được xây cho ba nhóm mà README nêu trực tiếp: developer cá nhân muốn chạy MCP server mà không phải rải thông tin xác thực khắp máy mình, kỹ sư platform cần MCP chạy trên hạ tầng Kubernetes họ đã vận hành sẵn, và doanh nghiệp có quy định tuân thủ cấm gửi dữ liệu nhạy cảm qua nhà cung cấp MCP dạng SaaS nên cần tự lưu trữ registry và gateway. Nếu bạn chỉ đang thử nghiệm một MCP server trên máy cá nhân, ứng dụng desktop hoặc CLI là đủ, không cần đụng tới phần Kubernetes.

Kiến trúc lõi và các năng lực chính

• ✓Gateway — điểm kiểm soát chính sách tập trung xác thực và phân quyền, tích hợp với nhà cung cấp danh tính qua OIDC/OAuth để làm SSO, và lọc hoặc viết lại mô tả tool trước khi request tới được MCP server.
• ✓Registry Server — danh mục được tuyển chọn, lấy dữ liệu từ MCP registry chính thức, cho phép thêm server tùy chỉnh, và xác minh nguồn gốc bằng chữ ký số trước khi server được đưa ra cho người dùng.
• ✓Runtime — chạy MCP server ở máy cục bộ qua Docker hoặc Podman, hoặc trên cụm Kubernetes thông qua operator, và có thể proxy các MCP server từ xa để server cục bộ lẫn server được host đều đi qua cùng một đường kiểm soát truy cập.
• ✓Portal — ứng dụng desktop đa nền tảng (toolhive-studio) cùng giao diện cloud chạy trên trình duyệt (toolhive-cloud-ui), giúp admin tuyển chọn server còn người dùng cuối chỉ cần cài đặt bằng một cú click.
• ✓Kubernetes Operator với Custom Resource Definitions cho MCP server và registry, cô lập theo nhiều namespace, và tự động tạo service kèm tích hợp ingress.
• ✓Cô lập bằng container theo mặc định — mỗi MCP server chạy trong container riêng với một tệp phân quyền tối thiểu, thay vì một tiến trình cục bộ nắm giữ thông tin xác thực của bạn.
• ✓OpenTelemetry trace và số liệu Prometheus được gắn sẵn vào Runtime và Operator, cộng thêm log kiểm toán, cho những đội cần chứng minh MCP server đã làm gì.
• ✓Semantic tool search cùng MCP Optimizer mà README cho biết giúp giảm mức dùng token tới 85% bằng cách lọc bớt tool và mô tả tool trước khi chúng tới được model.

Bắt đầu với ToolHive

README không đưa sẵn một lệnh cài đặt duy nhất — nó dẫn tới ba hướng dẫn quickstart riêng biệt trên docs.stacklok.com: một cho ứng dụng desktop, một cho CLI, và một cho Kubernetes Operator, cộng thêm tài liệu tham chiếu lệnh cho công cụ CLI `thv`. Ngoài các đường dẫn đó, các bước cài đặt cụ thể (tên gói, phiên bản Docker/Podman tối thiểu, v.v.) không được nêu rõ trong những gì có ở đây, nên cứ xem đây là 'vào đúng quickstart theo cách bạn muốn triển khai' chứ không phải một luồng cài đặt duy nhất.

Các hình thức triển khai và quy trình sử dụng

Theo README, việc triển khai chia làm ba hướng. Desktop: cài UI hoặc CLI trên máy cá nhân, chạy MCP server từ container image hoặc tự dựng một image từ trình quản lý gói phổ biến, rồi kiểm thử bằng MCP Inspector có sẵn. Kubernetes Operator: cài CRD cho MCP server và registry, operator sẽ lo việc cô lập namespace, tạo service và ingress — các đội có OIDC/OAuth SSO, log kiểm toán, OpenTelemetry và số liệu Prometheus theo đúng cách họ vẫn cấu hình cho các workload khác trong cụm. Hybrid: cách triển khai README đề xuất cho tổ chức lớn hơn, người dùng cuối truy cập server đã duyệt qua giao diện cloud, còn developer vẫn kết nối trực tiếp qua CLI hoặc desktop để kiểm thử, và mọi server — cục bộ, trong cụm, hay được host bên ngoài — đều đi qua cùng một Gateway và cùng bộ kiểm soát truy cập.

ToolHive so với các giải pháp khác

Câu hỏi thường gặp

Các trường hợp dùng tốt nhất

• •Một đội platform muốn chuẩn hóa cách mọi đội dịch vụ chạy MCP server trên cụm Kubernetes sẵn có của công ty, dùng CRD của Operator thay vì tạo Deployment thủ công từng lần.
• •Một đội bảo mật cần nhật ký kiểm toán cho biết MCP server nào đã chạy, ai truy cập, và những tool nào đã được gọi, mà không phải bắt developer đổi cách họ dùng Claude Code hay Cursor.
• •Một doanh nghiệp không được phép đưa dữ liệu nội bộ qua nhà cung cấp MCP dạng SaaS, nên tự lưu trữ registry và gateway thay vào đó, đúng với tình huống tuân thủ mà README mô tả.
• •Một developer chạy nhiều MCP server cục bộ, muốn mỗi server nằm trong một container riêng với tệp phân quyền tối thiểu, thay vì tin tưởng một script được toàn quyền truy cập hệ thống tệp.

Repo liên quan