Allows administrators to onboard a Notion MCP server into the gateway and expose its tools (e.g. read-only document, page, and database access) to developers through a governed bundle with function-level allow lists.
Allows administrators to onboard a Render MCP server, exposing its deployment and infrastructure tools to permitted users under centrally managed credentials and allow lists.
Allows administrators to onboard a Supabase MCP server so its database and project tools can be permissioned and executed by agents through the unified search/execute endpoint.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Gate22 search for tools to read Notion pages"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This repo is forGate22. If you're looking for the Tool-calling Platform, see ACI.
Govern which tools agents can use, what they can do, and how it’s audited—across agentic IDEs like Cursor, or other agents and AI tools.
Gate22 is built for engineering organizations and teams (Platform/Infra/DevEx, Security, Data/Analytics Eng). Admins onboard any remote MCP server (internal or external), set credential modes (org-shared or per-user), and define function-level allow lists per configuration. Developers then compose their own bundles from MCP configurations they’re permitted to use and expose them through a single unified MCP endpoint with just two functions — search and execute. Even if a bundle spans 20 MCPs/400+ tools, the unified endpoint discovers tools at call time, keeping IDE context lean while enforcing permissions.
To run the full Gate22 platform (backend server and frontend portal) locally, follow the individual README files for each component:
Backend: backend/README.md
Frontend: frontend/README.md
Related MCP server: Enterprise MCP Gateway and Tool Registry
Platform / Infra / DevEx teams rolling out agentic IDEs or internal AI agents at org scale.
Security / GRC that need least-privilege execution and auditability for agent tool-use.
Data & Analytics Engineering that want governed access to internal tools/BI with minimal setup.
Not a great fit (yet): single-user hobby setups; research sandboxes that don’t need governance.
Function allow-list permissioning (per MCP configuration).
Admin-set credential modes: org-shared or per-user (admins may publish both variants through separate MCP configurations of the same MCP server).
User-created bundles (private for now) → one endpoint (remote MCP URL) per bundle and only accessible to the bundle creator.
MCP tool list refresh & diff view (see what changed for an MCP server before you use it).
MCP bundles condense any number of MCPs and tools into just a single MCP endpoint and two functions--search and execute--to save context window.
Maximize your ROI from AI tools through safe integrations with any MCP and have visibility and audit.
Simple, least-privileged setup: admins set MCP permissions; developers only see/execute what they’re allowed.
No context bloat: two function surface (search/execute) dynamically resolves tools at runtime.
Separation of duties: admins control configs/credentials; developers assemble bundles from permitted building blocks.
Extend AI tools: have ease of mind to let AI tools interact with the rest of your stack.
An admin connects Notion, Supabase, and Render MCPs as read-only for everyone, and adds internal MCPs with write actions limited to specific projects. Developers create their own bundles (from what they’re entitled to), link one endpoint in their IDE, and safely execute only allowed functions—every call audited.
Cloud Version: gate22.aci.dev
Documentation: aci.dev/docs
Blog: aci.dev/blog
Tool-call logs: per-call records (who/what/when/result/latency) with export.
Policy enforcement (P0): thin, policy-as-code starter (env/time-box/allow-list), fail-closed for risky ops.
MCP tool-change audit: persist diffs when servers refresh; searchable history.
Bundle sharing: opt-in sharing within team/workspace (role-scoped visibility).
Security hardening: pre-flight checks for tool poisoning / prompt-injection patterns on MCP servers/configs.
Policy-as-code v2 (OPA/Cedar-style ABAC, approvals integration).
Quotas & budgets (per user/team/app/function).
Compliance (SIEM export, immutable audit logs).
Templates (“golden bundles”) for common stacks (Data/BI, SDLC, On-call).
We welcome contributions! Please see our CONTRIBUTING.md for more information.
This server cannot be deployed
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Governed app access for AI agents: 1,000+ apps & 12,000+ tools via Code Mode MCP.
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
