How do I use HydraGraph MCP?

1. Click on "Install 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., "@HydraGraph MCP Show me the impact of changing analyzeWithAI." 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.

HydraGraph MCP

by sayan365

Overview Schema Related Servers Score Discussions

TypeScript

Local

HydraGraph MCP

AI coding agents such as Claude Code and Codex usually answer “what depends on this?” by searching for similar text and inferring the result. HydraGraph instead parses a real codebase into a structural call graph, persists that graph in HydraDB, and exposes it through MCP. The agent receives verified callers, callees, source locations, and change-impact paths instead of guesses—including dependencies that cross from a frontend fetch() call to the matching backend route.

Why HydraDB

HydraDB makes the code graph persistent and independently queryable; it is not a temporary cache rebuilt privately by an agent during each session. HydraGraph uses the self-hosted HydraDB OSS container and its OpenCypher HTTP endpoint:

POST /v1/graphs/{graph_id}/query

AST-derived nodes and CONTAINS, IMPORTS, CALLS, and CALLS_API relationships are written with parameterized OpenCypher queries. MCP tools then query those stored relationships for direct and transitive dependency evidence.

Related MCP server: arcscope

Quick start

Requirements: Node.js 20+, npm, Docker Desktop, and PowerShell. The bundled HydraDB launcher binds its HTTP, Bolt, and admin ports to localhost only.

git clone https://github.com/sayan365/hydragraph-mcp.git hydragraph
cd hydragraph
npm install
npm run build

# Start the self-hosted HydraDB OSS container and configure its local-only token.
npm run hydradb:start
$env:HYDRADB_TOKEN = "local-development-token-32-bytes"

# Expose the package's `hydragraph` executable on your local npm path.
npm link

hydragraph init

# Use any local TypeScript repository, or clone the verified Docwise target.
git clone https://github.com/sayan365/docwise.git ../target-docwise
hydragraph add ../target-docwise

# Starts the existing MCP stdio server; it waits silently for an MCP client.
hydragraph mcp

hydragraph init checks HydraDB and writes .hydragraph/config.json. hydragraph add replaces the generated code graph with data from the supplied repository. Run one repository per configured HydraDB graph.

An MCP client normally launches hydragraph mcp itself, so do not also keep a separate copy running. For Codex, add this to ~/.codex/config.toml and replace the launcher path with the absolute path on your machine:

[mcp_servers.hydragraph]
command = "node"
args = ["C:\\absolute\\path\\to\\hydragraph\\bin\\hydragraph.js", "mcp"]
env = { HYDRADB_URL = "http://127.0.0.1:8443", HYDRADB_TOKEN = "local-development-token-32-bytes", HYDRADB_NAMESPACE = "default" }

The equivalent project-level .mcp.json configuration for Claude Code is:

{
  "mcpServers": {
    "hydragraph": {
      "type": "stdio",
      "command": "node",
      "args": [
        "C:\\absolute\\path\\to\\hydragraph\\bin\\hydragraph.js",
        "mcp"
      ],
      "env": {
        "HYDRADB_URL": "http://127.0.0.1:8443",
        "HYDRADB_TOKEN": "local-development-token-32-bytes",
        "HYDRADB_NAMESPACE": "default"
      }
    }
  }
}

Restart the client after adding the configuration. The token shown above is the fixed credential generated by the localhost-only development launcher, not a production secret.

What it does today

find_callers(symbol) returns the code nodes that directly call an exact qualified symbol or HTTP route, with relationship and call-site evidence.
impact_of_change(symbol) walks incoming CALLS and CALLS_API relationships to return the transitive blast radius with depths and source locations.
explain_context(question) matches a natural-language question to a graph symbol and returns its callers, callees, evidence, and two-hop impact for the calling agent to reason over.

This verified question demonstrates the frontend-to-backend boundary:

explain_context("what would break in the frontend if the /api/analyze-document response format changed?")

Relevant output from the live Docwise graph:

{
  "matchedSymbol": "api._backend.route.POST./api/analyze-document",
  "callers": [
    {
      "caller": "src.context.DocumentContext.DocumentProvider.analyzeWithAI",
      "file": "src/context/DocumentContext.tsx",
      "line": 140,
      "relationship": "CALLS_API",
      "evidence": "src/context/DocumentContext.tsx:154 fetch(\"/api/analyze-document\")"
    }
  ],
  "impact": [
    {
      "symbol": "src.context.DocumentContext.DocumentProvider.analyzeWithAI",
      "depth": 1,
      "relationship": "CALLS_API"
    },
    {
      "symbol": "src.context.DocumentContext.DocumentProvider.scanDocumentFile",
      "depth": 2,
      "relationship": "CALLS"
    }
  ]
}

Reference run: real numbers

The verified target is sayan365/docwise, a real TypeScript/React document-analysis application.

Parsed 27 files, 92 nodes, 165 edges
65 CONTAINS
45 IMPORTS
51 CALLS
4 CALLS_API
6 Express route nodes
449 external or ambiguous calls left unresolved
0 static fetch calls left unresolved

Current scope

TypeScript and TSX parsing only.
51 of 500 ordinary call sites resolve to internal CALLS edges (about 10%); the 449 unresolved sites are primarily external or ambiguous and are never guessed.
One repository per configured HydraDB graph.
CALLS_API matches static fetch() paths to Express routes by path string; dynamic paths, Axios, GraphQL, and response-schema analysis are not modeled.
explain_context returns a two-hop impact view by default.

Roadmap — not built yet

Multi-project graphs and project-aware namespacing.
Hosted or remote MCP instances per project.
Parsers for additional programming languages.
Team-wide context spanning services owned by different developers.

Architecture

┌──────────────────────┐    ┌─────────────────────┐    ┌──────────────────────┐
│ Target TS/TSX repo   │───▶│ tree-sitter parser  │───▶│ Self-hosted HydraDB  │
│ src/ + api/          │    │ nodes + call edges  │    │ persisted OpenCypher │
└──────────────────────┘    └─────────────────────┘    └──────────┬───────────┘
                                                                 │
                                                                 ▼
                                                      ┌──────────────────────┐
                                                      │ HydraGraph MCP stdio │
                                                      │ three graph tools    │
                                                      └──────────┬───────────┘
                                                                 │
                                                                 ▼
                                                      ┌──────────────────────┐
                                                      │ Claude Code / Codex  │
                                                      │ reasons over evidence│
                                                      └──────────────────────┘

Tech stack and attribution

TypeScript on Node.js.
tree-sitter with tree-sitter-typescript for TypeScript/TSX AST parsing.
HydraDB, AGPL-3.0, as the self-hosted graph database and OpenCypher query engine.
Model Context Protocol TypeScript SDK for the stdio MCP server and tools.
Zod for MCP tool input schemas.
Docwise as the real validation target; it is not redistributed here.

HydraGraph MCP is available under the MIT License. Implementation status and evidence are tracked in docs/PRD.md.

Available Tools

3 tools

explain_contextA

Given a natural-language question about the codebase, find the most relevant symbol and return its callers, callees, call-site evidence, and two-hop change impact from HydraDB. Use this structured graph data to answer the user's question yourself.

ParametersJSON Schema

Name	Required	Description	Default
`question`	Yes	Free-text codebase question, for example: what happens if I change analyzeWithAI's return type?

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the transparency burden and does a good job explaining the behavior: it finds the most relevant symbol, retrieves structured graph data, and instructs the agent to use that data to answer the user's question. It implies a read-only analysis operation through verbs like 'find' and 'return', though it doesn't explicitly state 'read-only'.

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 two sentences long, front-loaded with the core workflow, and has no filler or redundant content. Every clause adds meaningful information about inputs, outputs, or how to use the returned data.

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?

Given the absence of an output schema, the description adequately enumerates the key return items (callers, callees, call-site evidence, two-hop impact) and the self-answering instruction. It doesn't mention limitations or edge cases, but for a single-parameter tool with simple inputs, this is reasonably 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?

The schema fully describes the only parameter 'question' with an example, and the description adds no extra semantic detail beyond restating it's a natural-language codebase question. With 100% schema coverage, 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.

Purpose5/5

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

The description clearly states the tool's function: take a natural-language question, find the most relevant symbol, and return callers, callees, call-site evidence, and two-hop change impact. This specific output set distinguishes it from sibling tools find_callers and impact_of_change, which are narrower.

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

Usage Guidelines4/5

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

The description provides clear context for when to use it: when a natural-language question about the codebase needs a structured graph data answer. It does not explicitly mention sibling alternatives or exclusions, but the usage context is sufficiently clear for an agent to select it.

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

find_callersA

Find functions or methods that directly call an exact fully-qualified TypeScript symbol.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	Fully-qualified symbol, for example src.context.DocumentContext.DocumentProvider.analyzeWithAI

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals important matching constraints ('directly call' and 'exact fully-qualified'), but it does not explicitly state read-only behavior, return format, or edge-case handling like missing symbols or re-exports.

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 concise sentence that immediately communicates the tool's purpose with no filler. It is well-structured and easy to parse.

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 simple single-parameter tool without an output schema, the description covers the essential input criteria and matching behavior. It does not explicitly state the return value or format, but this is a minor gap given the tool's low complexity.

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 schema fully documents the single 'symbol' parameter with type, requiredness, and an example, so the description adds no new parameter semantics; it merely restates that the symbol must be exact and fully-qualified.

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 ('Find') and clearly identifies the resource: functions/methods that directly call an exact fully-qualified TypeScript symbol. This distinguishes it from sibling tools like impact_of_change and explain_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 description implies usage for locating direct callers, but it does not provide explicit when-to-use or when-not-to-use guidance. It also does not contrast this tool with transitive-caller or impact-analysis alternatives.

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

impact_of_changeA

Find the transitive blast radius of changing an exact fully-qualified TypeScript symbol.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	Fully-qualified symbol to trace backwards through CALLS edges

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does convey the key behavior of transitive traversal through 'transitive blast radius' and implies a read-only operation via 'Find'. However, it does not disclose what the output will contain, whether the symbol itself is included, or any potential performance/cost implications.

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. It begins with the active verb 'Find' and immediately communicates the core purpose.

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?

For a simple one-parameter tool, the description covers the core purpose but lacks usage guidance and return-value details. Since there is no output schema, the agent is left to guess what the response will contain. The description is adequate but leaves some context gaps.

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?

Schema coverage is 100%, so the baseline is 3. The description adds value by specifying 'exact fully-qualified TypeScript symbol', which clarifies the required format beyond the schema's 'Fully-qualified symbol'. The 'exact' and 'TypeScript' qualifiers help the agent understand the input more precisely.

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?

Description uses a specific verb 'Find' and clearly defines the scope: transitive blast radius of changing a TypeScript symbol. It distinguishes from sibling tools by emphasizing the transitive reach, which is broader than just direct callers (as in find_callers) or general 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 'transitive blast radius' implies this is for assessing change impact, but the description does not explicitly state when to use it versus alternatives like find_callers or explain_context. No direct comparison or exclusions are mentioned, so usage guidance is only implied.

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. Dates show when Glama detected each change.

3 tool updatesv0.1.0Aug 17, 2026
- First observedexplain_context
- First observedfind_callers
- First observedimpact_of_change

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation4/5

The three tools have clearly distinct primary purposes: find_callers for direct callers, impact_of_change for transitive blast radius, and explain_context for natural-language-driven exploration. Some overlap exists between find_callers and impact_of_change (the latter can include direct callers), but descriptions are sufficient to differentiate them.

Naming Consistency3/5

Tool names are descriptive but not uniformly patterned. find_callers and explain_context use an imperative verb_noun form, while impact_of_change is a noun_phrase. This mixed convention is still readable, but inconsistent.

Tool Count4/5

Three tools is on the lower end but reasonable for a focused code-analysis server covering direct query, impact analysis, and natural-language explanation. The set does not feel overly thin given the specificity of the domain.

Completeness4/5

The tools cover the core workflow of understanding callers and change impact. Missing explicit callee querying or symbol metadata retrieval could be gaps, but impact_of_change likely subsumes some of those needs. Overall, the surface is workable for its apparent purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

gentlyOAuth
is.gently
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Code Analysis Developer Tools
1
trip2g A
io.github.trip2g
Serve a folder of Markdown notes as an MCP server: hybrid search, reading, and sourced answers.
RAG Systems Note Taking Search
11237
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361
saagarpatel.dev Portfolio A
io.github.saagpatel
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Search Documentation Access
82

Related MCP Servers

code-graph-mcp
Code Analysis Knowledge & Memory Search
sdsrss
A
license
Not graded
quality
A
maintenance
A high-performance code knowledge graph server implementing MCP, indexing codebases into a structured AST knowledge graph with semantic search, call graph traversal, and HTTP route tracing.
Updated 2 days ago (2026-09-04 18:20 UTC)
3,126
72
MIT
arcscope
Code Analysis Software Architecture
iliedanila
A
license
Not graded
quality
A
maintenance
A local MCP server that gives AI coding agents symbol definitions, dependency graphs, and a live architecture vocabulary for TypeScript/JavaScript repos, with no network or embeddings.
Updated 2 months ago (2026-07-05 16:16 UTC)
18
MIT
Context Bunker MCP
Code Analysis Developer Tools
tonghaoch
A
license
Not graded
quality
D
maintenance
An MCP server that indexes your codebase using tree-sitter AST parsing and gives AI tools instant access to structural intelligence like dependency graphs, call trees, and dead code detection from a local SQLite database.
Updated 6 months ago (2026-03-03 02:28 UTC)
MIT
codegraph-mcp
Code Analysis Developer Tools
SiwarKhalfaoui
A
license
A
quality
C
maintenance
An MCP server that indexes TypeScript/JavaScript codebases into precise call and import graphs using the TypeScript compiler API, allowing Claude or any MCP client to query definitions, callers, callees, and perform impact analysis.
Updated 2 months ago (2026-07-05 12:29 UTC)
7
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sayan365/hydragraph-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server