Launching today
NitroStack
Build, test, and deploy MCP servers in one place
509 followers
Build, test, and deploy MCP servers in one place
509 followers
NitroStack is the full-stack platform for building production-ready MCP servers and AI apps. Build with open-source TypeScript & Python SDKs, test and debug visually in NitroStack Studio, orchestrate agent workflows with NitroStack Workflow, deploy on NitroStack Cloud, and ship branded experiences with NitroStack Chat. Auth, testing, deployment and frontend stay in one workflow. Connect to ChatGPT, Claude and other AI clients. Powering 80,000+ MCP servers.
Free Options
Launch Team
Viktor.comAn AI coworker that actually does the work
Promoted
@abhishek_dutta7 This could save developers a lot of time. What makes NitroStack different from other MCP tools?
@rohit62661 Thanks! Most MCP tools are strong in one stage, whether that’s building, testing or hosting. NitroStack covers the complete lifecycle, from idea to production, in one stack. Creating an MCP isn’t the hard part. Making it secure, scalable and reliable enough to power real workflows and serve customers at scale is, and that’s exactly where we focus. With our recently launched NitroStack Workflow, you can also connect multiple MCP apps, your own or third-party, and automate workflows around them. Whatever you’re doing with MCPs, we want NitroStack to be the place you do it.
Congrats Abhishek and the NitroStack team on the launch. Going from a decorated Zod tool to a deployed server on NitroCloud in one flow is the part that would save me the most glue code. To answer your question, what I still stitch together myself is per-user OAuth when a tool calls a downstream API like Google or Salesforce on behalf of the end user. Do the SDK auth modules store and refresh those tokens per user, or is that still on me?
@genedai Thank you, Gene. We appreciate the kind words.
To answer your question: NitroStack validates the OAuth 2.1 token on every tool call, so each tool knows which user is calling. The server is stateless and does not need sessions to do this. For downstream services such as Google and Salesforce, the SDK includes an OAuth 2.1 client that handles PKCE authorization, token exchange, refresh, and revocation.
Storing those downstream tokens for each user is currently up to you as the developer. There are two common approaches. You can let your identity provider hold the tokens (Auth0 Token Vault is one example) and exchange the verified user identity for a fresh token at call time. Or you can implement the SDK's TokenStore interface on top of your own database, keyed by user. A built-in helper that handles the whole flow in a single call is on our roadmap.
Finally, a place where I can build AND test an MCP server without juggling three terminals, honestly the one-click deploy is the part I am most curious to try!