mcp-server-nuxt
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_NUXT_ALLOW_WRITES | No | Set to "1" to enable the write tools (update_config, add_route, add_nuxt_module, scaffold_nitro_api, generate_component). Without it, write tools default to dry-run. Can also be enabled with the --allow-writes CLI flag. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_project_overviewA | 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. |
| get_type_infoA | Read generated Nuxt type information (.nuxt/imports.d.ts, .nuxt/types files and nuxt.schema.json) when the project has been built. |
| list_routesA | 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. |
| get_routeA | Get detailed information about a single page route by its resolved URL path (e.g. /users/:id). |
| add_routeB | Scaffold a new page route under pages/ following Nuxt conventions. Supports static, dynamic (:id -> [id]), optional ([[id]]), and catch-all ([...slug]) segments. |
| list_componentsA | 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. |
| inspect_componentA | Get detailed information about a single component by its auto-imported name (e.g. BaseButton): props types, slots, emits, and script setup details. |
| generate_componentC | Generate a new Vue SFC under components/ with typed defineProps/defineEmits and slots. |
| list_composablesA | 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. |
| get_auto_importsA | 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. |
| list_server_routesA | 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. |
| scaffold_nitro_apiB | Generate a new Nitro server API handler under server/api/ with H3 defineEventHandler and optional Zod body validation. |
| list_modulesA | 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. |
| add_nuxt_moduleA | Add a Nuxt module to the modules array in nuxt.config, optionally with options. Returns a diff; dry-run by default. |
| inspect_route_metaA | 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. |
| read_configA | 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. |
| update_configA | 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. |
| search_codeA | Search project source files for a substring or regex. Returns matching files with line/column numbers and surrounding context lines. |
| get_nuxt_docsB | Get targeted offline Nuxt documentation guidance for a feature area (routing, nitro, modules, layers, composables, config, components). |
| inspect_layersA | 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. |
| check_type_errorsA | 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. |
| analyze_bundle_depsA | Analyze package.json dependencies: classify Nuxt modules vs runtime/dev dependencies and surface warnings for misplaced or missing modules. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| project-overview | High-level overview of the Nuxt project structure and counts |
| project-routes | Full resolved route map with files, params, middleware and layouts |
| project-config | Current resolved Nuxt configuration object |
| project-modules | Installed Nuxt modules with status, source and configuration |
| project-layers | Resolved extends hierarchy with override priority order |
| project-auto-imports | Every auto-imported symbol with source path and type signature (from .nuxt/imports.d.ts) |
| project-types | Raw generated type info (.nuxt/imports.d.ts, .nuxt/types file list, nuxt.schema.json) |
TDQS
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.