I'm currently having issues getting the correct types on the v4 alpha branch, it's not using the correct type for the Nuxt Content queryCollection. It seems like the fix it to add the newer tsconfig.json format as this provides the correct types in the IDE, however when running the typecheck command it returns errors.

 "references": [
    {
      "path": "./.nuxt/tsconfig.app.json"
    },
    {
      "path": "./.nuxt/tsconfig.server.json"
    },
    {
      "path": "./.nuxt/tsconfig.shared.json"
    },
    {
      "path": "./.nuxt/tsconfig.node.json"
    }
  ],
  // https://nuxt.com/docs/guide/concepts/typescript
  "files": []

I've currently marked areas where the code is correct with:
// @ts-expect-error TODO: This will be fixed when the tsconfig is setup correctly
You can also see a similar fix in the docs/server/routes/raw/[...slug].md.get.ts file.

npm i https://pkg.pr.new/@nuxt/ui@4878

commit: 1203669

@JosephAnson Hi Joseph, sorry I haven't had time to look at the PR in detail yet but from what little I've seen it looks really good! The focus right now is on releasing v4 of @nuxt/ui. So once it's released, I'll come and have a look at it in detail and lend a hand, because it was one of our focuses after v4 to make an MCP server!

Great news, sounds good to me, thanks @HugoRCD. For now I'll keep using it locally unless it's possible to have a test url related to this PR? I'll keep testing and making tweaks if anything can be improved.

Great news, sounds good to me, thanks @HugoRCD. For now I'll keep using it locally unless it's possible to have a test url related to this PR? I'll keep testing and making tweaks if anything can be improved.

Do you have good local results?

Locally it's working well, it's not necessary for a deployed dev url for it work, however it would save me running the dev server each time haha. Just trying to be lazy with it. Only problem I could see is you'll need to run the same version of Nuxt UI for it work correctly, as it'll always suggest the changes of the version it's deployed with.

Locally it's working well, it's not necessary for a deployed dev url for it work, however it would save me running the dev server each time haha. Just trying to be lazy with it. Only problem I could see is you'll need to run the same version of Nuxt UI for it work correctly, as it'll always suggest the changes of the version it's deployed with.

I was talking more about the quality of the ia's responses and whether there are still many hallucinations with it or not!

It's working great tbh, code refactors have been much better. Before generally it would try to use old versions of the components, wouldn't understand which v-models to bind, now it's checking directly. With the component meta lookup it's been pretty great, my initial plan was something external but haven't that additional info seems invaluable.

Additionally things like having upgrading to v4 for you automatically will work well once the migration guide is populated correctly, as there's a tool for that using the markdown helper used for the /raw endpoint.

I've attached some demo screenshots to the pr description for reference.

I'd like to drop the mcp-handler and redis dependency as the approach is outdated using SSE and instead use Streamable HTTP (see here: https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#streamable-http, following the guide here: https://github.com/modelcontextprotocol/typescript-sdk#without-session-management-stateless), it's quicker as you no longer need to use npx, it feels more responsive too. I have a commit ready, i'd like to push the change or would you rather me create a PR for this PR?

@JosephAnson Even better without the redis dependency 🎉

@JosephAnson I had a project a while back to implement AI search in the docs (#4114 (files)) but couldn't make it work with a RAG. Could this new MCP you implemented help us achieve this?

Tbh I'm not sure, it seems like what you've made should work provided that the embeddings are in the db, you can add the mcp tools to the AI streamText, that could help it make a better conclusion, I'll take a look this week. Not sure about the database instance now though, if you've moved hosting to vercel as https://hub.nuxt.com/docs/features/autorag seems to be only supported on cloudflare. You will need a storage option from vercel to store the embeddings.

Sorry for a last minute change, added a new tool called list_documentation_pages to list all the correct paths in the documentation as I noticed when get_content_page was called it would try an incorrect path sometimes, this would provide a solution for the ai to get the correct paths. Also renamed get_content_page to get_documentation_page as I feel that's more accurate.

Sure! Let me know when you think this is ready 😊

Doesn't this make the list_getting_started_guides tool useless now?

Sure! Let me know when you think this is ready 😊

Doesn't this make the list_getting_started_guides tool useless now?

I think it's ready now, at least enough to move ahead with as v1. That's a good point, I think it still serves a purpose as it's a direct access for a certain use case, same as the get_migration_guide. Although if you'd prefer we could remove it for now?

No we can keep it I was just wondering, maybe what we're missing is a list_composables then? 🤔

Yeah that's not a bad idea to add another tool for that, generally it's recommended to keep it as atomic as possible. So I think it's not a bad idea. I can also add it as a resource as well.

Ok I think we're all good to go, unless you see some issues that need fixing i'm happy to consider it ready. Only issue I could see is currently useFormField is returned by the list_composables tool and currently the documentation for it is set to navigation: false, should we also hide it from the results? It is possible to navigate to it via https://ui4.nuxt.com/docs/components/form#input-events however.

Regarding the useFormField composable we can leave it like this I guess, we'll have to document this page at some point anyway 😅

Thanks again @JosephAnson for the awesome work 💚

Somehow I completely missed this PR 😅

Just wanted to leave a couple of notes I've discovered while building MCP servers with various models, might come handy in future iterations:

• hallucinations come from a out-of-memory context issue, essentially how many tokens are required for the current inference. Which are usually distributed as (in order of higher token consumption and sooner hallucination)
  1. manually added resources (either via mcp server or local client)
  2. data returned by tools listing and calls
  3. conversation length (tho this can easily become no. 1 or 2)
  4. times an LLM need to call a tool (either local or remote)
  5. system and user prompts
• AI search (aka vector/semantic search) requires:
  • source data to be embedded and kept track for future embedding, like having an hash of the current doc page and the various examples shown in it (re-embedding everything on each build is just a waste of resources)
  • embedding the request that is coming from the user's search, then doing a vector search against our data and providing it to the user

I've solved the first one by creating detailed instructions (based on the project) and a small parser of the UI docs to extract relevant information (using the usage, examples, api and theme chapters we have in all components pages) and informing the LLM that it can in a single tool request get one or multiple chapters for one or multiple components. Here is an example of the tool I regularly use (both name, description and descriptions in the jsonSchema are equally important to let the LLM understand what to bet and what to expect), while here is the Nuxt UI doc parser to extract only relevant part (either by letting the LLM decide or directly asking to include/exclude something)

While for AI search it is something that I've stopped testing for now, as I did reach most of what I was looking for via MCP tools. I'm starting to think that a vector search is not that much useful in a docs website, or at least not when you have to factor in that most of the meaning (based on vector size) might be constructed from common symbols and common css classes throughout the documentation. But I might just be wrong.

@JosephAnson Do you have any links to your socials to share with us for the server release post?

@JosephAnson Do you have any links to your socials to share with us for the server release post?

Not sure which one you'd like to share, you can pick what you prefer:

Github: https://github.com/JosephAnson
Website: http://www.josephanson.com/
Linkedin: https://www.linkedin.com/in/josephanson/