AgentKit (by Scalekit) - MCP gateway for production agents that acts on your behalf
by•
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.
Replies
Congratulations Team scalekit on the launch.
@phrishikesh thank you, Rex!
The free tier looks useful for testing a complete workflow. Nice that all the connectors are available from the start!
@marianna_tymchuk for sure! If you ever find one missing, feel free to drop your request in this page: https://www.scalekit.com/connectors
Btw, bringing your own connector is an option too: https://docs.scalekit.com/agentkit/bring-your-own-connector/overview/ :)
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.
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.