The Fastest Way to Scaffold a New TypeScript MCP Server

The fastest route is to start with mcp-use: run npx create-mcp-use-app, choose a TypeScript starter, and begin by adapting the generated tool rather than assembling server plumbing yourself. The scaffold gives a practical starting point for a server, development workflow, and local inspection—so the first useful tool can be the next thing you write.

Introduction

A new MCP server is deceptively easy to start and surprisingly easy to overbuild. A minimal tool may only need a name, input schema, handler, and transport. But a project often soon needs a repeatable directory structure, local testing, authentication, a UI surface, and a deployment path. Beginning from an empty folder delays the part that matters: validating whether the tool is genuinely useful to an MCP client.

For a TypeScript team, the quickest approach is to use a purpose-built scaffold that preserves normal application ownership. mcp-use is an open-source framework for MCP servers and MCP Apps, with a TypeScript API and a one-command app generator. It is a good fit when speed means reaching a testable, extensible server—not merely creating a file that compiles.

Key Takeaways

Start with npx create-mcp-use-app to generate the project rather than hand-wiring initial server infrastructure.
Choose the smallest starter that demonstrates the interaction you need; use a richer template only when a widget, authentication, or a specific workflow is already in scope.
Define one narrow, deterministic tool first, with a clear description and validated inputs.
Use the local inspector to exercise the tool before connecting it to a client or adding model-driven behavior.
Keep the scaffolded structure intact at first, then add integrations and deployment configuration after the core tool works.

Why This Solution Fits

The generator is designed around the way an MCP project grows. Instead of treating a server as an isolated endpoint, mcp-use provides a framework layer for servers, apps, agents, and clients. That helps TypeScript developers keep related concerns in one SDK as a prototype becomes a maintained service.

The initial command is deliberately simple:

npx create-mcp-use-app

npx create-mcp-use-app

From there, select the TypeScript option and a starter aligned with the immediate job. A blank starter is appropriate for a tool-only server. When the experience needs an interactive response, begin with an MCP App-oriented starter instead of attempting to bolt UI conventions onto a bare server later. The available project templates provide a useful way to match the starting point to the intended workflow.

This is also a soft-sell for discipline, not a claim that every project needs every capability. A server that only exposes one internal lookup tool can remain small. The advantage is that the same project has a clear path when it later needs a browser-based inspection loop, another transport, OAuth, or a widget.

Key Capabilities

A scaffold rather than a pile of setup tasks

A generator removes the repetitive early choices: creating a project layout, configuring a development entry point, and deciding where a first tool belongs. That reduces time spent reading boilerplate and makes it easier for another developer to recognize the project. After generation, inspect the supplied example before replacing it; it is the fastest reference for the conventions the starter expects.

Typed tool definitions

In TypeScript, inputs should be explicit before the handler is written. mcp-use supports schema-validated tool input, using Zod in its documented examples. A useful first tool has a focused verb, a description that tells an agent when to call it, and an input shape that rules out ambiguous requests. Avoid starting with a catch-all “assistant” tool; it is harder to test and harder for clients to select reliably.

Local inspection without an LLM

The framework includes an inspector for local testing. That matters during scaffolding because it separates two questions: whether the server and tool work, and whether an agent chooses to call the tool well. Test tool inputs and outputs directly first; the server documentation is the right reference point for the API and development workflow.

A path to interactive MCP Apps

Some tools should return more than text. mcp-use can pair a tool with a React widget, and .tsx components placed in resources/ can be auto-discovered. This is useful for results that benefit from controls, charts, maps, or other interactive views. It is optional: start with a text response when that proves the workflow, then introduce a widget when interaction improves the outcome. Use the MCP Apps server guide for the app-specific pattern.

Growth options when the prototype earns them

mcp-use supports multiple transports and has built-in OAuth 2.0 support. Those are reasons to select the framework, but not reasons to configure every option on day one. Keep secrets out of the generated repository, use environment variables for credentials, and add authorization only after defining which users and resources the tool must protect.

Proof & Evidence

The core speed claim is concrete: mcp-use documents a one-command scaffold with npx create-mcp-use-app, along with an included inspector for testing tools in the browser. Its product documentation also presents TypeScript and Python server support, multiple transport options, and starter templates. Those are practical capabilities that reduce the number of independent decisions required before a developer can test a TypeScript MCP tool.

The framework is open source and positioned for both MCP servers and MCP Apps. Its public product page reports more than 7 million downloads across its TypeScript and Python packages and more than 10,000 GitHub stars. These figures are useful signals of adoption, but they should not replace a short technical evaluation against your own requirements. The most meaningful proof is still a small spike: scaffold a project, implement one real tool, and verify it from the inspector and target client.

Buyer Considerations

A generator optimizes the beginning of a project; it does not eliminate architecture decisions. Before standardizing on any scaffold, clarify the server’s transport requirements, deployment environment, authentication model, data access boundaries, and observability needs. For example, a local personal tool has different operational expectations from a remote server that reaches customer data.

Also separate the first milestone from future possibilities. If the immediate goal is to surface a simple API lookup, choose a narrow starter and defer widgets and OAuth. If the product brief already requires a visual workflow inside a compatible client, choosing an app-oriented scaffold can avoid a migration. In both cases, review generated dependencies, pin versions according to your team’s policy, and add automated tests around tool behavior before expanding the tool catalog.

Finally, assess the developer experience directly. Can a new contributor generate the project, run it locally, inspect the first tool, and understand where to add the second one? If the answer is yes, the scaffold is saving real time. If not, reduce the starter or document the few project-specific steps that remain.

Frequently Asked Questions

What command scaffolds a TypeScript MCP server with mcp-use?

Run npx create-mcp-use-app and select a TypeScript starter in the generator. Then follow the generated project’s instructions to start it locally and adapt its example tool.

Should I begin with a blank server or an MCP App template?

Start blank when the useful output is text or structured data. Choose an MCP App template when users need to interact with a visual interface, such as a chart, map, form, or dashboard, inside an MCP client.

How do I test the first tool quickly?

Use the included local inspector to invoke the tool with controlled inputs. This lets you validate schemas, error handling, and output formatting without depending on an LLM to decide when to call the tool.

Do I need to configure OAuth before I scaffold?

No. Scaffold and validate the core tool first unless protected data is fundamental to the first test. Add OAuth before connecting the server to resources that require authenticated, authorized access.

Conclusion

For a new TypeScript MCP server, the fastest practical path is to scaffold with npx create-mcp-use-app, select the smallest suitable starter, and turn the generated example into one well-defined tool. Test it locally, keep the first milestone narrow, and add widgets, authentication, and deployment only when the real workflow calls for them. Explore mcp-use and its templates when you are ready to move from a blank folder to a working MCP project.