Launched this week
Scalekit
MCP gateway for production agents that acts on your behalf
795 followers
MCP gateway for production agents that acts on your behalf
795 followers
Let your agents use 30,000+ tools across 600+ apps, from Salesforce to GitHub, through one MCP gateway. AgentKit handles auth and integrations, so every action runs as the user who asked, within the scopes they granted. Give each agent only the tools its job needs with Virtual MCP Servers. Add internal APIs as custom connectors. Use Triggers to start an agent the moment an email lands. Built for developers taking agents to production: every call is logged. Free tier: 10,000 tool calls a month.
Launch Team / Built With
Render Sandboxes: a computer for every agentIsolated compute, persistent state and a real filesystem
Promoted
Hey Product Hunt,
I'm Ravi, co-founder of Scalekit. Today we're launching AgentKit, an MCP gateway that handles auth and tool-calling for AI agents in production.
Why now? Over the last year, wiring an agent to a tool got easy. MCP standardized the interface, and any agent can now call Gmail or Salesforce after an afternoon of work.
But the tool call is only the surface. Once an agent ships to real users, everything underneath it shows up:
whose credentials each call executes with
which tools each agent should have in context
the internal systems no catalog covers
what happens when an upstream API pushes back
who's accountable for every action
That layer decides whether an agent makes it to production. It's what we built AgentKit for.
Here's what it looks like in practice.
Say you're shipping a sales agent inside your product. A rep types: "Prep me for the Acme renewal. Pull the deal, the last three email threads, what the team said in Slack, when we last met them, and how much they've used the product this quarter."
Four apps, one ask. Getting it working for one rep in a demo is easy. Here's what's underneath when it runs for every rep at every customer:
Thousands of OAuth grants, not four. 40 customers × 30 reps × Salesforce, Gmail, Slack and Calendar = 4,800 connected accounts. Each needs its tokens stored, isolated per customer, and refreshed before they expire mid-run. → AgentKit manages connected accounts end to end. Users authorize through an auth link you surface in your app. Tokens live in a per-tenant AES-256 vault, refresh automatically, and are injected at execution time. They never touch your code, logs, or prompts.
Every call has to execute as the right user. The agent should see what that rep can see at that customer, and nothing more. Not a shared service account with org-wide access to every inbox. → Every tool call executes with the end user's own credentials, within the scopes they granted.
Every tool definition costs context. Gmail alone exposes ~30 tools; four apps put over a hundred on the table. At ~200 tokens per definition, 40 tools burn ~8,000 tokens before the agent does any work, and tool selection gets worse as the list grows. Your prep agent needs about ten tools. Your outbound agent needs a different ten. → Virtual MCP Servers let you compose a tool set per agent role, across connectors. Each role gets one static MCP URL; you mint a short-lived session token per user per run. Smaller context and least-privilege access: ten tool definitions (~2,000 tokens) instead of over a hundred (20,000+).
The data you need has no connector. Usage lives in your customer's internal analytics service. No catalog covers it, so you'd build that integration yourself, auth included. → Define it as a custom connector (OAuth 2.0, API key, bearer token, RSA or basic auth), or point AgentKit at a remote MCP server. It runs on the same gateway with the same credential handling and logs as the 600+ built-in connectors.
It has to hold up and be auditable. Rate limits, timeouts, upstream errors the model can't act on. Then a deal stage changes and someone asks whether the rep did it or the agent did. → Retries and rate limits are handled on every call. Every call is logged with agent, user, tool and response, and logs stream to Datadog or Splunk.
None of this shows up in a demo. All of it shows up in production. AgentKit handles that layer: 30,000+ tools across 600+ apps behind one MCP gateway. And with Triggers, an agent can start on its own the moment an email lands.
Python and Node SDKs. Works with the Anthropic and OpenAI SDKs, LangChain, Google ADK, Vercel AI SDK, Mastra, and Claude Code. You keep your framework and backend.
Which of these five has slowed your agent down the most?
@ravibits Congrats on the launch, Ravi!
@ravibits Congrats on the launch! When an agent needs to act across several tools for one user request, how do you decide which tools should stay in its context versus be fetched or composed on demand? I’m curious how teams balance giving agents enough capability with keeping prompts focused and access truly least-privilege.
@swati_paliwal Thanks! The common mistake we see is treating "what's in context" and "what's allowed" as the same problem. They aren't.
Two ways we solve this.
Context: give each agent a small pinned set of tools via a Virtual MCP server, and use tool search to pull in the rest per request, so you're not shipping hundreds of tool definitions in every prompt.
Access: scopes are set on each connection, and every tool call runs on that user's own token. If a scope isn't granted, the call fails at the provider, whatever the model decides to call.
@ravibits Congrats on the launch.
Does AgentKit support organization-wide connector restrictions?
@buchireddy Yes, it supports. Three levels:
1/ Environment: you choose which connectors are enabled. Agents and APIs only ever see that curated set, never the full catalog.
2/ Agent: a Virtual MCP server limits which connectors and tools a given agent can reach, so a support agent and a finance agent don't share the same toolset.
3/ Permissions: scopes are set per connection (e.g. read-only CRM), and every call runs on the user's own token, so the provider enforces what was granted.
If you're building a multi-tenant product and want each of your customers to switch connectors on or off for their own org, our APIs list your enabled connections, and you keep the per-tenant policy in your app.
@ravibits Congratulations. I will give it a try today
Satya here, co-founder of Scalekit. Some context on why we’re building this. Before Scalekit, we built Pipemonk, an iPaaS that connected SaaS apps and kept data in sync. A developer set it up once and it ran on a schedule.
Agents broke that model. They act on a user’s behalf and decide what to call on every run, so the hard part moved from mapping schemas to runtime access control.
What we kept hearing from teams shipping agents: access that expires mid-run, and permissions broader than the task needs. AgentKit handles that layer, with every call executed as the end user within the scopes they granted.
If you’re building agents in production that need secure access to third-party apps, happy to compare notes here or in DMs.
@satya_deva549 this is pretty cool Satya, will definitely try!
@satya_deva549 Congrats Satya.. 🎉this is awesome and will try it
@satya_deva549 congrats on the launch 🎉
@satya_deva549 Congrats Ravi, Satya and team! Building AI agents is getting easier. Making them secure, reliable and production ready is where the real challenge begins. Identity, permissions and orchestration are super critical infrastructure in the agentic world . Love what you’re building at Scalekit. And many congratulations on the launch!
@arundesigns We don't run a formal startup program, but we have a Free plan with 10,000 tool calls a month. Free to start, no card required. Free plan offers most features as our paid plan, so you're not building on a cut-down version. When you outgrow the Free plan, please reach out at support@scalekit.com and we'll find a plan that fits your needs.
Excited about this launch. Congratulations team! Scalekit helped us with its coverage of some of the emerging tools that are not offered by other vendors. With the agentic capability it'll add wings to their powerful platform. Good luck.
@hnshyam , glad to be a part of your journey. Thank you!
@hnshyam Thank you! Boomerang team's input and support is appreciated.
@hnshyam Thank you. Coverage of the newer, long-tail tools has been a deliberate bet for us: most of those connectors came from our customers.
Ravi and Satya - congrats. Can you explain how the tool calling works and what you built to optimize that? I'm sure there's interesting stuff under the hood.
@alexsalkever we realized over the last few months that newer frontier models nowadays are able to solve the "tool selection" problem quite effectively.
We previously focused very heavily on optimizing the tool descriptions but in the last few hours - we are focusing on giving the right tool input schema along with examples and appropriate default values actually make the tool calling easier for the models and agents. The core optimization we focused on is how often are the agents/models make a "successful" tool call in the first attempt; typically failures we have seen are because the models are not able to reliably "predict" how to structure the right inputs in the right format even though they know this is the tool to use.
Very cool, how does authentication work? Ill try it out.
@chandan_maruthi1 You should definitely try it out and let us know how it goes; Would love to work with you to help build reliable agents.
Everytime agent needs to act in real applications on behalf of a user, we generate a magic link that the human needs to complete - either, it is OAuth handshake, or entering API Keys securely - depending on the upstream provider. We store these tokens in an encrypted vault on our side and we inject the appropriate tokens in the proper place before making the tool calls. We handle the OAuth refresh tokens etc transparently so that the agent tool calling never fails because of stale tokens but more importantly agents don't get access to the tokens either and the tokens never leave our encrypted vault.
Congrats folks on the launch. This is really exciting, are you planning to support browser agents too in the future?
@nikhil_aitharaju Yes. We are working with early partners on browser agent usecases too. Hit us up with your usecase and we would love to work with you!
Congratulations on the launch!! The depth here is impressive - Packaging tools per job seems to be a great way to improve agent effectiveness
Also great to see support for Rocketlane MCP connector :D
@swetha__murali depth >> breadth
@swetha__murali Thanks! Packaging tools per job is the part we'd point most teams to first. A support agent and a delivery agent shouldn't carry the same tools, and keeping them separate helps both accuracy and access. Glad you spotted the Rocketlane connector :)