| name | vite-mcp-next |
| description | Use when debugging Vite + Vue local pages with vite-plugin-vue-mcp-next MCP, including DOM, screenshots, console logs, network requests, Vue components, router, or Pinia state. |
vite-mcp-next
Overview
vite-mcp-next exposes local Vite + Vue runtime state through MCP. Use it before guessing from source code when the task asks to inspect a running page, verify UI, debug browser errors, trace requests, or inspect Vue app state.
When to Use
- User asks to inspect, open, verify, screenshot, or debug a local Vite/Vue page
- The answer depends on actual browser DOM, Console, Network, Vue component state, Router, or Pinia
- You need evidence from the running app before changing code
- You need to compare source expectations with runtime behavior
Do not use it for static code-only questions where reading files is enough.
Quick Reference
| Need | Tool |
|---|
| Find available pages and targets | list_pages |
| Inspect a copied element ID | get_element_context |
| Refresh the current page | reload_page |
| Inspect DOM structure | get_dom_tree |
| Find elements by selector | query_dom |
| Capture visual evidence | take_screenshot |
| Read browser logs | get_console_logs |
| Inspect one runtime console object argument | inspect_console_arg |
| Reset old browser logs | clear_console_logs |
| Inspect requests | get_network_requests |
| Inspect one request deeply | get_network_request_detail |
| Reset old request records | clear_network_requests |
| Inspect browser storage | list_storage, get_storage_item |
| Mutate browser storage | set_storage_item, delete_storage_item, clear_storage |
| Inspect Vue component tree | get_component_tree |
| Inspect one component state | get_component_state |
| Edit runtime component state | edit_component_state |
| Highlight a component | highlight_component |
| Inspect Vue Router | get_router_info |
| Inspect Pinia stores | get_pinia_tree, get_pinia_state |
| Evaluate page expression | evaluate_script |
Tool Order
- Call
list_pages first. Confirm the page, runtime connection, and any cdp:* target.
- If the user provides an
elementId such as src/App.vue:12:8, call get_element_context before editing source.
- For layout or content questions, call
get_dom_tree or query_dom.
- For visual verification, call
take_screenshot and report whether source is cdp or snapdom.
- For browser errors, call
get_console_logs; if a runtime Hook log contains an object argument with argId, call inspect_console_arg only when that object detail is needed.
- For API behavior, call
get_network_requests, then get_network_request_detail for the relevant id.
- For storage questions, call
list_storage first, then get_storage_item, set_storage_item, delete_storage_item, or clear_storage for the selected scope.
- For Vue-specific behavior, call
get_component_tree, get_component_state, get_router_info, get_pinia_tree, or get_pinia_state.
Channel Boundaries
- DOM, Console, Network, and Screenshot should use CDP when available.
- Without CDP, DOM, Console, Network, and same-origin storage fall back to Runtime Hook; screenshots fall back to snapdom.
- Cookie storage is CDP-only.
HttpOnly cookies can be read through CDP, but deletion and clear operations skip them.
- Vue component, Router, and Pinia tools always use Vue Runtime Bridge. Do not replace them with CDP DOM inspection when Vue semantic state is needed.
Risk Boundaries
evaluate_script is disabled unless the project sets runtime.evaluate.enabled: true.
- Prefer
evaluate_script for read-only diagnosis. Do not mutate page state unless the user asked for it.
edit_component_state mutates runtime Vue state. Use it only when state editing is the explicit goal.
get_element_context returns editable: false for third-party packages. Do not edit node_modules; modify project usage code instead.
- Storage mutation tools change browser state. Use them only when the user explicitly asks to write, delete, or clear storage.
- Network data can include token, cookie, or authorization values. Do not write sensitive values into source code, docs, commits, or final replies.
Failure Handling
- If
list_pages has no runtime page, ask the user to start or refresh the Vite page.
- If a CDP target is missing, use the runtime page tools instead of blocking.
- If screenshot fails, state whether the failure came from CDP or snapdom.
- If MCP is disconnected, ask the user to verify the Vite log URL ending in
/__mcp/sse or /__mcp/mcp.