Launching today
AgentKit by Scalekit
MCP gateway for production agents that acts on your behalf
614 followers
MCP gateway for production agents that acts on your behalf
614 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
AWS Activate CreditsCredits that fuel your startup’s next milestone
Promoted
Congrats on the launch @ravibits @satya_deva549. How is this different from connecting an MCP server directly to my agent?
For a multi-tenant scraping platform, say customers connect their own brightdata, firecrawl or browserbase... when the cust's key stops working, does Scalekit update the connected account’s status, send a webhook, or just return an error on the next tool call? And can we tell between a revoked key (customer must reconnect) and an exhausted balance (customer must top up)?
@codepoet_n Ha, good one. This is the stuff that actually breaks in production.
Every connected account in AgentKit has a status. If a customer’s key stops working, you can catch it with a webhook and send them a link to re-enter it. It works the same for API keys and OAuth, so you don’t build a reconnect flow per provider.
And yes, you can tell them apart. We separate connection errors from upstream API errors. A revoked key shows up as a connection problem, so you ask the customer to reconnect. Running out of credits comes back as an error from the provider itself, so you tell them to top up. No generic errors.
congrats on the launch ravi. from your five the internal apis with no connector hurt me most, every client has some old admin panel the agent just can't reach. do you build those tools from an openapi spec, or someone still writes the connector by hand?
@agshin_rajabov it's a mix of both - we build the tools with openapi spec, for some connectors - we build them by hand and customize the tool descriptions and inputs so that agents have a higher chance of selecting the right tool and executing them
Whose credentials each call runs with, that's the one for us. Our agents never get a password, I do every sign-in myself, so when a session drops in the middle of a run nothing moves until I sign back in. If a token can't be refreshed mid-run, does the agent get an error it can pass back, or does the call just fail?
@julien_zammit usually, most of the token refreshes happen seamlessly behind the scenes. But, in case tool refresh can't happen - agents get a 401 error along with a clear description on how to get the user to reauthorize easily.
The per-tenant token vault plus Virtual MCP Servers per role is a sensible split. One thing I'm curious about: when a user revokes a grant in Salesforce directly, how fast does AgentKit notice, and what does the agent see on its next call, a clean auth error or a silent failure?
Love that every tool call runs with the end user's own credentials instead of a shared service account, and the Virtual MCP Servers idea of giving each agent only the tools it needs is a smart way to save context.
@ilko_kacharov Bang on! Authz is the underrated yet essential problem to solve in the agent world - this is often overlooked for faster experimentation. But then as real traction happens, this becomes a must-solve problem for any production agent.
The user identity in the action log is the detail I'd look at first. When several people use the same agent, it should be clear whose access it acted with.