
Mcp React Toolkit
io.github.Nishant-Chaudhary5338Published by GitHub account Nishant-Chaudhary5338v1.0.1Updated Oct 27, 2026
9 MCP servers for React/TypeScript — dep auditing, a11y, test gen, and TypeScript enforcement.
Overview
A local npm toolkit of 59 React/TypeScript dev tools — scaffolding, audits, test generation, CRUD and CRA-to-Vite migration — each run as its own stdio MCP…
- What you can do
- Scaffold and extend components: component factory from shadcn/ui templates, Storybook stories, variants and edge-case tests
- Audit and fix code quality: TypeScript any-type rules, WCAG 2.1 accessibility checks and autofixes, design tokens, render and performance analysis, bundle budgets, review gates
- Generate and repair tests: Vitest suites, test-gap analysis, fixtures, failing-test triage, Playwright CRUD specs and visual regression setup
- Build full CRUD features from a JSON sample or OpenAPI schema: field inference, Zod schemas, API clients, forms, tables, detail views, routes and MSW mocks
- Migrate Create React App to Vite, including env vars, Jest to Vitest and webpack config…
- When to use it
- Useful when an assistant works on React/TypeScript codebases and you want repetitive, multi-file work — audits, scaffolding, migrations, test generation — done in one structured call instead of many read/write turns. Less worthwhile for small, novel single-file edits.
- Requirements
- Runs locally over stdio via npx from the npm package mcp-react-toolkit; Node.js is required. Each tool is started separately by name, so one server entry per tool in the client config. No authentication, environment variables or headers are declared.
Installation
In SourceWeft
- Open Mcp React Toolkit in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
mcp-toolkit
MCP servers for React + TypeScript development automation. Works with Claude Desktop, Cline, Cursor — and as plain CLI scripts — one protocol, zero duplication.
[npm] [CI] [License: MIT] [MCP SDK]
59 tools across 9 categories — component scaffolding, code quality, a full CRUD-feature factory, CRA→Vite migration, and more. Every tool ships as its own MCP server, built and tested independently.
Why this exists — the token math
Here's the thing nobody tells you when you start building agentic workflows: the loop itself is what's expensive, not the model. An agent working without any composed tools does everything the slow way — read a file, think, write a file, read it back to check its own work, repeat — and every single one of those turns re-sends the whole conversation so far as input tokens. By the time you're 20 steps into a real multi-file task, that resent context alone can be running 50K+ tokens per call. It adds up fast, and it's not really about which model you're using.
I didn't just take that on faith — a few sources back it up with real numbers. LeanOps measured agent loops running about 3.2× the tokens of a single direct call at 5 steps, ~30× at 50 steps, and past 100× once you're deep into a typical build-and-debug session — because re-sent context is roughly 62% of the bill. Vantage found similar: real agentic sessions run an input-to-output ratio around 25:1 (a direct call is closer to 1:1), with a 50-turn session routinely hitting a million input tokens, and non-agentic usage on comparable work costing something like 200× less per interaction on the same team. And a recent arXiv paper on agentic tokenomics puts agentic tasks at roughly 1000× the tokens of single-turn work, with up to 30× variance run to run on the exact same task — so it's not just expensive, it's unpredictable.
That's the problem this toolkit's composed tools are built to get rid of. workflow-runner's schema_to_feature and cra-to-vite don't add one more tool call into an agent's existing loop — they replace what would otherwise be 7 or 8 separate read/write/verify turns with a single in-process call that runs the whole generator or migration pipeline and hands back the finished result. That's the "50-turn loop collapses into 1 call" shape the research above says saves 10–100×, which is a very different thing from just bolting one extra tool onto an unchanged loop (that only gets you the 20–40% range).
To keep myself honest, I also ran a real, measured benchmark rather than just trusting the theory — ax-benchmark, 6 tasks, claude -p running headless, three arms (agent alone, agent with one MCP tool call added into its loop, and the tool called directly with no agent at all). This is a conservative baseline on purpose, since it only tests adding a single tool call into an otherwise unchanged loop, not the deeper pipeline collapse described above:
Two things worth being upfront about: cost is the fair metric here, not wall-time — the agent-alone arm ran headless with no shell access and over-explored on open-ended tasks, which inflated its time without touching its actual cost. And on small, novel, single-file work, the overhead of the tool's structured output can offset what it saves — the real win shows up on repetitive, mechanical, multi-file work, which also happens to be exactly where the multi-turn-loop tax above hits hardest.
Install
Published on npm as mcp-react-toolkit. No clone or build required:
Add it to Claude Desktop / Cursor / Cline:
Swap in any tool name from npx mcp-react-toolkit --list. Restart your client and the tool appears.
Interactive dashboards
Most MCP tools return raw JSON. These return that JSON plus an interactive HTML dashboard — health score, sortable issue triage, light/dark toggle, and one-click fix actions that call other tools in the toolkit. One self-contained artifact, no server, no external requests:
Analysis tools (legacy-analyzer, component-reviewer, dep-auditor, etc.) get an audit view — grade, category cards, filterable issue table. Generators (component-factory, code-modernizer, etc.) get a result view — files created/changed, diffs, follow-ups. Powered by the internal @mcp-showcase/ui-kit package: dependency-free, ~30 KB per report.
Tools
Component Development
Code Quality & Modernisation
Monorepo & Infrastructure
CRUD Factory
One JSON API sample (or OpenAPI schema) fans out into a full, typed CRUD feature. Every generator keys off the shared FieldSchema contract, so the pieces compose.
CRA → Vite
Migrate a Create React App project to Vite: analyze → plan → scaffold → migrate → verify.
Boilerplate
Meta
Automation workflows
Chain tools together for common tasks:
How MCP works
Each server extends McpServerBase from tools/shared/ — handles transport, routing, and error formatting. Adding a new tool is ~50 lines:
Run from source (contributors)
Prefer npm for everyday use (see Install). Clone only to hack on the tools or run the showcase UI:
Point Claude Desktop at a local build the same way as Install, swapping npx -y mcp-react-toolkit <name> for node /path/to/mcp-toolkit/tools/<name>/build/index.js.
Use as a CLI / in CI
Every tool's build/index.js has a #!/usr/bin/env node shebang — pipe a JSON-RPC message to it on stdin:
Testing
Every tool has a co-located Vitest suite covering its core logic directly — no MCP transport required.
CI runs on every push and PR against Node 20 and 22.
Companion package
code-graph-indexer — indexes any TS/React/Next.js repo into a queryable code graph (files, components, functions, and the edges between them) and answers structural questions: who calls this, blast radius, dead code, semantic search. Same family, separate package.
Contributing
See CONTRIBUTING.md — how to scaffold a new tool, write tests, and open a PR.
Stack
TypeScript strict · Node.js · MCP SDK 1.12 · Vitest · React 19 · Vite · Tailwind CSS · Express
Built by
Nishant Chaudhary — Senior Frontend Engineer · [email protected]
Also see: dashcraft · react-present · ai-builder
MIT License
Source: README.md at commit 7b64768
Tools
0Version history
1- v1.0.1LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts