nanostores_clear_cache
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.
Index every Nanostores store, subscriber and derived relation in a project, then compare that graph against what the running app actually emits.
LABSCO SUMMARY
nanostores_store_impact opens by telling the caller not to run nanostores_store_summary on each downstream store, and nanostores_store_subgraph opens by redirecting downstream-only questions back to nanostores_store_impact — the surface is written to keep an agent from fanning out into a call per store. Another design decision worth knowing is that the static index and the runtime stream are genuinely separate, and nanostores_runtime_coverage exists because they disagree: a store defined but never observed may be dead code or may just be untested, and a store observed but unindexed means the scan missed something dynamic. Results are cached, so nanostores_clear_cache and force:true are what you reach for when the answers stop matching the files.
A Nanostores code-intelligence server built on a cached static index of stores, subscribers and relations read from the project source, alongside a runtime event stream from a logger bridge in the running app.
The project to index: set NANOSTORES_MCP_ROOT to its path, or leave it unset where the editor supplies the workspace (VS Code sets WORKSPACE_FOLDER), and otherwise the server uses the directory it was started in. The activity, noisy-store, overview and coverage tools additionally need the app running with its logger bridge connected — nanostores_ping is what reports whether that bridge is up.
One command — npx -y nanostores-mcp
USE CASES
Ask once for the ordered downstream chain, widen to the upstream side only when the change depends on where the value came from, and open the individual store the chain implicates.
Rank stores by how much they are actually moving in the running app, then open the noisiest one to see which actions are driving it and whether it is erroring.
Start with the shape of the project rather than the full index, then pull the complete list once you know which corner of it matters.
Exercise the app, then set the static index against what the runtime actually emitted to find stores nothing ever touched and stores the scan never saw.
Search the documentation by topic or by the kind of store you are reaching for, and open the page in full when the excerpt is not enough.
Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.
nanostores_clear_cacheUse 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_docs_searchFind 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"}.
nanostores_find_noisy_storesUse 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_pingUse this when you need to verify the MCP server is alive or check whether the runtime logger bridge is connected.
nanostores_project_outlineUse 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_runtime_coverageCompare 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_runtime_overviewUse 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_scan_projectReturns 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_activityUse 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_store_impactWhen 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_store_subgraphIf 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_summaryUse 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"}.
BEFORE YOU INSTALL
12 tools when we connected. Nothing writes: every tool reads, analyses or clears a cache.
npx on PATH
All 6 documented clients run the server on your machine.
CONTEXT COST
Rated by the size of the 12 tool definitions that ride along on every turn, not by how many there are
INSTALLATION
npx -y nanostores-mcp{
"mcpServers": {
"nanostores": {
"command": "npx",
"args": [
"-y",
"nanostores-mcp"
],
"env": {
"NANOSTORES_MCP_ROOT": "<YOUR_NANOSTORES_MCP_ROOT>"
}
}
}
}{
"servers": {
"nanostores": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"nanostores-mcp"
]
}
}
}{
"mcpServers": {
"nanostores": {
"command": "npx",
"args": [
"-y",
"nanostores-mcp"
]
}
}
}{
"context_servers": {
"nanostores": {
"command": "npx",
"args": [
"-y",
"nanostores-mcp"
],
"env": {
"NANOSTORES_MCP_ROOT": "<YOUR_NANOSTORES_MCP_ROOT>"
}
}
}
}