# NitroStack: a decorator-driven TypeScript framework for MCP servers

> NitroStack wraps MCP server development in decorators, dependency injection and a middleware pipeline, and ships a desktop client called NitroStudio. It is aimed at TypeScript teams, and the README leaves deployment and rollback undocumented.

**nitrocloudofficial/nitrostack** — The full-stack TypeScript framework to build, test, and deploy production-ready MCP servers and AI-native apps.

- Repository: https://github.com/nitrocloudofficial/nitrostack
- Website: https://nitrostack.ai
- Stars: 2,478 · Forks: 1,430
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/nitrocloudofficial-nitrostack

## The gap NitroStack fills for MCP server authors

The Model Context Protocol defines how an AI client discovers and calls tools on a server. What it does not define is how you structure the server code. A minimal MCP server is a switch statement over tool names with hand-written JSON Schema, and that shape gets uncomfortable once you have twenty tools, per-tool authentication, and a caching policy that differs per endpoint. NitroStack is a TypeScript framework that imposes a structure on that code: tools are methods on classes, schemas are Zod objects, and cross-cutting concerns are decorators. The intended reader is a backend engineer who already writes TypeScript services and does not want to hand-roll a dispatcher. The README describes the project as "the enterprise-grade TypeScript framework for building production-ready MCP servers", and the vocabulary it uses (guards, interceptors, pipes, exception filters) is deliberately borrowed from server-side frameworks rather than from the MCP specification itself. That is the whole pitch: if you know how to write a NestJS-style service, the README claims you already know how to write an MCP server.

## Decorators, DI and a middleware pipeline as the mechanism

The mechanism is visible in the README's worked example. An application is declared with @McpApp, which takes a module reference and a server block containing name and version. @Module declares the module graph, and the README shows imports as an array, so composition happens at the module level rather than by registering tools globally. A class then exposes methods decorated with @Tool, which carries a name, a description and an inputSchema built from z.object. The framework reads that schema for validation and for the tool listing the client sees. Stacked on the same method are @UseGuards(ApiKeyGuard), @Cache({ ttl: 300 }) and @Widget('product-grid'). Each of those is a separate concern that would otherwise be inline code: the guard runs before the handler, the cache wraps the result for 300 seconds, and the widget tells the client which React component to render for the output. The handler receives the validated input plus an ExecutionContext, and the README's example calls ctx.logger.info. So the data flow is: client request, guard, cache lookup, schema-validated handler, widget-tagged response. Dependency injection is described as first-class with singleton, transient and scoped lifecycles, though the README does not show a provider registration example, so how a service like the productService in the snippet gets bound is something the Server Concepts documentation page would have to answer.

## Installing NitroStack and running a first server

The README lists Node.js >= 20.18 and npm >= 9 as prerequisites. Scaffolding is a single npx invocation against the CLI package, which the README also lists separately as @nitrostack/cli and suggests installing globally with npm i -g @nitrostack/cli. The scaffold command is:

```bash
npx @nitrostack/cli init my-server
```

That creates a directory named my-server. The README then shows the next two commands, which install dependencies and start the dev server:

```bash
cd my-server
npm install
npm run dev
```

After npm run dev the README states your MCP server is running and can be connected to any MCP-compatible client. It does not print a port, a URL or a startup banner in the README, so if you need to point a client at it you will have to read the generated project or the CLI reference page. The third step the README describes is opening the same folder in NitroStudio, a desktop app downloaded from nitrostack.ai/studio. NitroStudio runs the dev server for you, and the README lists real-time tool testing, payload inspection, built-in AI chat, widget preview and hot reload as its features. For a first real use, the README's own example is a search_products tool with a query string and a maxResults number defaulting to 10; that is the shape to copy when you replace the scaffolded sample with your own tool.

## Package layout and what you actually install

NitroStack is split into three published packages rather than one. @nitrostack/core holds the decorators, the DI container and the server runtime. @nitrostack/cli handles scaffolding, the dev server and code generators. @nitrostack/widgets is a React SDK for the interactive tool output UIs that the @Widget decorator references. The README's framing is that you install only what you need, which matters because a server that returns plain JSON has no reason to pull in a React rendering SDK. The implementation workspace lives under typescript/ in the repository, with typescript/packages/core, typescript/packages/cli and typescript/packages/widgets as the per-package directories. The top level of the repository also contains docs/, sample-apps/, notes/ and assets/, which is where the GIFs referenced throughout the README live. Two releases are listed: v1.0.0 on 2026-07-06, described as the safest stable release, and 1.0.1 on 2026-07-13, described as an updated SDK. The last push to the repository was on 2026-09-07, so the project is not archived and there is recent commit activity, but the released version line has been still since mid-July.

## Where the documentation stops short

The README is a good front door and a poor operations manual. It documents scaffolding, the dev loop and the decorator surface, and it links out to a documentation site with pages for server concepts, tools, widgets and authentication. What it does not contain is any deployment story. There is no section on building for production, no container image, no mention of how the server is hosted, and no rollback procedure. For a framework whose headline word is "production-ready", that is a real gap, and it is the gap you should probe before committing. The same applies to the middleware pipeline: guards, interceptors, pipes and exception filters are listed as features, but the README shows exactly one guard usage and no interceptor or filter example, so their execution order relative to the cache decorator is not something you can determine from the README. Authentication is the third thin spot. JWT, OAuth 2.1 and API key are listed as built in, and ApiKeyGuard appears in the example, but the README does not show how a token is verified or where the signing secret is configured. All three of those are documented as separate pages on docs.nitrostack.ai, which is a reasonable place for them to live, but it means the README alone cannot tell you whether the auth model fits your deployment.

## How NitroStack differs from the official MCP SDK

The obvious alternative is the official TypeScript SDK for the Model Context Protocol, which is the reference implementation most MCP servers are built on today. The difference is one of layer, not of capability. The official SDK gives you the protocol: transport handling, the request and response types, and a registration API for tools, resources and prompts. You write the wiring. NitroStack sits above that and supplies the application structure: a DI container with three lifecycles, a middleware pipeline, decorator-based tool declaration, a cache decorator, and a React widget SDK for tool output. The trade-off is direct. With the official SDK you have fewer moving parts and no framework conventions to learn, and the server does exactly what the protocol says. With NitroStack you get the structure that pays off at twenty tools and costs you at two, plus a dependency on a smaller project with a short release history: two published releases, the newest on 2026-07-13. If your server is a handful of stateless functions, the official SDK is the smaller commitment. If you are building something that looks like an internal API with auth, caching and UI, the decorator approach removes code you would otherwise write and maintain yourself.

## Licence and the cost of keeping up

NitroStack is licensed under Apache-2.0, which permits commercial use, modification and redistribution, and includes an explicit patent grant. It does not impose a copyleft obligation on your server code, so shipping a closed-source MCP server built on @nitrostack/core is within the terms as stated. That is the licence text, not legal advice; if your organisation has a policy on patent clauses or attribution notices, run it past whoever handles that. On upgrade cost, the honest reading of the release list is that the project is young. v1.0.0 arrived on 2026-07-06 and 1.0.1 on 2026-07-13, so there is no multi-version history to judge how breaking changes are handled, and no changelog is present in the README. The practical consequence is that you should pin @nitrostack/core to an exact version in package.json rather than accepting a caret range, and read the release notes before moving. Because the framework owns the DI container and the decorator metadata, a breaking change in @nitrostack/core can touch every tool class in your project at once, which is a different risk profile from a breaking change in a leaf utility library.

## Conclusion

Adopt NitroStack if your team already writes TypeScript services and wants MCP tool definitions, validation, auth and caching expressed as decorators on ordinary classes, with NitroStudio for local debugging. Do not adopt it if you need a non-Node runtime, or if you want the framework's own docs to tell you how to deploy and roll back a server in production, because the README stops at npm run dev. Verify three things first: that the @nitrostack/core version you install matches the 1.0.1 release, that the auth strategy you need is documented under docs.nitrostack.ai/sdk/typescript/authentication-overview, and that your MCP client can reach the server outside NitroStudio, since the README only demonstrates the desktop path.

## FAQ

### What is NitroStack?

NitroStack is a TypeScript framework for building MCP servers, published as @nitrostack/core with a CLI package for scaffolding and a React widget SDK for tool output UIs. It provides decorator-based tool definitions, dependency injection, a middleware pipeline and built-in authentication.

### What is a Nitro server?

In this project's context, it is an MCP server built with NitroStack: a Node.js process scaffolded by npx @nitrostack/cli init and started with npm run dev, exposing tools that MCP-compatible clients can discover and call.

### Does Discord Nitro stack?

This question is about Discord's Nitro subscription and has nothing to do with NitroStack, the TypeScript MCP framework. The README does link a Discord community server for the project, but that is a support channel, not a subscription product.

## Sources

- [License: Apache-2.0](https://github.com/nitrocloudofficial/nitrostack/blob/main/LICENSE)
- [nitrocloudofficial/nitrostack on GitHub](https://github.com/nitrocloudofficial/nitrostack)
- [Project website](https://nitrostack.ai)
- [README](https://github.com/nitrocloudofficial/nitrostack/blob/main/README.md)
- [Releases](https://github.com/nitrocloudofficial/nitrostack/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nitrocloudofficial-nitrostack