AgentKit: The MCP Gateway That Lets AI Agents Securely Call 30,000 Tools

When AI agents move from demos to production, developers face an awkward reality: getting an agent to call external tools isn't hard—what's hard is making it complete every operation within the right permission boundaries, under the right identity, securely and controllably. AgentKit, released by the Scalekit team on Product Hunt, attempts to solve this layer of complexity with an MCP gateway—and it took the #1 product spot of the day, with 166 upvotes and 40 comments.

One gateway, connecting 600+ apps and 30,000+ tools

AgentKit's core positioning is "the MCP gateway that acts on your behalf." According to the official description, developers can use this single gateway to let agents tap capabilities spanning more than 600 applications and over 30,000 tools, covering common enterprise software from Salesforce to GitHub.

Behind that number is the reality of a rapidly expanding MCP (Model Context Protocol) ecosystem. The protocol standardizes how agents connect to tools, but for every app you integrate, developers still have to handle authentication, integration, permission boundaries, and other tedious work. AgentKit consolidates this at the gateway layer: authentication and integration are handled by the platform, and agents only need to make calls against a unified interface.

For teams pushing agents into production, the value of this "middle layer" isn't saving a few lines of code—it's pulling the security boundary out of each agent's internal logic and turning it into centrally managed infrastructure.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic in late 2024, aimed at standardizing how large language models connect to external tools and data sources. Before MCP, every AI application needed custom development to integrate different tools, resulting in a great deal of duplicated integration work. MCP defines the communication specification between clients (AI applications) and servers (tool providers), including tool discovery, invocation requests, and result returns. The introduction of this protocol drove rapid expansion of the tool ecosystem and made "integrate once, reuse everywhere" possible. However, MCP itself only solves the problem of communication standardization—it doesn't address authentication, permission management, or multi-tenant isolation, all of which are essential for production environments. That's precisely the gap that gateway products like AgentKit are trying to fill.

Execute as the user, not with superuser privileges

The most noteworthy design choice in AgentKit is how it handles "execution identity." The official documentation emphasizes that every operation runs as the identity of the user who initiated the request, and is strictly limited to the scopes that user has granted.

That sentence sounds like a compliance clause, but it actually points to the most common pitfall when deploying agents: to save effort, developers often give an agent a high-privilege service account, and as a result the agent can do far more than any single user should be able to. Once an agent is tricked into performing an unauthorized operation, or a logic error occurs, the blast radius is multiplied.

AgentKit's approach pulls the permission model back into a "user delegation" framework—the agent is an extension of the user, not a system super-admin. Combined with the Virtual MCP Servers mechanism, each agent can also be restricted to only the subset of tools its responsibilities require. This combination of "least privilege" both reduces the risk of mistakes and makes the audit trail clearer: who initiated it, under whose identity, and what was called—all traceable.

The "scope" mechanism in OAuth 2.0 is key to understanding AgentKit's permission model. When a user authorizes an application to access their data, they can limit the scope of authorization—for example, allowing only calendar reads but not sending emails. AgentKit brings this mechanism into the agent context: when an agent calls a tool, it carries the access token of the user who initiated the request, and the scopes declared in that token directly constrain the boundaries of what the agent can do. Compared with the traditional service-account model, this "user delegation" approach means the agent cannot obtain capabilities beyond the user's own permissions; even if the agent is attacked with a malicious prompt, the damage it can cause is limited to the scope the user authorized. This design approach is known in the industry as a practical application of the "least privilege principle" to agents.

Custom connectors and triggers: from "can call" to "takes initiative"

Beyond the prebuilt app ecosystem, AgentKit lets developers register internal APIs as custom connectors. This is especially critical for mid-size and large teams—an enterprise's core capabilities are often embedded in its own systems, not on any standard SaaS list. Only by bringing these internal interfaces into the same gateway can agents truly participate in business processes.

The Triggers feature moves agents from "passively waiting to be called" to "event-driven." The official example is very concrete: the moment an email arrives, an agent can be triggered to start working. This kind of mechanism makes agents feel more like always-on business assistants rather than chat windows that require a human to click.

For developers, the combination of these two capabilities means AgentKit isn't just solving connectivity—it's also trying to define when and under what conditions agents run. That is precisely the dividing line between production-grade agents and toy demos.

Event-Driven Architecture is the core concept behind the Triggers feature. Unlike the traditional request-response model, in an event-driven model the system automatically triggers follow-up actions when specific events occur, without manual intervention or polling. In the AI agent context, this means agents can shift from "waiting for someone to ask" to "acting when they sense a change." Common triggers include email arrival, file updates, database record changes, and webhook callbacks. This pattern is essential for building always-on business assistants, because it allows agents to continuously listen for business events and make autonomous decisions, rather than existing only as conversational interfaces. However, event-driven design also brings new challenges: how to prevent duplicate triggers, how to set trigger rate limits, and how to maintain stability during event storms are all issues that production deployments need to consider.

Observability and a free tier: pragmatic configuration for production

The official materials specifically mention that "every call is logged," and the product is explicitly positioned for "developers taking agents to production." Observability is an unavoidable threshold for putting agents into production: without call logs, problems can't be diagnosed, and compliance reviews can't even begin. Making logging a default capability rather than a paid add-on shows the team understands the real demands of production environments.

On pricing, AgentKit offers a free tier of 10,000 tool calls per month. For teams in early validation stages, this quota is enough to run through the full pipeline; for large-scale use, the cost structure needs further evaluation.

The promise of the gateway model—and the open questions

AgentKit represents a product approach that is taking shape: rather than having every agent handle authentication and integration separately, add a unified gateway between the protocol layer and the business layer, consolidating identity, permissions, logs, and connectors in one place. This mirrors the role API gateways played in the microservices era.

However, the 40 comments on Product Hunt also remind us that this space is highly competitive, and developers will be especially sensitive to gateway latency, failure domains, vendor lock-in, and similar issues. Routing all tool calls through the same middle layer means it simultaneously becomes a potential performance bottleneck and single point of failure; delegating internal APIs and user permissions to a third-party platform also requires sufficient security trust.

AgentKit's answer is to centralize complexity management and give permissions back to users. Whether this direction is right will ultimately be validated by the teams actually putting agents into production.

One-line Summary

Scalekit launches AgentKit, an MCP gateway that lets AI agents securely call 600+ app tools under user identity and least privilege.

Paragraph Summary

AgentKit, released by Scalekit, is an MCP gateway product designed to solve the authentication, permission, and integration challenges AI agents face when calling external tools in production. It provides a unified entry point for agents to access more than 600 apps and over 30,000 tools, and supports registering internal enterprise APIs as custom connectors. Its core design is that every operation executes as the identity of the user who initiated the request, strictly limited to the scopes the user has authorized, with Virtual MCP Servers enforcing least privilege. The Triggers feature shifts agents from passive invocation to event-driven operation, and all calls are logged for observability. The product offers a free tier of 10,000 calls per month and took #1 product of the day on Product Hunt. While the gateway model centralizes complexity, it also faces unresolved questions around latency, single points of failure, and vendor lock-in.