Synapse
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SYNAPSE_DATA_DIR | No | Directory where mindmaps are stored. Defaults to ~/.synapse/data. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_mindmapA | Create a new mindmap to track a coding plan, touched files, and the agent's mental model / HLD of the code. |
| add_nodeC | Add a child node under a parent node. Supports both plan/task nodes ('plan', 'task', 'code', 'file', 'note') and semantic code-thinking nodes ('component', 'data_flow', 'hypothesis', 'decision', 'risk'). |
| update_nodeC | Update a node's label, status, semantic type, notes, or attached files. |
| link_nodesB | Create a directed concept or data-flow link between two nodes (e.g. 'calls', 'streams SSE to', 'mutates', 'depends on') to map how the agent understands interactions between components, files, or ideas. |
| map_architectureC | Batch-map the agent's high-level understanding and mental model of the codebase (HLD): components, data flows, decisions, hypotheses, and risks, plus directed links between them. Nodes are created under a 'Code Mental Model (HLD)' branch unless parentId or parentKey is given. |
| update_plan_statusA | Update the status of a plan task ('planned', 'in_progress', 'completed', 'blocked'), with an optional note. Can automatically start the next task by setting nextNodeId. |
| log_file_touchA | Record that a file was read, created, modified, renamed, or deleted, plus symbol-level |
| sync_git_statusB | Inspect git status and diff in the workspace and automatically attach all modified/created/deleted files to the mindmap. |
| get_plan_summaryA | Get a concise status report of the mindmap plan: completion percentage, active tasks, blocked items, HLD concept count, and all touched files with their changes. |
| remove_nodeA | Remove a node and all its descendants from a mindmap. Cannot remove the root. |
| list_mindmapsA | List all stored mindmaps with their IDs, titles, and last updated timestamps. |
| get_mindmapC | Get a mindmap's full data as JSON. |
| render_mindmapB | Render a mindmap in a digestible format: mermaid (flow chart syntax), text (indented outline), or json. |
| delete_mindmapB | Delete an entire mindmap and all its nodes. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| track-coding-plan | Instruct the agent to create and continuously update a live Synapse mindmap tracking the plan and every file touched. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Several tool pairs have blurry boundaries: update_node also mutates node status while update_plan_status exists for status changes, add_node+link_nodes overlaps with the batch map_architecture, and log_file_touch overlaps with sync_git_status for attaching files. Descriptions do clarify the single-item vs batch/automation split, but an agent must read carefully to pick correctly.
Nearly everything follows a snake_case verb_noun pattern (create_mindmap, list_mindmaps, add_node, link_nodes, render_mindmap, log_file_touch). Minor deviations: create/delete for mindmaps vs add/remove for nodes, and get_plan_summary uses 'plan' where the resource is a mindmap.
14 tools is well within the comfortable range and each maps to a distinct part of the plan/mindmap workflow (CRUD, linking, batch HLD mapping, status propagation, file tracking, rendering). No tool looks like filler.
Mindmap lifecycle (create/list/get/render/delete), node CRUD, links, plan status with auto-advance, and git/file tracking are all covered, giving a full working loop. Gaps are minor: no way to unlink nodes, rename/update a mindmap's title, or move a node between parents.