The Mindpilot MCP server lets you visualize code, architecture, and processes as Mermaid diagrams rendered locally in your browser via an AI coding agent.
render_mermaid: Accepts Mermaid diagram syntax, a title (up to 50 characters), and an optional background color to validate and render diagrams as SVGs. Supports all diagram types (flowcharts, sequence diagrams, C4 context, state machines, etc.) with built-in color classes (coral, ocean, forest, sunshine, etc.) optimized for light/dark mode.
open_ui: Launches a local web interface (default: http://localhost:4000) to view, manage, and export previously rendered diagrams.
Export: Save any rendered diagram as a vector (SVG) image for sharing or documentation.
Multi-Client Support: Multiple AI assistants or IDE instances share the same server and diagram history simultaneously.
Local-Only Processing: All diagrams are rendered locally—nothing is sent to the cloud beyond what your LLM provider already receives.
Renders Mermaid syntax diagrams generated by AI assistants in a web interface, enabling visualization of code structures, workflows, and architectures
Supports development workflow with hot module reloading for the client interface
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Mindpilot MCP visualize the authentication flow in this codebase"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
See through your agent's eyes. Visualize legacy code, inspect complex flows, understand everything.
Mindpilot is now available as a lightweightagent skill—no local MCP server needed. Ask your agent to diagram something and it builds a self-contained, interactive Mermaid viewer you can open in your browser or publish as a Claude artifact.
Install with: npx skills add abrinsmead/skills/mermaid-viewer
Visualize Anything: Use your coding agent to generate on-demand architecture, code, and process diagrams to view your code from different perspectives.
Vibe Checks: AI-generated code can accumulate unused and redundant constructs. Use visualizations to spot areas that need cleanup.
Local Processing: Diagrams are never sent to the cloud. Everything stays between you, your agent, and your agent's LLM provider(s).
Export & Share: Export any diagram as a vector image.
Related MCP server: software-design-mermaid-mcp
Node.js v20.0.0 or higher.
claude mcp add mindpilot -- npx @mindpilot/mcp@latest
Under Settings > Cursor Settings > MCP > Click Add new global MCP server and configure mindpilot in the mcpServers object.
{
"mcpServers": {
"mindpilot": {
"command": "npx",
"args": ["@mindpilot/mcp@latest"]
}
}
}Follow the instructions here for enabling MCPs in VS Code: https://code.visualstudio.com/docs/copilot/chat/mcp-servers
Go to Settings > Features > MCP, then click Edit in settings json
Then add mindpilot to your MCP configuration:
{
"mcp": {
"servers": {
"mindpilot": {
"type": "stdio",
"command": "npx",
"args": ["@mindpilot/mcp@latest"]
}
}
}
}Under Settings > Windsurf Settings > Manage Plugins, click view raw config and configure mindpilot in the mcpServers object:
{
"mcpServers": {
"mindpilot": {
"command": "npx",
"args": ["@mindpilot/mcp@latest"]
}
}
}In the AI Thread panel click on the three dots ..., then click Add Custom Server...
In the Command to run MCPserver field enter npx @mindpilot/mcp@latest and click Add Server.
Port: The server defaults to port 4000 but can be configured using the --port command line switch.
Data Path: By default, diagrams are saved to ~/.mindpilot/data/. You can specify a custom location using the --data-path command line switch.
Mindpilot intelligently handles multiple AI assistants running simultaneously. When you have multiple Claude Desktop windows or IDE instances open:
The first mcp client to use Mindpilot starts a shared web server
Additional assistants automatically connect to the existing server
All assistants share the same diagram history and web interface
The server will automatically shuts down a minute after the last MCP clinet disconnects
This means you can work with multiple MCP hosts at once without port conflicts, and they'll all contribute to the same collection of diagrams.
Mindpilot MCP collects anonymous usage data to help us understand how the product is being used and improve the user experience.
If you prefer not to share anonymous usage data, you can disable analytics by adding the --disable-analytics flag to your MCP configuration:
Claude Code:
claude mcp add mindpilot -- npx @mindpilot/mcp@latest --disable-analyticsOther IDEs:
Add "--disable-analytics" to the args array in your configuration:
{
"command": "npx",
"args": ["@mindpilot/mcp@latest", "--disable-analytics"]
}After configuring the MCP in your coding agent you can make requests like "create a diagram about x" and it should use the MCP server to render Mermaid diagrams for you in a browser connected to the MCP server.
You can optionally update your agent's rules file to give specific instructions about when to use mindpilot-mcp.
"Show me the state machine for WebSocket connection logic"
"Create a C4 context diagram of this project's architecture."
"Show me the OAuth flow as a sequence diagram"
Frontier LLMs are well trained to generate valid Mermaid syntax. The MCP is designed to accept Mermaid syntax and render diagrams in a web app running on http://localhost:4000 (default port).
If you use port 4000 for another service you can configure the MCP to use a different port.
Claude Code example:
claude mcp add mindpilot -- npx @mindpilot/mcp@latest --port 5555
To save diagrams to a custom location (e.g., for syncing with cloud storage):
Claude Code example:
claude mcp add mindpilot -- npx @mindpilot/mcp@latest --data-path /path/to/custom/location
Other IDEs:
{
"command": "npx",
"args": ["@mindpilot/mcp@latest", "--data-path", "/path/to/custom/location"]
}If you use asdf as a version manager and have trouble getting MCPs to work (not just mindpilot), you may need to set a "global" nodejs version from your home directory.
cd
asdf set nodejs x.x.xConfigure the MCP in your coding agent (using claude in this example)
claude mcp add mindpilot -- npx tsx <path to...>/src/server/server.ts
Run claude with the --debug flag if you need to see MCP errors
Start the development client (Vite) to get hot module reloading while developing.
npm run dev
Open the development client
localhost:5173
Open the web-based user interface
| Name | Required | Description | Default |
|---|---|---|---|
| autoOpen | No | Automatically open browser |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions opening a web-based UI but doesn't specify whether this launches a browser, requires network access, affects system state, or has side effects. The parameter 'autoOpen' hints at browser behavior, but the description doesn't elaborate on this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that presumably launches or interacts with a web interface, the description is insufficient. It doesn't explain what the UI is for, what happens after it opens, whether it requires authentication, or what the expected user workflow is. With no annotations and no output schema, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter 'autoOpen' with its description and default value. The tool description doesn't add any parameter-specific information beyond what's in the schema, but with zero required parameters and high schema coverage, the baseline is appropriately high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Open the web-based user interface' clearly states the action (open) and target (web-based UI), but it's somewhat vague about what exactly this UI represents or controls. It doesn't distinguish from the sibling tool 'render_mermaid' which appears to serve a different purpose (rendering diagrams).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or in what context it should be invoked. The description doesn't mention prerequisites, dependencies, or typical scenarios for opening the UI.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a Mermaid diagram to SVG format. CRITICAL RULES: 1) Node IDs must be alphanumeric without spaces (use A1, nodeA, start_node). 2) For node labels with special characters, wrap in quotes: A["Label with spaces"] or A["Process (step 1)"]. 3) For quotes in labels use ", for < use <, for > use >. 4) For square brackets in labels use A["Array[0]"]. 5) Always close all brackets and quotes. 6) Use consistent arrow styles (either --> or ->). Example: graph TD\n A["Complex Label"] --> B{Decision?}\n B -->|Yes| C["Result "OK""]\n\nIMPORTANT: If the diagram fails validation, the error message will explain what needs to be fixed. Please read the error carefully and retry with a corrected diagram.
| Name | Required | Description | Default |
|---|---|---|---|
| background | No | Background color | white |
| diagram | Yes | Mermaid diagram syntax. MUST start with diagram type (graph TD, flowchart LR, sequenceDiagram, etc). Node IDs cannot have spaces. Use quotes for labels with spaces/special chars. Avoid forward slashes. Use this colors which work well for both light and dark mode: classDef coral fill:#ff6b6b,stroke:#c92a2a,color:#fff classDef ocean fill:#4c6ef5,stroke:#364fc7,color:#fff classDef forest fill:#51cf66,stroke:#2f9e44,color:#fff classDef sunshine fill:#ffd43b,stroke:#fab005,color:#000 classDef grape fill:#845ef7,stroke:#5f3dc4,color:#fff classDef amber fill:#ff922b,stroke:#e8590c,color:#fff classDef teal fill:#20c997,stroke:#12b886,color:#fff classDef pink fill:#ff8cc8,stroke:#e64980,color:#fff classDef tangerine fill:#fd7e14,stroke:#e8590c,color:#fff classDef sky fill:#74c0fc,stroke:#339af0,color:#000 classDef lavender fill:#d0bfff,stroke:#9775fa,color:#000 classDef mint fill:#8ce99a,stroke:#51cf66,color:#000 classDef rose fill:#ffa8a8,stroke:#ff6b6b,color:#000 classDef lemon fill:#ffe066,stroke:#ffd43b,color:#000 classDef violet fill:#a78bfa,stroke:#8b5cf6,color:#fff classDef peach fill:#ffc9c9,stroke:#ffa8a8,color:#000 | |
| title | Yes | Title for the diagram (max 50 characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and excels at this. It provides extensive validation rules, error handling guidance ('If the diagram fails validation, the error message will explain what needs to be fixed'), and specific formatting requirements that go beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with clear sections (purpose, critical rules, example, error handling). Every sentence serves a purpose, though it's somewhat lengthy due to the detailed formatting rules. The information is front-loaded with the core purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description provides exceptional completeness. It covers purpose, detailed usage rules, parameter guidance, error handling, and examples. The comprehensive formatting instructions compensate for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the input schema has 100% description coverage, the description adds significant value by providing detailed formatting rules, examples, and validation requirements for the 'diagram' parameter that aren't captured in the schema. It doesn't add much for 'background' or 'title' parameters, but the comprehensive diagram guidance compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Render a Mermaid diagram to SVG format') and distinguishes it from the only sibling tool 'open_ui' by focusing on diagram rendering rather than UI operations. It provides a complete verb+resource+output format specification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (for rendering Mermaid diagrams to SVG) and includes critical formatting rules. However, it doesn't explicitly mention when NOT to use it or compare it to potential alternatives beyond the single sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have completely distinct purposes: 'open_ui' launches a web interface, while 'render_mermaid' processes diagram code into SVG format. There is no overlap in functionality, making tool selection unambiguous.
Both tools follow a consistent verb_noun naming pattern ('open_ui' and 'render_mermaid'), using lowercase with underscores. The verbs 'open' and 'render' clearly describe their actions, maintaining a predictable convention throughout.
With only two tools, the server feels under-scoped for a 'Mindpilot' domain, which suggests broader cognitive or planning capabilities. This minimal set may limit agent workflows, as it lacks tools for core operations like creating, editing, or managing content beyond diagram rendering.
The tool surface is severely incomplete for a 'Mindpilot' server, which implies mind-mapping or planning functionality. It only offers UI access and diagram rendering, missing essential CRUD operations for mind maps, such as creating, updating, or retrieving content, leaving significant gaps for agent tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Let Claude, Cursor, or ChatGPT author Mermaid diagrams your team can read and share.
Generate dynamic Mermaid diagrams and charts with AI assistance. Customize styles and export diagr…
Talk to Claude and get a live web app deployed to a real URL, with Postgres, storage and cron.
Build a full backend from Claude Code — boards, data, REST APIs — plus a ready-made admin UI
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/abrinsmead/mindpilot-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
