BoilerplateHub

MCP Servers for Nuxt

Nuxt 3 and later rebuilt the framework on Vue 3, Vite, and Nitro, which means Nuxt 2 answers are not partially correct, they are entirely wrong. An agent needs to know that composables, components, and utils are auto-imported, that the server directory runs on Nitro with h3 helpers rather than Express, and that data fetching has to be SSR aware or the same request fires twice. Config lives in defineNuxtConfig and runtime values come from useRuntimeConfig, not from process.env at the point of use.

Wiring MCP into a Nuxt project

  • Commit .mcp.json so every contributor's agent has the same docs server available for Nuxt module APIs.
  • Wire the browser server to the dev server port your team actually uses, since Nuxt defaults to 3000 and collides with other tooling.
  • Keep credentials in env var references, as .mcp.json sits next to the Nuxt config in the same repo.

Servers worth adding

Filesystem MCP server

Scoped read and write access to the project tree.

Auto-import behaviour depends entirely on directory names, so an agent that can list composables/ and server/ stops guessing import paths.

Git MCP server

History, diffs, and blame for the repository.

The fastest way to confirm a project is on Nuxt 3 or later rather than mid-migration is to read the nuxt.config history.

Playwright MCP server

Browser automation against the running app.

Double fetching and hydration mismatches are only visible from the network panel of a real page load.

Context7 MCP server

Fetches current library and framework documentation into the agent's context.

Nuxt module APIs move faster than model training data, so pulling the current docs beats recalling a Nuxt 2 signature.

Skills, MCP and plugins compared →

Rule these out for Nuxt

These are the failures that repeat across sessions, so each one belongs in .mcp.json.

Calling $fetch directly in setup

Agents write a plain $fetch in a component setup block, which runs once during server render and then again on the client after hydration, doubling the load and often flashing different data. The composables exist specifically to dedupe that. Add to your rules file: 'Data fetched during setup uses useFetch or useAsyncData so the payload transfers from server to client. $fetch is only for event handlers and server routes.'

Emitting Nuxt 2 config and lifecycle code

asyncData, the component level fetch hook, the buildModules array, and @nuxtjs/axios all show up constantly because Nuxt 2 dominates older training data, and none of them work now. The failure is usually a silently ignored option rather than an error. State the version and add: 'Nuxt 3 or later. Config is defineNuxtConfig in nuxt.config.ts. Never use asyncData, the fetch hook, buildModules, or the Options API.'

Adding manual imports for auto-imported symbols

Agents import ref, computed, useRoute, or a project composable from a path they guessed at, because explicit imports feel safer. Nuxt already auto-imports from composables/, utils/, and Vue itself, so the guessed path is frequently wrong and the import is always redundant. Write: 'Do not import ref, computed, watch, Nuxt composables, or anything under composables/ and utils/. They are auto-imported. If a symbol appears unresolved, check the directory name rather than adding an import.'

Reading process.env inside components

An agent needing an API base URL reaches for process.env.API_URL in a component, which is undefined on the client and not tree-shaken safely on the server. Nuxt exposes configuration through runtimeConfig with a public section for browser-safe values and everything else server-only. Add: 'Runtime values come from useRuntimeConfig(). Anything the browser needs goes under runtimeConfig.public. Never read process.env outside nuxt.config.'

Writing Express style handlers in server/api

Nitro route files export a defineEventHandler and use h3 helpers like readBody, getQuery, and createError, but agents write (req, res) handlers with res.json and res.status because that is what a decade of Node training data looks like. State it directly: 'Every file in server/ exports defineEventHandler. Read input with readBody or getQuery, throw errors with createError, and return a plain object rather than calling res.'

Module level refs used as global state

For shared state an agent will export a const user = ref(null) from a composable file. On the client that is fine, but on the server that module is shared across requests, so one visitor's data can leak into another's render. Nuxt provides useState precisely for SSR-safe shared state. Add: 'Cross-component state uses useState with a stable key, or a Pinia store. Never export a module level ref or reactive object as shared state.'

Same framework, other agents