[Feature Request] Make the v0 docs WebMCP-consumable (agent-navigable)
@johnleider is already working on this.
Since Jul 8, 2026.
- Dominant language
- TypeScript
- Stars
- 735
- Forks
- 10
- Avg merge
- 10h 47m
- Merged PRs (30d)
- 72
Description
Idea
Have the v0 docs site register WebMCP tools via navigator.modelContext.registerTool so an in-browser AI agent can drive the docs through structured, typed tool calls instead of screenshot-and-guess scraping.
Scope is deliberately the docs app only — not a first-party @vuetify/v0 API. Blast radius is one app, zero commitment in the shipped package.
Why the docs are the right place
- The data is already structured — search index, component/composable catalog, API metadata (the same schemas ApiPopover/Vuetify MCP already serve). Registering tools is a few
registerToolcalls, feature-detected so it's a no-op off supporting browsers. - Real dogfood + a clean differentiator: "first Vue library docs a browser agent can actually navigate." Useful launch-narrative seasoning.
- Doubles as living documentation of WebMCP — the docs demonstrate the pattern by using it.
Candidate tools
search-docs(query)— over the existing search indexopen-guide(name)— navigate to a component/composable pagelist-composables(category?)/list-components(category?)— the catalog behind the decision tableget-api(name)— return the API schema already served via ApiPopover/MCPfilter-by-skill-level(level)— the existing skill-level filterrun-example(id, props)— drive an interactive example live
Two flavors (not exclusive)
- Instrument the real docs (agent-navigable) — start with
search-docs+open-guide, the highest-value pair. - Dedicated WebMCP demo/example page — teaches the pattern with a v0 example; safest sandbox, and the natural home for documenting the feature.
Folds in existing docs follow-ups — search, skill-level filter, bookmarks become the backing actions the tools call.
Recommendation
Start with flavor 2 (a demo/example page): proves the API, documents it, risks nothing. Graduate to instrumenting real search + navigate once it feels solid.
Reference — WebMCP API shape
const controller = new AbortController()
await navigator.modelContext.registerTool({
name: 'search-docs',
description: 'Search the v0 documentation',
inputSchema: { type: 'object', properties: { query: { type: 'string' } }, required: ['query'] },
async execute ({ query }) {
const results = await searchIndex(query)
return { content: [{ type: 'text', text: JSON.stringify(results) }] }
},
}, { signal: controller.signal }) // controller.abort() unregisters
Caveats (as of 2026-07)
- Origin-trial only, Chrome-first (Angular has experimental support; Firefox/Safari uncommitted). Gate everything behind feature detection.
- API not finalized — sources disagree on
document.vsnavigator.modelContext;getTools/executeToolstill TODO in the spec. Keep the integration thin and centralized so a rename is a one-line change.
Next step
Check what the docs search/router actually expose, then scope the demo page.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.