Nanostores MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WORKSPACE_FOLDER | No | Alias for NANOSTORES_MCP_ROOT — set automatically by VS Code and some editors | |
| NANOSTORES_MCP_ROOT | No | Project root path | cwd |
| NANOSTORES_DOCS_ROOT | No | Path to documentation directory | |
| NANOSTORES_MCP_ROOTS | No | Platform-delimited roots (':' on Unix, ';' on Windows) for multi-project setup | |
| WORKSPACE_FOLDER_PATHS | No | Alias for NANOSTORES_MCP_ROOTS — set automatically by some editors | |
| NANOSTORES_DOCS_PATTERNS | No | Comma-separated glob patterns for docs | **/*.md |
| NANOSTORES_MCP_LOGGER_HOST | No | Host to bind. Allowed values: 127.0.0.1, localhost, ::1 | 127.0.0.1 |
| NANOSTORES_MCP_LOGGER_PORT | No | HTTP port for logger bridge | 3999 |
| NANOSTORES_MCP_LOGGER_ENABLED | No | Set to false or 0 to disable runtime event collection and the logger bridge | true |
Capabilities
Features and capabilities supported by this server
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| nanostores_scan_projectA | Returns the complete store/subscriber/relation index for the project. Use compact:true for a token-efficient directory-level overview (store counts by folder). Use the full mode (default) when you need to iterate over every entity or build a complete picture. Example: {compact: true} for directory overview, {force: true} to bypass cache. |
| nanostores_store_summaryA | Use this when you need details about a specific store — its kind, file location, direct subscribers, and first-level derived relations. Accepts store id or name. For multi-hop dependency chains use nanostores_store_subgraph instead. Example: {name: "$counter"} or {storeId: "store:src/stores.ts#$counter"}. |
| nanostores_clear_cacheA | Use this when scan results seem stale or after making file changes that the server may not have detected. Clears the cached project index so the next nanostores_scan_project call performs a fresh scan. |
| nanostores_project_outlineA | Use this for a quick overview of Nanostores usage in the project — store kind distribution, top directories, and hub stores ranked by connectivity. Returns a compact summary instead of full store/subscriber lists (same scan data, smaller response). Use nanostores_scan_project when you need the complete list of stores and relations. |
| nanostores_store_subgraphA | If your question is 'what recomputes downstream when X changes?', use nanostores_store_impact instead — it gives the ordered causal chain in one call. Use this tool only when you need both directions: upstream sources AND downstream dependents together. Returns the BFS neighborhood within a configurable radius (default 2). Start with radius=1; increase only when you need wider structural context. On highly connected hub stores (score>5 in project_outline) radius=2+ may return most of the project. Example: {name: "$cart", radius: 1} or {storeId: "store:src/stores.ts#$cart", radius: 2}. |
| nanostores_store_impactA | When you need to trace what recomputes if X changes, call this once — not nanostores_store_summary on each downstream store. Returns the full ordered downstream chain in a single response: computed stores that depend on X at hop 1, their dependents at hop 2, and so on. Subscribers appear at the same hop as the store they react to. Use nanostores_store_subgraph instead when you also need upstream ancestors (BFS in both directions). Example: {name: "$isLoggedIn"} returns every computed store and subscriber that recomputes when $isLoggedIn changes, ordered by distance. |
| nanostores_pingA | Use this when you need to verify the MCP server is alive or check whether the runtime logger bridge is connected. |
| nanostores_store_activityA | Use this when debugging a specific store's runtime behavior — why it updates too often, what actions trigger changes, or whether it emits errors. Returns recent events, change frequency, action calls, and errors. Omit storeName to get activity across all stores. Example: {storeName: "$cart", kinds: ["change", "action-error"]} or {limit: 20, windowMs: 60000}. |
| nanostores_find_noisy_storesA | Use this when investigating performance issues or excessive re-renders. Returns stores ranked by activity — frequent changes, many action calls — to pinpoint bottlenecks. Example: {limit: 10} or {windowMs: 30000, compact: true}. |
| nanostores_runtime_overviewA | Use this when you want a high-level health check of the running app's state management. Returns active stores, error-prone stores, unused stores, and activity patterns. Example: {} or {windowMs: 60000, compact: true}. |
| nanostores_runtime_coverageA | Compare static analysis graph with runtime event data to find stores declared in the static graph but not observed in this runtime session, and stores seen at runtime but absent from the static graph (dynamic or unscanned). Use after running the app to verify instrumentation completeness. Example: {} or {projectRoot: "/path/to/project"}. |
| nanostores_docs_searchA | Find Nanostores documentation by topic or store kind. Use query for free-text search across guides, API references, and best practices. Use storeKind to get docs relevant to a specific store type (atom, map, computed, etc.). Combine both to search within store-relevant pages. To read full page content, use the nanostores://docs/page/{id} resource. Example: {query: "persistent storage"} or {storeKind: "computed"} or {query: "batched", storeKind: "computed"}. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| explain-project | High-level explanation of how Nanostores is used in the current project, based on nanostores://graph. |
| explain-store | Explain what a Nanostores store does, how it is used, and how it fits into the project. |
| debug-store | Analyze a Nanostores store by combining static code analysis (AST graph) with runtime behavior (@nanostores/logger events). Find anti-patterns, performance issues, and suggest refactoring. |
| debug-project-activity | Analyze runtime behavior across all Nanostores in the project to find hot spots, error patterns, unused stores, and optimization opportunities. |
| docs-how-to | Get step-by-step guidance on accomplishing specific tasks with Nanostores, backed by official documentation. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| graph | Graph of Nanostores stores and subscribers (components/hooks/effects) in the current workspace. |
Latest Blog Posts
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Valyay/nanostores-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server