Provides tools and resources for inspecting and modifying Nuxt applications, exposing resolved routes, config, modules, layers, auto-imports, components, composables, Nitro server routes, and generated types.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-nuxt show me all resolved routes and which layers they come from"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A production-ready Model Context Protocol server that gives LLMs Nuxt's resolved state.
Generic LLMs get file-based routing, auto-imports, extends layers, and Nitro wrong more often than anything else in Nuxt.
A generic AI agent looking at a Nuxt repo sees a directory tree. It does not see:
pages/users/[id].vue maps to /users/:id, or the definePageMeta middleware and layout contract.
components/base/BaseButton.vue is available as <BaseButton> with no import statement.
composables/useFoo.ts exports useFoo(), typed and callable anywhere.
extends: ['../ui-kit'] layers an override chain of components, pages, and config over the app.
server/api/hello.get.ts registers GET /api/hello in the Nitro runtime.
Without that context the model guesses. It invents import paths, misnames auto-imported components, and misreads layer precedence. The gap is between the source tree and Nuxt's resolved runtime state.
mcp-server-nuxt exposes that resolved state through 22 tools and 7 read-only resources over MCP. It reads Nuxt's own output rather than scanning files.
Principle | What it means in code |
Deep Nuxt Kit integration |
|
Layer-aware | Resolves the |
Auto-imports registry | Serves the auto-imports index with source paths and TypeScript signatures from |
Write protection | Mutation tools default to |
Strict TypeScript |
|
Related MCP server: Next.js MCP Server
Prerequisites: Node.js 18 or newer.
# via npx
npx mcp-server-nuxt@latest /path/to/your/nuxt/app
# or install globally
npm install -g mcp-server-nuxt
mcp-server-nuxt /path/to/your/nuxt/appThe server speaks MCP over stdio; it is not a web service. To run from a local checkout:
git clone https://github.com/<your-org>/mcp-server-nuxt.git
cd mcp-server-nuxt
npm install
npm run build
node dist/index.js /path/to/your/nuxt/appOmit the path to use the current directory. Pass --allow-writes or set MCP_NUXT_ALLOW_WRITES=1 to enable write tools. See Write protection.
.cursor/mcp.json){
"mcpServers": {
"mcp-server-nuxt": {
"command": "npx",
"args": ["mcp-server-nuxt@latest", "/path/to/your/nuxt/app"],
"env": {
// set this only if the agent may write files
"MCP_NUXT_ALLOW_WRITES": "1"
}
}
}
}claude_desktop_config.json){
"mcpServers": {
"mcp-server-nuxt": {
"command": "npx",
"args": ["mcp-server-nuxt@latest", "/path/to/your/nuxt/app"],
"env": {
"MCP_NUXT_ALLOW_WRITES": "1"
}
}
}
}Start without MCP_NUXT_ALLOW_WRITES. The agent can still plan every change and show you the diff before applying.
The server exposes read-only resources (resources/*) for large, cacheable datasets, and tools (tools/call) for targeted queries and mutations. Resources carry the bulk context so the agent does not re-scan files each turn.
┌─────────────────────────────────────────┐
│ mcp-server-nuxt │
│ │
MCP client ───────► │ ┌──────────────┐ ┌───────────────┐ │
(Claude/Cursor/v0) │ │ 22 Tools │ │ 7 Resources │ │
│ └──────┬───────┘ └───────┬───────┘ │
│ │ │ │
│ ▼ ▼ │
│ NuxtProjectContext (cached snapshot) │
└─────────┬───────────────────┬───────────┘
│ │
@nuxt/kit loadNuxtConfig .nuxt/imports.d.ts
extends resolution .nuxt/tsconfig.jsonURI | Content |
| Project summary: Nuxt version, layers, directories, and route/component/composable/module counts |
| Resolved route map: files, params, middleware, layouts, children |
| Resolved |
| Installed modules with status, source, and configuration |
|
|
| Parsed registry of auto-imported symbols with source paths and TypeScript signatures |
| Raw generated types ( |
nuxt://project/layers resolves the extends graph and orders it by precedence (project > later extends > earlier extends), so the agent knows which BaseButton.vue wins when several layers define one.
nuxt://project/auto-imports reads .nuxt/imports.d.ts and returns the registry of auto-imported symbols (ref, useFoo, BaseButton) with their file origins and type signatures. The model does not have to guess an import path.
nuxt://project/auto-imports needs the app to have been prepared or built (nuxi prepare or nuxi build) so .nuxt/imports.d.ts exists.
Tool | Description |
| Summary: Nuxt version, layers, module/route/component counts, directories |
| Read the resolved |
| Update a config value, keep comments and formatting, return a diff |
| Active and inactive Nuxt modules with version, source, and config |
| Add a module to the |
| Resolve and return the full |
Tool | Description |
| File-based, dynamic, optional, catch-all, and nested routes |
| One route by path, e.g. |
| Scaffold a page under |
|
|
| Nitro endpoints, middleware, and plugins with method and middleware chain |
| Generate an H3 handler with optional Zod body validation |
Tool | Description |
| All components, including those injected by layers and modules |
| Props types, emits, slots, and |
| Generate a typed Vue SFC |
| User-defined and auto-imported composables |
| The |
| Raw generated type info ( |
Tool | Description |
| Run |
| Classify Nuxt modules vs runtime/dev deps, flag missing or misplaced ones |
| Search the codebase with line numbers and context lines |
| Offline Nuxt guidance for routing, nitro, modules, layers |
update_config, add_route, add_nuxt_module, scaffold_nitro_api, and generate_component all follow the same contract:
dryRun is true by default. The tool returns the planned file or a diff without writing to disk.
A real write needs dryRun: false and a server started with writes enabled:
# CLI flag
mcp-server-nuxt /path/to/app --allow-writes
# or environment variable
MCP_NUXT_ALLOW_WRITES=1 mcp-server-nuxt /path/to/app// in the client config
"env": { "MCP_NUXT_ALLOW_WRITES": "1" }Config edits touch only the affected lines. Comments and unrelated keys stay, and every change returns a diff you can review.
Dry-run first, check the diff, then enable writes.
Pull requests are welcome.
git clone https://github.com/<your-org>/mcp-server-nuxt.git
cd mcp-server-nuxt
npm install
npm run typecheck # tsc --noEmit (strict)
npm test # vitest
npm run build # tsupFollow Conventional Commits (feat:, fix:, chore:).
Add tests for new tools and resources under tests/.
Keep @nuxt/kit an optional dependency; each integration needs a fallback.
Write tools default to dry-run and go through WriteGuard.
MIT © 2026 mcp-server-nuxt contributors.
Add a Nuxt module to the modules array in nuxt.config, optionally with options. Returns a diff; dry-run by default.
Inputs: name (required), dryRun, options.
Scaffold a new page route under pages/ following Nuxt conventions. Supports static, dynamic (:id -> [id]), optional ([[id]]), and catch-all ([...slug]) segments.
Inputs: path (required), dryRun, layout, middleware.
Analyze package.json dependencies: classify Nuxt modules vs runtime/dev dependencies and surface warnings for misplaced or missing modules.
Inputs: no named parameters.
Run a TypeScript type check against .nuxt/tsconfig.json (or the project tsconfig.json) and return structured diagnostics with file, line, column, code and severity.
Inputs: no named parameters.
Generate a new Vue SFC under components/ with typed defineProps/defineEmits and slots.
Inputs: name (required), emits, props, slots, +1 more.
Read the .nuxt/imports.d.ts auto-imports registry: every auto-imported symbol with its source path and type signature. Requires the project to have been prepared/built. Use this instead of guessing import paths or function signatures.
Inputs: filter.
Get targeted offline Nuxt documentation guidance for a feature area (routing, nitro, modules, layers, composables, config, components).
Inputs: topic (required).
Get a high-level overview of the Nuxt project: root, name, Nuxt version, config file, directory layout, layer list, and counts of routes, components, composables, server routes, middleware, plugins and modules.
Inputs: no named parameters.
Get detailed information about a single page route by its resolved URL path (e.g. /users/:id).
Inputs: path (required).
Read generated Nuxt type information (.nuxt/imports.d.ts, .nuxt/types files and nuxt.schema.json) when the project has been built.
Inputs: no named parameters.
Get detailed information about a single component by its auto-imported name (e.g. BaseButton): props types, slots, emits, and script setup details.
Inputs: name (required).
Resolve and return the full Nuxt extends hierarchy (layers). Returns layers ordered by override priority (project first), with each layer's config file, raw extends, and sub-layers.
Inputs: no named parameters.
Inspect a single route: returns route params, middleware, layout, page meta plus the component props, emits and slots. Accepts a route path (e.g. /users/:id) or a page file path.
Inputs: path (required).
List all Vue components with their auto-imported names, file paths, props, emits and slots. Use this to discover existing UI building blocks before writing new code.
Inputs: name, directory.
List all composables, both auto-imported and explicit. Returns name, file path, parameters, and return type. Use this to discover reusable logic before writing new code.
Inputs: name.
List Nuxt modules discovered from nuxt.config and package.json, with version, status (active/inactive) and source. Use this to understand which Nuxt features are available.
Inputs: status.
List all page routes with their resolved URL paths, source files, params, middleware, layouts and children. Use this to understand the page/routing surface of the project.
Inputs: pattern.
List all Nitro server API routes, middleware, and plugins. Returns route path, handler file, HTTP method, and middleware chain. Use this to understand the server/API surface of the project.
Inputs: type.
Read the resolved Nuxt config, or a single key by dot-notation (e.g. runtimeConfig.public.apiBase). Omit the key to return the whole config.
Inputs: key.
Generate a new Nitro server API handler under server/api/ with H3 defineEventHandler and optional Zod body validation.
Inputs: path (required), zod, dryRun, method.
Search project source files for a substring or regex. Returns matching files with line/column numbers and surrounding context lines.
Inputs: query (required), fileTypes, maxResults.
Update a nuxt.config value by dot-notation key. Returns a diff of the change. Dry-run by default; real writes require the server to be started with write authorization.
Inputs: key (required), value (required), dryRun.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 22 tools
Most tools target a clearly distinct resource+action (list_routes vs list_components vs list_modules vs read_config), so an agent can pick correctly most of the time. The main overlap is get_route vs inspect_route_meta, which both resolve a route path and return params/middleware/layout plus component details, making the boundary between them fuzzy. get_type_info vs check_type_errors is a milder near-overlap but is distinguishable by read-vs-run semantics.
All names are snake_case and verb-first, which yields a predictable, readable pattern. There is minor verb drift for creation actions (add_route, generate_component, scaffold_nitro_api) and for inspection (get_ vs inspect_ vs read_), but nothing that breaks comprehension.
22 tools is on the heavy side, but each maps to a distinct surface of Nuxt work (routing, components, composables, Nitro, modules, config, types, docs, dependency analysis). The breadth justifies the count rather than feeling like redundancy, though trimming the route-inspection duplicates would tighten the set.
Coverage is strong on discovery and scaffolding (list/get/add for routes, components, composables, server routes, modules, config read/update), and there are diagnostics and docs helpers. However no delete/remove or edit operations exist for routes, components, composables, or modules, leaving dead ends after scaffolding, and there are no dedicated tools for middleware, plugins, or layouts as first-class resources.
Read and write KukGit repositories, files, issues and pull requests from an AI assistant.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Work on your own computers from Claude or ChatGPT: run commands, edit and search files.
