I think we all love Nuxt. One problem with using Nuxt for AI is that training data is not up to date. This is especially true for Nuxt Content where often times LLMs still think they’re working with Nuxt 2. This is why the Nuxt team created their MCP server.
I think the MCP is good and perfectly fine. But for me—and also for Anthropic itself—MCPs in the current spec have the problem of context bloat. Anthropic has written down this problem perfectly in their engineering blog.
💡The Context Bloat Problem
Anthropic identifies two main issues: tool definition overload (loading all tools upfront creates hundreds of thousands of tokens before the model even reads your request) and intermediate result redundancy (every result must pass through the model, sometimes processing 50,000+ tokens per operation).
If you want to dive deeper into what MCP is and how it works, check out my post on What Is the Model Context Protocol (MCP)?What Is the Model Context Protocol (MCP)? How It WorksLearn how MCP (Model Context Protocol) standardizes AI tool integration, enabling LLMs to interact with external services, databases, and APIs through a universal protocol similar to USB-C for AI applications.mcptypescriptai.
Why I Use Custom Research Agents Instead#
This is why for all my projects I don’t use MCP but I use custom research agents.
All websites nowadays use llms.txt. Now if you let an LLM fetch llms.txt first, it can perfectly find every information needed from the docs itself.
I’ve written about how I added llms.txt to my own blogHow I Added llms.txt to My Astro BlogI built a simple way to load my blog content into any LLM with one click. This post shows how you can do it too.astroai—it’s becoming a standard way for sites to expose their content to AI.
This approach has several advantages:
- Only the description gets loaded as context — The agent description is minimal, not the entire tool schema
- You can customize it — Full control over what the agent knows and how it behaves
- It runs in its own context — Your main agent could use the research agent only to gather information and then continue with its work without polluting its context window
This is essentially the same pattern I described in my post about Claude Code subagentsClaude Code Customization Guide (2026): CLAUDE.md vs Skills vs SubagentsWhen should you use CLAUDE.md, a slash command, a skill, or a subagent in Claude Code? A decision guide with real examples for each, so you stop guessing which one fits the job.claude-codeaitooling+1 — agents keep your main context clean by delegating specialized tasks.
💪Claude Code Uses This Pattern Too
Claude Code itself uses this exact approach. When you ask it questions about its own features, it spawns a claude-code-guide agent that fetches from a documentation sitemap and answers based on current docs—not training data. We’re just applying the same pattern to other libraries.
Example: Nuxt Content Specialist Agent#
Here’s how my Nuxt Content agent looks. Just put it under .claude/agents:
Key Design Principles#
The agent follows these principles:
- Documentation-first: Always fetch
llms.txtbefore answering anything - Specific expertise: Focused on Nuxt Content v3, not general Nuxt knowledge
- Verification: Cross-reference documentation, don’t rely on training data
- Practical output: TypeScript code following project conventions
How It Works in Practice#
When you ask Claude Code something like “How do hooks work in Nuxt Content?”, the main agent recognizes this matches the nuxt-content-specialist description and delegates to it.
The specialist agent then:
- Fetches
https://content.nuxt.com/llms.txt - Identifies the relevant documentation pages
- Fetches the actual docs
- Provides an accurate, up-to-date answer
Your main context stays clean. The research happens in a separate context window.
Create Your Own#
You can apply this pattern to any library or framework:
- Find if they have
llms.txt(most modern docs sites do) - Create an agent that fetches it first
- Define the expertise scope in the description
- Add examples so Claude Code knows when to delegate
This approach gives you 98%+ reduction in token usage compared to loading full MCP tool definitions, while maintaining access to current documentation.
