Nanostores MCP
Provides static analysis for Angular projects using Nanostores, including DI support for @nanostores/angular NanostoresService constructor injections and detection of this.nanostores.useStore(...) call patterns in TypeScript component files.
Integrates with Windsurf (Codeium's IDE) to provide Nanostores analysis tools through the MCP interface, accessible via the Cascade panel.
Makes Nanostores analysis tools available in VS Code through GitHub Copilot's Agent mode, enabling AI-assisted store architecture analysis and debugging.
Supports static analysis for Lit projects using Nanostores as part of the framework-agnostic approach to store inspection and subscriber detection.
Generates dependency graph visualizations (Mermaid diagrams) showing how Nanostores depend on each other as part of the static analysis capabilities.
Provides comprehensive analysis, debugging, and monitoring capabilities for Nanostores projects including AST-based scanning, runtime monitoring with @nanostores/logger integration, and documentation search.
Required runtime environment for the MCP server with specific version requirements (Node.js ^20.0.0 || >=22.0.0) to execute Nanostores analysis tools.
Package manager used for installing the nanostores-mcp server and its dependencies, including required peer dependencies like nanostores itself.
Alternative package manager option for installing the nanostores-mcp server alongside npm.
Supports static analysis for Preact projects using Nanostores as part of the framework-agnostic approach to store inspection and subscriber detection.
Provides framework-aware subscriber detection for React projects using Nanostores, recognizing component bindings and store usage patterns.
Supports static analysis for SolidJS projects using Nanostores as part of the framework-agnostic approach to store inspection and subscriber detection.
Provides specialized static analysis for Svelte projects using Nanostores, including parsing of script blocks, auto-subscription detection ($storeName in templates), and filtering of Svelte 5 runes to avoid false positives.
Nano Stores MCP
Model Context Protocol server for Nanostores — analyze, debug and monitor your nanostores in AI assistants like Claude Desktop.
📊 Static Analysis: AST-based project scanning, dependency graphs, store inspection
🔥 Runtime Monitoring: Live events from
@nanostores/logger, performance metrics, activity tracking📚 Documentation: Search and browse Nanostores docs by topic or store kind
🎯 Zero Config: Works out of the box — auto-detects project roots and nanostores docs
🌐 Framework-Agnostic: Works with React, Vue, Svelte, Angular, Solid, Preact, Lit — any framework that uses Nanostores
npx nanostores-mcpAsk your AI: "Analyze my store architecture" or "Which stores update most frequently?"
Made at Evil Martians, product consulting for developer tools.
Table of Contents
Related MCP server: forgekit-storybook-mcp
Features
📊 Static Analysis (AST-based)
Understand your nanostores architecture without running your app:
Project scanning — find all stores, subscribers, and import/export relationships
Dependency graph — visualize how stores depend on each other (Mermaid diagrams)
Store inspection — type (atom/map/computed/batched/persistentAtom/persistentMap/router), location, usage patterns, related files
Framework-aware subscriber detection — recognizes
.subscribe()/.listen()calls and component bindings across React, Vue, Svelte, and AngularVue SFC support — parses both
<script>and<script setup>blocks in.vuefiles (requires@vue/compiler-sfc)Svelte support — parses
<script context="module">and instance<script>blocks, auto-subscriptions ($storeNamein templates), and filters out Svelte 5 runes ($state,$derived,$effect, etc.) so they are not mistaken for store references (requiressvelte)Angular DI support — resolves
@nanostores/angularNanostoresServiceconstructor injections and detectsthis.nanostores.useStore(...)call patterns in TypeScript component files
🔥 Runtime Monitoring (Logger Integration)
Real-time insights into your running application:
Live event capture — mount/unmount, value changes, action calls from
@nanostores/loggerPerformance analysis — find noisy stores, high error rates, performance bottlenecks
Activity metrics — change frequency, action success/failure rates, action duration
Combined analysis — merge static structure with runtime behavior for deep debugging
📚 Documentation Search
Search and browse Nanostores documentation directly from your AI assistant:
Full-text search — find guides, API references, and best practices by query
Store-kind lookup — get docs relevant to a specific store type (atom, map, computed, etc.)
Auto-detection — picks up docs from
nanostoresin yournode_modulesautomatically
Requirements
Requirement | Version |
Node.js |
|
Required peer dependency (for static analysis):
npm install nanostoresOptional peer dependencies — install only if you use the corresponding file format:
Package | When needed |
| Vue SFC ( |
| Svelte ( |
| Runtime monitoring ( |
Without these optional packages the server still works — it silently skips unsupported file types.
Installation
npm install -g nanostores-mcp
# or
pnpm add -g nanostores-mcpOr run directly without installation:
npx nanostores-mcpConfiguration
Claude Desktop
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"nanostores": {
"command": "npx",
"args": ["-y", "nanostores-mcp"],
"env": {
"NANOSTORES_MCP_ROOT": "/path/to/your/project"
}
}
}
}VS Code
Requires GitHub Copilot extension (VS Code 1.99+). Create .vscode/mcp.json in your project:
{
"servers": {
"nanostores": {
"type": "stdio",
"command": "npx",
"args": ["-y", "nanostores-mcp"]
}
}
}Tools are available in Copilot's Agent mode (select "Agent" in the Copilot Chat dropdown).
Cursor
Create .cursor/mcp.json in your project root (or ~/.cursor/mcp.json for global):
{
"mcpServers": {
"nanostores": {
"command": "npx",
"args": ["-y", "nanostores-mcp"]
}
}
}Zed
Add to your Zed settings.json:
{
"context_servers": {
"nanostores": {
"command": "npx",
"args": ["-y", "nanostores-mcp"],
"env": {
"NANOSTORES_MCP_ROOT": "/path/to/your/project"
}
}
}
}The server appears in Zed's Agent Panel settings.
Windsurf
Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"nanostores": {
"command": "npx",
"args": ["-y", "nanostores-mcp"],
"env": {
"NANOSTORES_MCP_ROOT": "/path/to/your/project"
}
}
}
}You can also open this file from the MCP icon in the Cascade panel → "Configure".
Claude Code
Add via CLI:
claude mcp add --transport stdio nanostores -- npx -y nanostores-mcpOr create .mcp.json in your project root (shared with the team):
{
"mcpServers": {
"nanostores": {
"command": "npx",
"args": ["-y", "nanostores-mcp"],
"env": {
"NANOSTORES_MCP_ROOT": "/path/to/your/project"
}
}
}
}Environment Variables
Variable | Default | Description |
| cwd | Project root path |
| — | Platform-delimited roots ( |
| — | Alias for |
| — | Alias for |
|
| Set to |
|
| HTTP port for logger bridge |
|
| Host to bind. Allowed values: |
| auto-detect | Path to documentation directory |
|
| Comma-separated glob patterns for docs |
How the Project Root Is Resolved
The server picks workspace roots in priority order:
Environment variables (highest priority) —
NANOSTORES_MCP_ROOTS/NANOSTORES_MCP_ROOT/WORKSPACE_FOLDER_PATHS/WORKSPACE_FOLDERClient roots — roots reported by the MCP client via the
roots/listcapability (set automatically by some editors)Current working directory —
process.cwd()used as fallback when neither env nor client roots are configured
When a tool is called without an explicit projectRoot argument the server uses the first configured root. In a multi-root setup always pass projectRoot to avoid ambiguity.
Quick Start
1. Static Analysis
Works out of the box — just point at your project and ask:
"Analyze my store architecture"
"Explain how nanostores is used in this project"
"Give me a summary of the $cart store"
"My stores changed — re-scan the project" ← the AI will force a fresh scan
2. Documentation Search
Auto-detected from nanostores in your node_modules:
"How do I use computed stores?"
"Show me the docs for persistentAtom"
3. Runtime Monitoring (Optional)
Requires logger integration in your app. See Runtime Monitoring below.
"Which stores update most frequently?"
"Show me recent activity for $user"
"Give me an overall health report"
Verify Your Setup
Run these four tools in order to confirm everything is working:
nanostores_ping → should return server status and logger bridge state
nanostores_scan_project → should list your stores and subscribers
nanostores_docs_search → should return documentation results (requires nanostores in node_modules)
nanostores_runtime_overview → should return overview (or "no runtime data" if logger is disabled — that's fine)If nanostores_scan_project returns zero stores, check that NANOSTORES_MCP_ROOT points to the correct project directory.
MCP Interface
MCP Resources
Resource | Description |
| Full dependency graph (text + Mermaid) |
| Store details by name or id |
| Documentation index — all pages and tags |
| Full content of a documentation page |
MCP Tools
Static Analysis
Tool | Description |
| Scan project for all stores, subscribers, and dependencies |
| Detailed summary of a specific store |
| High-level overview: store kinds, top directories, hub stores |
| BFS-expanded dependency neighborhood of a store |
| Downstream causal chain — what recomputes/re-renders if X changes |
Runtime Monitoring
Tool | Description |
| Overall health report with statistics for all stores |
| Activity timeline for a specific store (filterable by kind/action) |
| Identify stores with high change frequency or error rates |
| Compare static graph with runtime events to find coverage gaps |
Documentation
Tool | Description |
| Search docs by |
Use nanostores://docs/page/{id} resource to read the full content of pages returned by search.
Utilities
Tool | Description |
| Server health check and logger bridge status |
| Clear project index cache to force rescan |
MCP Prompts
Prompt | Parameters | Description |
|
| AI-guided explanation of your project's store architecture. |
|
| Deep dive into a specific store's implementation and usage |
|
| Comprehensive analysis combining static + runtime data |
| — | Project-wide performance analysis and optimization |
|
| Step-by-step guidance for a Nanostores task, backed by docs (e.g. |
Advanced Tool Arguments
Most tools accept these optional arguments that significantly change their behavior:
Argument | Type | Used in | Description |
|
|
| Exact store identifier — format: |
|
|
| Store name (e.g. |
|
|
| BFS hops around the store. |
|
| most tools | Which project root to analyze in multi-root setups. Omit to use the first configured root. Always specify this in multi-root projects. |
|
|
| Look-back window in milliseconds (e.g. |
|
|
| Filter events by type. Values: |
|
|
| Filter events to a specific action (e.g. |
|
|
| Return a compressed token-efficient table instead of full text. Useful for large projects to reduce context usage. |
Runtime Monitoring
For runtime analysis, integrate the MCP Logger client into your application.
1. Install in your app and enable the logger bridge:
npm install nanostores-mcpThe logger bridge starts automatically — no extra config needed. To disable it, set NANOSTORES_MCP_LOGGER_ENABLED=false in your MCP server config.
2. Define stores with logger attached (src/stores.ts):
import { atom, map, computed } from "nanostores";
import { initMcpLogger, attachMcpLogger } from "nanostores-mcp/mcpLogger";
// Automatically disabled in production (checks NODE_ENV / import.meta.env.DEV)
initMcpLogger();
// Stores
export const $count = atom(0);
export const $user = map({ name: "", role: "guest" });
export const $greeting = computed($user, user => `Hello, ${user.name}`);
// Attach logger — each call returns a cleanup function
attachMcpLogger($count, "$count");
attachMcpLogger($user, "$user");
attachMcpLogger($greeting, "$greeting");3. Use stores normally — events (mount, unmount, change, actions) are captured automatically and batched to the MCP server every second.
4. Ask your AI assistant:
"Which stores change most frequently?" →
nanostores_find_noisy_stores"Show me recent activity for $user" →
nanostores_store_activity"Give me an overall health report" →
nanostores_runtime_overview
Logger Options
initMcpLogger({
url: "http://127.0.0.1:3999/nanostores-logger", // default; change if using a custom port
batchMs: 1000, // default; lower for faster delivery (e.g. 200)
projectRoot: "/absolute/path/to/project", // link runtime events with static analysis
// Mask sensitive data — return null to skip event entirely
maskEvent: event => {
if (event.storeName === "authToken") return null;
return event;
},
});Flush Before Shutdown
import { getMcpLogger } from "nanostores-mcp/mcpLogger";
window.addEventListener("beforeunload", async () => {
await getMcpLogger()?.forceFlush();
});Reading Results
nanostores_runtime_overview health summary
The overview groups stores into three categories:
Top active stores — sorted by total event count (changes + actions). A store that appears here with hundreds of changes in seconds may be a performance concern.
Error-prone stores — stores with
action-errorevents. High error counts indicate failing async actions.Unmounted stores — stores seen at mount but never unmounted. May indicate memory leaks.
nanostores_runtime_coverage
Compares your static store graph against observed runtime events:
Term | Meaning |
static-only | Store found by AST scan but no runtime events observed. Possible dead code, deferred initialization, or missing |
runtime-only | Events received for a store not found by the scanner. Common for dynamically-created stores, factory patterns, or stores in |
Coverage by kind | E.g. |
nanostores_find_noisy_stores
Returns stores ranked by total activity (changes + actions combined) within the windowMs period. A store is considered "noisy" when its change frequency is disproportionately high relative to visible UI updates — use this to find re-render hotspots or thrashing computed chains.
Privacy & Security
The runtime logger is designed to stay on your local machine:
Loopback-only binding — the HTTP bridge accepts connections exclusively from
127.0.0.1,localhost, or::1. Binding to0.0.0.0is explicitly blocked. Data never leaves your machine.What is transmitted — from your app to the MCP server over localhost: store name, timestamp, event kind, and optionally value snapshots (truncated to 200 characters). Nothing is sent to Anthropic or any third party.
Nothing is persisted — events are held in a ring buffer (5 000 events max) in process memory and discarded when the server restarts.
Mask sensitive data — use
maskEventto filter or redact events client-side before they are batched and sent:
initMcpLogger({
maskEvent: event => {
if (event.storeName === "$authToken") return null; // drop entirely
if (event.storeName === "$paymentInfo") return { ...event, newValue: undefined }; // strip value
return event;
},
});CORS — the bridge rejects cross-origin requests from non-loopback origins.
Example Queries
Ask your AI assistant natural language questions:
Static Analysis:
"Analyze my store architecture for potential issues"
"What happens when $user changes? Show subscribers and derived stores"
Runtime Debugging:
"Which stores update most frequently?"
"Are there stores declared in code but never used at runtime?"
"Debug the $user store — combine static analysis with runtime behavior"
With Playwright MCP:
"Open my app in the browser, interact with it, and analyze which stores cause the most recalculations"
Documentation:
"How do I use computed stores?"
"Show me best practices for persistent stores"
Architecture
┌──────────────────────┐
│ Your Application │
│ │
│ @nanostores/logger │
│ events │
└──────────┬───────────┘
│ HTTP POST (localhost:3999)
▼
┌──────────────────────┐
│ nanostores-mcp │
│ │
│ ┌──────────────┐ │
│ │ Logger Bridge │ │ ← HTTP server for runtime events
│ └──────┬───────┘ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Event Store │ │ ← Ring buffer (5000 events) + stats
│ └──────┬───────┘ │
│ │ │
│ ┌──────┴───────┐ │
│ │ AST Scanner │ │ ← ts-morph static analysis
│ └──────┬───────┘ │
│ │ │
│ ┌──────┴───────┐ │
│ │ Docs Index │ │ ← Auto-detected from node_modules
│ └──────┬───────┘ │
│ │ │
│ ┌──────┴───────┐ │
│ │ MCP Interface│ │ ← Resources, Tools, Prompts
│ └──────────────┘ │
└──────────┬───────────┘
│ MCP Protocol (stdio)
▼
┌──────────────────────┐
│ LLM Client │
│ (Claude, VS Code, …) │
└──────────────────────┘Limitations & Caveats
Multi-root: same store name in multiple projects
In multi-root mode a store named $user can exist in two different projects. The runtime event store uses a composite key (projectRoot + storeName) to keep them separate, but summary views may show the same name twice with no project label. Always specify projectRoot when querying tools in a multi-root setup to get unambiguous results.
Static analysis only covers discovered files
The AST scanner follows TypeScript/JavaScript imports from your project root. Stores created dynamically at runtime, generated by factories, or living in node_modules will not appear in static results — they may show up as "runtime-only" in coverage reports.
Vue and Svelte parsing requires optional dependencies
If @vue/compiler-sfc or svelte are not installed, .vue / .svelte files are silently skipped during scanning. Install them as dev dependencies if you want full coverage for those file types.
Event ring buffer is capped at 5 000 events
Older events are dropped when the buffer is full. For high-frequency stores use windowMs to narrow your queries to recent data, or lower batchMs in initMcpLogger to deliver events more frequently and reduce the chance of buffer overflow during bursts.
radius on hub stores can be very large
Stores with many dependencies (hub score > 5) can return most of the project graph at radius=2. Start with radius=1 and increase only if you need broader context.
Development
git clone https://github.com/Valyay/nanostores-mcp.git
cd nanostores-mcp
pnpm install
pnpm dev # Run dev server
pnpm build # TypeScript compile
pnpm test # Run vitest
pnpm lint # ESLint
pnpm check # All checks: lint + format + test + build
# Test with MCP Inspector
npx @modelcontextprotocol/inspector pnpm run devTroubleshooting
Logger not receiving events:
Use the
pingtool to verify logger bridge is enabled and runningCheck browser console for
[nanostores-mcp]warnings about connection issuesConfirm the port matches between server (
NANOSTORES_MCP_LOGGER_PORT) and client URLTest with a simple atom store to verify events flow
Port conflicts:
# Change server port
NANOSTORES_MCP_LOGGER_PORT=4000 npx nanostores-mcp
# Update client
initMcpLogger({ url: "http://127.0.0.1:4000/nanostores-logger" });TypeScript errors:
// Import from the mcpLogger subpath export
import { initMcpLogger, attachMcpLogger } from "nanostores-mcp/mcpLogger";Documentation not found:
The server auto-detects docs from
nanostoresin yournode_modulesMake sure
nanostoresis installed:npm install nanostoresOr set
NANOSTORES_DOCS_ROOTto point at a docs directory manually
Related Projects
Nanostores ecosystem:
nanostores — Tiny state manager (atom, map, computed, batched, deepMap)
@nanostores/logger — Logger and action system
@nanostores/persistent — Persistent stores (localStorage, sessionStorage)
@nanostores/router — SPA router
@nanostores/i18n — Internationalization
@nanostores/react, @nanostores/vue, @nanostores/preact, @nanostores/solid, @nanostores/lit — Framework bindings
MCP:
Model Context Protocol — MCP specification
Playwright MCP — Browser automation (works with nanostores-mcp for runtime analysis)
License
MIT
Contributing
Contributions are welcome! Please open an issue or PR.
Available Tools
12 toolsnanostores_clear_cacheClear project analysis cacheAIdempotent
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.
Inputs: rootUri.
nanostores_docs_searchSearch Nanostores documentationARead-onlyIdempotent
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"}.
Inputs: query, storeKind, limit, tags. Returns: query, storeKind, results
nanostores_find_noisy_storesFind noisy storesARead-onlyIdempotent
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}.
Inputs: limit, windowMs, compact. Returns: stores, summary
nanostores_pingPing Nanostores MCP serverARead-onlyIdempotent
Use this when you need to verify the MCP server is alive or check whether the runtime logger bridge is connected.
Inputs: message. Returns: message, loggerBridge
nanostores_project_outlineGet project outlineARead-onlyIdempotent
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.
Inputs: projectRoot. Returns: rootDir, totals, storeKinds, topDirs, +5 more
nanostores_runtime_coverageRuntime coverage reportARead-onlyIdempotent
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"}.
Inputs: projectRoot. Returns: summary, report
nanostores_runtime_overviewGet runtime overviewARead-onlyIdempotent
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}.
Inputs: windowMs, compact. Returns: summary, stats, noisyStores, errorProneStores, +1 more
nanostores_scan_projectScan project for Nanostores usageARead-onlyIdempotent
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.
Inputs: rootUri, force, compact. Returns: root, filesScanned, stores, subscribers, +5 more
nanostores_store_activityGet store runtime activityARead-onlyIdempotent
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}.
Inputs: storeName, limit, windowMs, projectRoot, +2 more. Returns: storeName, stats, events, summary
nanostores_store_impactGet store impact chainARead-onlyIdempotent
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.
Inputs: storeId, name, projectRoot. Returns: sourceStoreId, sourceName, hops, summary
nanostores_store_subgraphGet store subgraphARead-onlyIdempotent
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}.
Inputs: storeId, name, radius, projectRoot. Returns: centerStoreId, radius, nodes, edges, +2 more
nanostores_store_summarySummarize a Nanostores storeARead-onlyIdempotent
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"}.
Inputs: storeId, name, file, rootUri. Returns: store, resolution, subscribers, derivesFrom, +1 more
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 12 tools
Each tool has a clearly distinct purpose with no ambiguity; for example, nanostores_store_impact is specifically for downstream dependency chains, while nanostores_store_subgraph handles bidirectional neighborhoods, and nanostores_scan_project focuses on project indexing versus nanostores_project_outline for summaries. The descriptions explicitly differentiate overlapping tools like nanostores_store_impact and nanostores_store_subgraph, preventing misselection.
All tools follow a consistent snake_case pattern with a 'nanostores_' prefix and descriptive verb_noun combinations (e.g., nanostores_clear_cache, nanostores_docs_search). The naming is predictable and uniform across all 12 tools, making them easily identifiable and readable without any deviations in style.
With 12 tools, the count is well-scoped for the server's purpose of analyzing and debugging Nanostores projects. Each tool serves a specific role in static analysis, runtime monitoring, documentation, and performance tuning, covering a comprehensive workflow without being excessive or insufficient for the domain.
The tool set provides complete coverage for the Nanostores domain, including project scanning (nanostores_scan_project), runtime health checks (nanostores_runtime_overview), debugging (nanostores_store_activity), dependency analysis (nanostores_store_impact), documentation (nanostores_docs_search), and performance optimization (nanostores_find_noisy_stores). There are no obvious gaps; agents can handle all core workflows from setup to troubleshooting.
Maintenance
Related MCP Connectors
Analytics and debugging for your MCP server — explore usage and sessions, then root-cause errors.
2,000+ MCP servers read at source level. Know what one does before you connect. Free, no key.
The official Svelte MCP server providing docs and autofixing tools for Svelte development
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA modular MCP server for code analysis using ast-grep, enabling structural pattern matching and transformations across multiple languages.MIT
- AlicenseNot gradedqualityDmaintenanceMCP server for automatic Storybook story generation, component analysis, and validation. Auto-detects React frameworks and syncs component documentation.22 npm1MIT
- AlicenseAqualityDmaintenanceMCP server that analyzes TypeScript/JavaScript codebases via AST parsing and dependency graph tracing to identify affected tests, detect dead code, circular dependencies, and trace import chains, enabling AI agents to run only relevant tests.1557 npmMIT
- FlicenseNot gradedqualityBmaintenanceMCP server for static code analysis using AST parsing and linters, providing tools to detect syntax errors, type issues, typos, and incorrect variable usage across multiple languages. It supports headless linting with tools like ast_check, lint_check, and health.-