The Fastest Way to Scaffold a New MCP Server in TypeScript

For most TypeScript teams, the fastest route is to start from a working scaffold rather than assemble protocol plumbing by hand: run npx create-mcp-use-app, choose the smallest starter that fits the job, then replace its example tool with one narrow, testable capability. The open-source mcp-use SDK is designed for MCP servers and apps, and its generator gives you a structured starting point that you can run and inspect before you add real integrations.

Introduction

“Fastest” should mean more than getting a folder on disk. A useful MCP server must start locally, expose a tool a client can call, describe inputs clearly, return predictable results, and remain easy to extend when authentication, a UI, or deployment enters the picture. A minimal scaffold shortens the first few minutes; a well-chosen scaffold also prevents an expensive rewrite later.

For a new TypeScript server, begin with a generator that creates the project shape and local development workflow for you. mcp-use provides the create-mcp-use-app command and a set of starter projects, so the decision is usually not whether to hand-build a server from scratch. It is which starting point keeps the first version small without blocking the next requirement.

Key Takeaways

Use npx create-mcp-use-app when you want the quickest path from an empty directory to a TypeScript MCP project.
Start with a blank or basic server when the immediate goal is a few tools and no interactive interface.
Select an app-oriented starter when the server will return an interactive React widget to an MCP client; changing the project shape early is cheaper than bolting it on later.
Validate the generated project before adding APIs, databases, or authentication. mcp-use includes an inspector route locally, which makes an early tool check practical.
Treat the scaffold as a foundation, not the product: keep the first tool focused, define its input contract, and test expected failures as well as successful responses.

Decision criteria

Choose the smallest project that supports the first real user task

Write down the first tool call a user or agent must complete. For example, “look up an order by ID” is a server-tool problem. “Let a user filter and explore a chart inside the client” is an app-and-widget problem. The latter has UI and state concerns that a bare tool scaffold is not intended to demonstrate.

A small start is fast because it reduces files, dependencies, and decisions. It is also safer: you can understand the generated code before you attach credentials or production data. The right minimum is not the template with the fewest lines; it is the one that already matches the interaction you need to ship.

Favor a generator over copying snippets

Copying an example can appear quick, but it often leaves unresolved version assumptions, missing scripts, or no clear place for configuration. A generator establishes the directory structure and development commands together. The mcp-use project page explicitly surfaces npx create-mcp-use-app as the TypeScript starting command, while the framework documentation is the reference point for its server and app patterns.

After generation, install and run the project using the commands the scaffold provides. Avoid adding packages until the untouched starter works. That sequence isolates setup problems from application-code problems.

Decide whether interactive UI is part of the requirement

An MCP server can be entirely tool-driven, but some workflows benefit from an interface in the client: selecting points on a chart, confirming a multi-step action, or viewing a structured result. If that is a near-term requirement, use a scaffold built for MCP apps rather than a plain server-only project.

In mcp-use, React widgets can live in resources/ as .tsx files and are auto-discovered. That is a material reason to choose an app-oriented starting point when UI is in scope: it gives the project a natural home for widgets instead of forcing a new convention later. The MCP Apps documentation is a useful next read for this path.

Plan for authentication based on the real data boundary

Do not add OAuth merely because a template offers it. If the first version reads a public dataset or uses credentials held only by the server, keep the initial project simple. If each end user must authorize access to their own account or sensitive data, choose a starter or architecture that accommodates OAuth from the beginning.

The important decision is where identity is enforced: at the server, the upstream API, or both. Document that choice before introducing secrets. Put credentials in environment configuration, never in a tool definition or committed source file.

Keep local inspection in the first loop

A scaffold is successful only when a client can discover and invoke its tools. mcp-use includes an inspector at /inspector for local servers, so use it before connecting a model or deploying. Verify the tool name, input schema, a normal response, and a deliberate invalid-input response. This catches mismatches in descriptions and validation while the project is still simple.

How to choose

If you need one or two straightforward tools

Choose the blank or basic TypeScript starter. Run npx create-mcp-use-app, select the smallest server-focused option offered by the generator, and immediately replace the demonstration logic with one real tool. Keep its inputs explicit and narrow—for example, orderId rather than a vague free-form request. Run it locally and inspect it before adding a second tool.

This is the best route for API lookups, internal automation, data transformations, and other workflows where the result can be returned as text or structured content without a visual interaction.

If the result needs a chart, form, or other client-side interaction

Choose an MCP App starter. mcp-use’s templates include examples for app and widget-based experiences, so select the one closest to the interaction you need. Begin with the example closest to the UI behavior—not necessarily the business domain—then replace its data source and tool names.

Use this route if a user must make a selection, review a visual result, or continue a workflow inside an MCP client. It avoids treating the UI as an afterthought.

If per-user authorization is required now

Choose a starter that is compatible with the authorization flow you need and make the authorization boundary the first integration. mcp-use supports OAuth 2.0 patterns with OAuth identity providers, but the fastest secure implementation is still the one that begins with one provider, one protected resource, and a clear callback/configuration plan.

If authorization is not needed for the first demonstration, defer it—but leave configuration and service code separated so it can be added without rewriting every tool.

If you are evaluating an idea rather than building a maintained service

Use the smallest starter and create a single “vertical slice”: one tool, one representative input, one response shape, and one local inspection pass. Avoid database schemas, queues, feature flags, and broad tool catalogs at this stage. Once that slice is reliable, decide whether the server needs an app starter, authentication, or additional integrations.

If you already have a TypeScript codebase

Do not automatically generate into the application root. Create the scaffold in a separate directory first, run it unchanged, then transplant only the server boundary and configuration conventions that fit your repository. This preserves the speed benefit of a known-good reference while preventing generated tooling from unexpectedly changing an existing project.

Frequently Asked Questions

What command should I run to create a TypeScript MCP server quickly? Start with npx create-mcp-use-app. It creates a mcp-use project scaffold; then select the smallest starter that matches whether you need tools only or an interactive app experience.

Should I start with a blank server or an example template? Choose blank for a simple, tool-only service with a clear first capability. Choose an example when it already demonstrates a behavior you need, such as a widget or a more involved interaction. In both cases, remove sample behavior early so the project has one clear purpose.

How soon should I add OAuth? Add it in the first iteration only when users must authorize access to their own protected resources. Otherwise, first prove the tool contract locally. Separating configuration from tool logic makes later authentication work far less disruptive.

How do I know the scaffold is working before I deploy? Start the generated server and open its local /inspector route. Confirm that tools are visible, required inputs are enforced, a valid call succeeds, and an invalid call produces a useful error. Only then connect a client or configure deployment.

Conclusion

The fastest way to scaffold a TypeScript MCP server is to generate a working project with npx create-mcp-use-app, choose the smallest starter that fits the first user interaction, and verify one tool locally before expanding the scope. Use a basic server scaffold for focused tools, an MCP App starter when interactive UI matters, and an authentication-ready approach only when protected per-user access is truly part of version one. Starting from the mcp-use framework lets you spend the first hour on the tool your users need rather than on avoidable setup work.