mcp-use: A TypeScript Framework That Binds React Views to MCP Tools

The problem mcp-use picks: tool output and tool UI drift apart

Model Context Protocol servers are easy to write and awkward to keep consistent. A tool declares an input schema, returns content, and separately some client renders that content. In practice the schema, the handler's return shape, and whatever front end consumes the result are three files maintained by hand. mcp-use's answer is to make the Zod schema the single source. In the README example, weatherInput and weatherOutput are declared once, passed to server.tool as inputSchema and outputSchema, and the same output shape reappears in the React view as toolOutput and refresh.data?.structuredContent. The audience is TypeScript developers shipping MCP servers that have a visual surface: ChatGPT apps, Claude connectors, anything where a tool result should render as a card rather than a paragraph of text. If your tools return plain strings and always will, the framework's central feature is dead weight.

How a tool, a schema and a view are wired together

The mechanism is name-based binding. A tool is registered with a view key: view: { name: "weather-card" }. The README instructs you to create views/weather-card/view.tsx, and states that the directory name matches view.name on the tool. That is the whole contract, and it is worth being explicit about what it implies. The README example view does not import anything from the tool file. Rename the directory or the view.name string and the two no longer match. The framework compensates on the data side, where typing is real: useToolContext<"get-weather">() narrows toolInput and toolOutput to that tool, and useCallTool("get-weather") returns an object whose data field the example reads as refresh.data?.structuredContent. The view also reads status, which the example branches on with "pending" and "error" cases, and falls back to toolOutput when a refresh has not completed. So the type safety is in the payload, while the visual association is a string convention. That is a reasonable trade for a file-based scaffold, but it is the seam where bugs will live.

Getting a server running: the scaffold, the dev loop and the Inspector

The documented path is a single command: npx -y create-mcp-use-app@latest. The README says the generated project includes the server, TypeScript configuration, development scripts, an Inspector and a React view pipeline, and that you then run npm run dev in that directory. Development mode serves the MCP endpoint at http://localhost:3000/mcp and exposes the Inspector at http://localhost:3000/mcp/inspector, so tool invocation and view rendering are both reachable from a browser without extra setup. The README also notes that the MCP endpoint serves a client-ready landing page carrying its connection URL and setup instructions, which matters if you are handing the server to someone else to connect. For production there is npm run build. The server itself is constructed with new MCPServer({ name, title, version }) and tools are registered through server.tool({...}). There is also an agent-first entry point: the README offers a prompt at https://mcp-use.com/prompt.md and a text snippet telling an agent to build an MCP server from that URL.

Where the framework gets in the way

The view pipeline is the main cost. Adding a React build step to an MCP server means your deployment now produces two artifacts, and the README's build section gives one command, npm run build, without describing what the output contains or how it is served in production. That is a documentation gap you should resolve before you commit, not after. The second constraint is the version split. The README's migration note is addressed to TypeScript users moving from v1 to v2, pointing at a migration guide and suggesting you hand the migration to an agent. A v1-to-v2 break in a framework whose selling point is typed schemas flowing end to end is not a cosmetic upgrade; schemas and view props are exactly the surfaces a major version would touch. The third limitation is conceptual: this is a framework, not a library. server.tool, MCPServer, useToolContext and useCallTool are its abstractions, and a server written against them is not trivially portable to a bare MCP SDK. If you want to stay close to the protocol, mcp-use is the wrong layer.

The alternative: the official MCP SDK without a view layer

The obvious comparison is the Model Context Protocol's own SDK, which gives you a server object, tool registration and transport, and nothing else. The difference in approach is not features, it is where the UI lives. With the base SDK, a tool returns content and the client decides how to render it; there is no views/ directory, no view.name on the tool, no React runtime in your dependency tree, and no build step beyond compiling your server. You write more glue if you want a custom card, and you own the schema-to-render consistency yourself. mcp-use inverts that: it accepts a heavier toolchain in exchange for the schema, the handler result and the view props sharing one type. Neither is strictly better. A server that exposes database queries to an agent needs the SDK and would find mcp-use's view machinery inert. A server whose whole purpose is an interactive card inside ChatGPT is doing unnecessary work if it hand-rolls the same wiring.

Maintenance, releases and the MIT licence

The repository is active rather than archived, with the most recent push on 2026-11-02 and the three listed releases all canary builds dated 2026-10-29: [email protected], @mcp-use/[email protected] and @mcp-use/[email protected]. Three packages released together suggests the project is maintained as a set. The framework is MIT-licensed, which is permissive and permits commercial use and modification, but the licence covers this repository only. The README points at https://manufact.com for deployment, and a hosted deployment path is a separate service with its own terms, so read those independently before you assume the MIT grant extends to it. For upgrade cost, the concrete signal is the v1-to-v2 migration guide: budget time for it if you have an existing server, and check whether your current tool definitions and views are covered by the guide before you start.

Who should pick this up, and what to check first

The framework fits a team already writing TypeScript that needs MCP tools with a real interface, in ChatGPT or Claude, and is willing to run a React build alongside the server. The scaffold, the Inspector at /mcp/inspector and the typed hooks mean the first working app is a short distance from npx -y create-mcp-use-app@latest. It fits less well if your tools are headless, if you are on Python (the README presents mcp-use as the TypeScript framework for MCP and its migration note is for TypeScript), or if you need your server to stay legible to someone who knows the base MCP SDK and nothing else. Before adopting, open the v2 server documentation and confirm that view binding is genuinely directory-name based, since the README states the convention but does not describe what happens on a mismatch. Then check what npm run build emits and how that output is served, because the README stops at the command. Those two answers decide whether mcp-use is a convenience or a second deployment problem.

Editorial conclusion

Adopt mcp-use if you are writing MCP servers in TypeScript and you want the tool definition, its Zod schemas and its React view to be one artifact rather than three that drift apart. Do not adopt it if your server is a thin wrapper over an existing HTTP API with no UI, because you would be paying for a view build pipeline you never call. Before committing, verify three things against docs.mcp-use.com/v2: whether the v1 migration guide covers every API you already use, whether the Inspector's headless mode fits your CI, and whether the MIT licence on the framework is compatible with how you ship the generated app to ChatGPT or Claude.

Frequently asked questions

Official sources

1. License: MIT
2. mcp-use/mcp-use on GitHub
3. Project website
4. README
5. Releases