How do I use memory_graph_mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@memory_graph_mcp What's the impact of changing src/api/users.ts?" 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.

memory_graph_mcp

by FuryCow

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

🧠 memory_graph_mcp

An MCP server that gives your AI agent a persistent knowledge graph of your project.

TypeScript MCP Tests License Node

AST dependencies · DB-schema links · debugging sessions · side effects

💡 Why

When a feature is requested, the agent receives a dependency subgraph, not a list of similar files — protecting adjacent modules from breaking changes.

graph_query_context("src/api/users.ts")

┌─────────────────┐     imports      ┌─────────────────┐
│  src/db/users.ts │ ◄────────────── │ src/api/users.ts │
└────────┬────────┘                  └─────────────────┘
         │ writes_table
         ▼
   [table: users]   ◄── also touched by 2 other files

Instead of "here are 5 files matching users" the agent learns: changing this file affects two other modules, writes to the users table, and a past debug session recorded a missing await bug here.

Related MCP server: hive-memory

🛠 Tools

Tool	Purpose
`graph_query_context`	file/symbol → dependency subgraph + adjacent modules + related sessions
`graph_impact_analysis`	planned change → affected nodes, tables, and risk level
`graph_get_side_effects`	implicit module effects: table reads/writes, calls
`graph_record_session`	record a discussion/debug session with decisions and bugs, linked to files
`graph_stats`	index state: nodes, edges, files, last update time

📦 Installation

Requires Node.js ≥ 18

git clone git@github.com:FuryCow/memory_graph_mcp.git
cd memory_graph_mcp
npm install
npm run build

🔌 Connecting

The server communicates over stdio. Set the root of the project you want to index as the working directory (cwd) in your MCP client config — the index is built from process.cwd() and stored in .memory-graph/graph.db.

Claude Desktop / Cursor

The configuration is identical for both clients; only the config file location differs:

Claude Desktop: claude_desktop_config.json (menu → Settings → Developer → Edit Config)
Cursor: ~/.cursor/mcp.json

{
  "mcpServers": {
    "memory-graph": {
      "command": "node",
      "args": ["/absolute/path/to/memory_graph_mcp/dist/src/index.js"],
      "cwd": "/absolute/path/to/your/project"
    }
  }
}

💡 On Windows, escape paths (C:\\path\\to\\...) or use forward slashes (C:/path/to/...).

🗺 Graph model


Nodes	`File`, `Symbol`, `Table` — journal: `Session`, `Decision`, `Bug`
Edges	`imports`, `calls`, `contains`, `reads_table`, `writes_table`

The indexer (tree-sitter) extracts imports, function definitions and calls, and database access from SQL strings (SELECT/INSERT/UPDATE/DELETE) and ORM patterns (Prisma, drizzle). A watcher (chokidar) incrementally re-indexes the graph on file changes — typically under a second.

🧰 Stack

Layer	Technology
Server	`@modelcontextprotocol/sdk` (stdio)
Parsing	`tree-sitter` (TypeScript / TSX / JavaScript)
Storage	`better-sqlite3` (WAL) in `.memory-graph/graph.db`
Watching	`chokidar` (mtime-based incremental re-index)

🚀 Development

npm run build   # tsc
npm test        # node --test dist/test/*.test.js
npm run lint    # tsc --noEmit

📄 License

MIT

Available Tools

5 tools

graph_get_side_effectsB

Return implicit side effects of a module (DB writes, external calls, etc.).

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	File path (relative to project root)

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full weight of behavioral disclosure. It clearly indicates a read-style operation by saying 'Return', and gives useful examples of what counts as side effects. However, it does not explain how implicit side effects are discovered, whether the operation is fully read-only, or what is excluded from 'implicit'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that front-loads the operation and target. The parenthetical examples add concreteness without unnecessary verbosity, making it an ideal length for a simple one-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is minimally viable for a tool with one simple parameter: an agent knows the required input and broadly what to expect from the output. However, because there is no output schema, the description does not specify the return format, content structure, or edge cases such as missing files or modules without side effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides complete documentation for the single required parameter, path, with a clear description and 100% coverage. The tool description adds no additional parameter-level semantics, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb, 'Return', and a clear resource, 'implicit side effects of a module', with concrete examples like DB writes and external calls. It is clear enough to convey the core function, though it does not explicitly distinguish itself from the conceptually related sibling graph_impact_analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 such as graph_impact_analysis. The intended context must be inferred solely from the one-line purpose, with no explicit when-to-use, when-not-to-use, or alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

graph_impact_analysisB

Given a planned change, return affected nodes and risks.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	File path to be changed
`change`	Yes	Description of the planned change

TDQS

B3.1/5.0

Behavior2/5

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. It does not clarify whether the operation is read-only, whether it has side effects, whether it requires any prerequisites, or how risks are determined. The one-sentence description is functionally informative but behaviorally thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every word contributes to the core meaning, and the input-to-output structure is immediately clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description gives a high-level understanding of the output, but without an output schema it does not specify the structure of affected nodes or risks, nor does it address edge cases or sibling-tool boundaries. It is minimally adequate but leaves room for ambiguity in real usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 both path and change adequately. The description adds minimal semantic value beyond the schema, and no parameter details are missing, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool analyzes a planned change and returns affected nodes and risks, which is a specific enough verb-resource combination. It does not explicitly distinguish itself from graph_get_side_effects, which could plausibly overlap, so it falls short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus alternatives like graph_get_side_effects or graph_query_context. The description only states what the tool does, leaving the agent to infer usage from the tool name and output description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

graph_query_contextB

Return the dependency subgraph for a file or symbol, plus adjacent modules.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	File path (relative to project root)
`depth`	No	Traversal depth
`symbol`	No	Optional symbol name to focus on

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says a graph is returned; it does not state whether the operation is read-only, how depth or symbol affect traversal, what 'adjacent modules' means, or any limits or performance traits. This is a notable gap for a query tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no filler; the main action is front-loaded and the phrasing is tight. It is concise, though the brevity omits useful behavioral and usage details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The core purpose and key parameters are covered between the description and the schema, so the tool is minimally invocable. However, with no output schema and no annotations, the vague phrase 'plus adjacent modules' and the lack of result-shape or traversal context leave meaningful gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all parameters are already documented in the schema. The description's 'file or symbol' loosely maps to path and symbol but adds no meaningful detail beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific operation ('Return') and a distinct resource ('dependency subgraph for a file or symbol, plus adjacent modules'), making the tool's core purpose clear. It differentiates from siblings like graph_stats and graph_impact_analysis, though it does not explicitly name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for retrieving dependency structure, which gives a reasonable cue for when to use it. However, it offers no explicit guidance on when to prefer this over graph_impact_analysis or graph_get_side_effects, and no exclusions or alternative conditions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

graph_record_sessionA

Record a discussion/debug session with decisions and bugs, linked to related files.

ParametersJSON Schema

Name	Required	Description
`bugs`	No	Bugs encountered/fixed
`topic`	Yes	Session topic
`decisions`	No	Decisions made
`related_paths`	No	Related file paths (relative to project root)

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description bears the full burden of disclosing behavior. It states that a session is recorded and linked to related files, implying a write operation, but it does not disclose side effects, whether a new node is created, whether existing sessions are overwritten, or any persistence/error behavior. The agent is left with only a high-level purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It states the action, the object, the key content, and the linking behavior in minimal space, and every phrase contributes to understanding what the tool does.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The schema covers the parameters well, and the description conveys the core purpose. However, with no annotations and no output schema, an agent still lacks guidance on when to choose this over sibling tools, what side effects to expect, and what the tool returns after recording. It is adequate for a simple mutation but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the fields topic, bugs, decisions, and related_paths are already fully documented in the schema. The description adds a minor contextual link ('linked to related files') but no meaningful parameter-level semantics beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description provides a specific verb ('Record'), a clear resource ('discussion/debug session'), and specifies the key content (decisions, bugs, related files). This clearly differentiates it from the sibling read/analysis tools like graph_query_context and graph_impact_analysis, since this tool is about creating/persisting a session record rather than querying graph context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Record a discussion/debug session' implies when the tool should be used, but the description never explicitly states when to use it versus alternatives, nor does it mention any when-not-to-use conditions. Sibling tool names suggest the broader graph context, but no alternative routing is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

graph_statsA

Return index state: node/edge counts, files indexed, last update time.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of behavioral disclosure. 'Return index state' suggests a read-only operation and lists the kind of data returned, but it does not explicitly state whether it is non-mutating, whether it requires special permissions, or whether there are any side effects or consistency caveats.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every element ('node/edge counts', 'files indexed', 'last update time') adds concrete value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only stats tool with no output schema, the description is largely complete: it names the return categories. A small gap is that it does not describe the exact output format or timing semantics of 'last update time', but this is minor for a stats endpoint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there are no parameter details to document. The description appropriately focuses on what the returned state contains, which is all an agent needs for invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') and a clear resource ('index state'), and enumerates the exact contents (node/edge counts, files indexed, last update time). This distinguishes graph_stats from its siblings, which are about recording sessions, querying context, and analyzing impacts/side effects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: call this tool when you need index state or statistics. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions, leaving the agent to infer the appropriate context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Sep 9, 2026
- First observedgraph_get_side_effects
- First observedgraph_impact_analysis
- First observedgraph_query_context
- First observedgraph_record_session
- First observedgraph_stats

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-09-09 17:36 across 5 tools

Disambiguation5/5

Each tool targets a distinct operation: recording a session, querying context, analyzing impact, inspecting side effects, and viewing stats. There is no meaningful overlap, so an agent can reliably pick the right tool.

Naming Consistency4/5

All tools share the graph_ prefix and most follow a verb_noun pattern, but graph_impact_analysis and graph_stats are noun-style names and only graph_get_side_effects uses 'get_'. The overall pattern is still predictable and readable.

Tool Count5/5

Five tools is a tight, well-scoped set that covers the server's apparent purpose without redundancy or bloat. Each tool earns its place.

Completeness4/5

The set covers the core workflows: recording new knowledge, querying relationships, assessing change impact, inspecting side effects, and checking index health. Minor gaps like updating or deleting sessions are absent but not critical to the primary graph-based workflow.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Umtri
io.umtri
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
Code Analysis Knowledge & Memory Software Architecture
1
Brain Scanner DOAuth
io.github.kevin-lozada-santos
Codebase graphs, caller impact analysis, and recorded project context for AI coding agents.
Code Analysis Developer Tools Knowledge & Memory
1371
TeamShared C
io.github.xhad
Shared memory for coding agents. Stop re-explaining your codebase every session.
Knowledge & Memory Developer Tools
991
Penfield Memory AOAuth
io.github.penfieldlabs
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Knowledge & Memory RAG Systems Vector Databases
1726

Related MCP Servers

GraphHub
Code Analysis Knowledge & Memory Developer Tools
slnquangtran
F
license
Not graded
quality
C
maintenance
Transforms codebases into a knowledge graph for AI agents, enabling semantic search, impact analysis, and persistent session memory with up to 94% token savings.
Updated 5 months ago (2026-04-25 13:54 UTC)
0
16
-
hive-memory
Knowledge & Memory RAG Systems
moonx010
A
license
Not graded
quality
C
maintenance
Provides AI coding agents with persistent, graph-connected memory across projects, enabling cross-project context retrieval via synaptic connections and hybrid search.
Updated 6 months ago (2026-04-02 09:01 UTC)
9 npm
8
MIT
agent-memory-mcp
Knowledge & Memory Autonomous Agents
Yarmoluk
A
license
Not graded
quality
B
maintenance
Enables persistent, graph-based memory for AI agents, allowing them to store, traverse, and recall relationships between facts, decisions, and context across sessions for efficient reasoning and reduced token usage.
Updated 3 months ago (2026-07-07 02:04 UTC)
MIT
Hokmah MCP Server
Code Analysis Coding Agents Developer Tools
davidangularme
A
license
Not graded
quality
D
maintenance
Provides AI coding agents with persistent architectural memory of codebases, enabling impact analysis, test generation, and code generation with reduced token usage.
Updated 5 months ago (2026-04-22 06:41 UTC)
MIT