A Kùzu-backed code-graph MCP server that indexes Ruby on Rails codebases into a queryable graph, enabling token-efficient code navigation without grepping through files.
find_definition(name) — Locate where any class, module, method, or function is defined in the codebase
find_callers(name, depth) — Find all functions/methods that call a given name, transitively up to a specified number of hops, traversing CALLS, ENQUEUES, and DELIVERS edges
find_references(name) — Discover all inbound references to a name, including calls, imports, and inheritance relationships
impact_of(name, max_depth) — Predict the blast radius of a change by finding all transitive callers up to a configurable depth
module_overview(path) — Get a file-level summary including exports, imports, and most-called internal symbols
routes_for(controller_or_action) — Look up HTTP routes (verb + URL) that map to a given Rails controller or specific controller action
associations_of(model) — Retrieve all ActiveRecord associations (has_many, has_one, belongs_to, HABTM) for a model, plus reverse-references from other models
graph_stats() — Get a health-check overview with counts of all node and edge types in the indexed graph
Indexes Ruby on Rails codebases into a queryable graph, enabling AI agents to explore model associations, routes, callbacks, jobs, mailers, and more through graph-based queries.
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., "@graphdb query associations User"
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.
A Kùzu-backed code-graph MCP plugin for Claude Code. Indexes Ruby on Rails codebases into a queryable graph of associations, routes, callbacks, jobs, and mailers — a token-efficient alternative to grep for navigating Rails code.
The animation above shows the CLI. The same eight tools are exposed to Claude Code via MCP — see docs/PROMPTS.md for natural-language prompts you can try directly in a Claude Code session.
Rails encodes most of its architecture in DSL declarations (has_many,
before_action, resources, include) rather than direct method calls. Grep
matches the strings but cannot turn them into relationships:
Question | Grep | graphdb |
"What models reference User?" | 200+ matches across |
|
"What routes hit | Scan 218-line |
|
"Who delivers |
|
|
"What jobs do | Multi-step grep + read |
|
Related MCP server: Code-Index-MCP
Proof of concept, validated against a real Rails 8 / Ruby 3.3 codebase
(smart-hub-backend, 494 indexed .rb files):
nodes: 2913 edges: 4731 index time: ~0.8s
60 models 63 controllers 25 concerns 121 services 67 serializers
7 mailers 6 jobs 109 migrations 230 routes 421 actionsValidation against grep ground truth on smart-hub-backend:
Pattern | Grep | Graph | |
| 52 | 52 | exact |
| 79 | 79 | exact |
| 15 | 15 | exact |
| 66 | 66 | exact |
| 11 | 11 | exact |
| 48 lines | 58 edges | each call's rules expand to one edge per rule |
| 46 lines | 377 edges | each filter × N actions in |
# Set up a venv with uv (sidesteps Homebrew's broken ensurepip on macOS)
uv venv .venv --python 3.13
uv pip install --python .venv/bin/python -e .
# Index a Rails project (writes to ~/.cache/graphdb/<repo>-<hash>.kuzu/;
# nothing is written to the target repo)
.venv/bin/graphdb --root /path/to/rails_app index /path/to/rails_app
# CLI queries
.venv/bin/graphdb --root /path/to/rails_app query def User
.venv/bin/graphdb --root /path/to/rails_app query associations User
.venv/bin/graphdb --root /path/to/rails_app query routes Api::V1::UsersController
.venv/bin/graphdb --root /path/to/rails_app query callers UserInviteMailer --depth 2
.venv/bin/graphdb --root /path/to/rails_app query impact ScheduleExecutionJob
.venv/bin/graphdb --root /path/to/rails_app query refs Account
.venv/bin/graphdb --root /path/to/rails_app statsAdd to your Claude Code MCP config (~/.claude.json or project-level):
{
"mcpServers": {
"graphdb": {
"command": "/path/to/Graph_DB/.venv/bin/graphdb-mcp",
"env": { "GRAPHDB_ROOT": "/path/to/your/rails_app" }
}
}
}Tools exposed to Claude:
Tool | Answers |
| Where is |
| Who calls/enqueues/delivers |
| All inbound edges to |
| Transitive callers — predicted blast radius |
| File-level summary: exports, imports, hotspots |
| HTTP routes that hit a controller / action |
| All |
| Counts of nodes/edges by kind |
NODE KINDS
file, module, class, method, class_method,
model, controller, action, concern, service, serializer,
job, mailer, validator, helper, channel, error_class,
migration, route, external
EDGE KINDS
Generic Ruby: CONTAINS, CALLS, INHERITS, INCLUDES
Model DSL: HAS_MANY, BELONGS_TO, HAS_ONE, HABTM, VALIDATES, SCOPES
Controllers: BEFORE_ACTION, AFTER_ACTION, SKIP_BEFORE, RENDERS
Routes: HANDLES, MOUNTS
Async: ENQUEUES, DELIVERSindexer.py parses every .rb under app/, lib/, config/,
db/migrate/ with tree-sitter-ruby. Two passes:
Pass 1: register every class/module/method as a node, build a qualname index used for resolution.
Pass 2: walk again, emit INHERITS, INCLUDES, CALLS, and the
Rails-specific edges (HAS_MANY, BEFORE_ACTION, ENQUEUES, etc.)
Pass 3: a separate walker handles config/routes.rb (DSL outside any
class), producing Route nodes with HANDLES edges to controller actions.
graph.py buffers nodes/edges in memory and bulk-flushes via Cypher
UNWIND at end of indexing. Drops full-repo indexing from ~8 minutes (individual
inserts) to ~0.8 seconds.
queries.py issues Cypher patterns like
MATCH (caller)-[:CALLS|ENQUEUES|DELIVERS*1..3]->(target) — the database
does the BFS.
mcp_server.py exposes the queries as MCP tools for Claude Code.
Static parsing only. Doesn't run Rails — no type inference, no resolution
of define_method / method_missing / dynamic class_eval.
Relative imports / autoload constants: resolved by unique-name fallback; ambiguous names are skipped silently.
Custom DSLs (acts_as_paranoid, paper_trail's has_paper_trail, amoeba):
not yet specialized — they emit generic CALLS edges at class scope.
Routes: scope, member/collection custom routes, constraints,
concerns (route concerns), nested resources past 1 level — partial or
skipped. The 7 standard REST actions, namespace, mount, devise_for,
and get/post/... with to: work fully.
Reindex is one-shot. Edit a file, rerun graphdb index. No file watcher.
Specialize the major Gemfile DSLs in smart-hub-backend (paper_trail, discard, amoeba, flipper).
Member / collection / nested resource routes.
Incremental reindex via file-watcher.
AI-generated per-method summaries stored on nodes (read summary first, file second).
Benchmark harness: grep-only vs graph-only Claude sessions on identical tasks.
Rails-specific: all ActiveRecord associations on a model.
Returns outgoing has_many/has_one/belongs_to/HABTM plus reverse-references (other models that point at this one).
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool returns association data but does not explicitly confirm it is read-only or disclose any side effects. The behavioral context is adequate but could be more explicit about safety.
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 two concise sentences: the first states the purpose, the second details the output. It is front-loaded and efficient with no fluff.
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?
Given the has output schema (though not provided) and simple single-parameter input, the description sufficiently explains the tool's function and output types. It covers the key aspects without needing examples.
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?
The input schema has a single 'model' parameter with no description. The description adds meaning by indicating it takes a model name, but does not provide format or examples. Value is added but limited, as the schema coverage is 0%.
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 tool is Rails-specific and enumerates the types of ActiveRecord associations returned, including outgoing and reverse-references. This is a specific verb-resource combination that distinguishes it from sibling tools like 'find_references' or 'graph_stats' which likely have different scopes.
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 implies usage for Rails models but does not explicitly state when to use this tool versus alternatives like 'find_references' or 'impact_of'. No exclusions or conditions are provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Functions that call name, transitively up to depth hops.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| depth | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full behavioral disclosure burden. It mentions transitive search with depth, which is useful, but omits safety traits like whether the operation is read-only or any permissions needed. The description adds moderate transparency.
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 a single sentence with no waste, front-loading the core action. Every word earns its place.
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?
Given that an output schema exists (handling return value documentation), the description adequately covers the tool's purpose and parameters. It lacks edge-case behavior (e.g., what if name not found) but is sufficient for basic use.
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 0%, so the description must add meaning. It explains the role of 'name' (the function to find callers of) and 'depth' (transitive hops), which clarifies the parameters. However, it does not specify the format of 'name' (e.g., function signature vs. identifier).
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 states the tool finds functions that call a given name transitively up to a depth, which is clear for a call-graph tool. However, it does not differentiate from siblings like 'find_references' or 'impact_of' which might also find callers.
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 when-to-use or when-not-to-use guidance is given. The description does not differentiate this tool from similar siblings such as 'find_references' or 'impact_of', leaving the agent without criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all definitions matching a simple name (functions/classes/methods).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden but only states it finds definitions. It does not disclose behavior like read-only nature, result limit, or handling of no matches. This is insufficient for an agent to understand side effects or constraints.
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 one concise sentence that effectively front-loads the verb and resource. While it could include more detail, there is no unnecessary text.
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?
Given the tool's simplicity (one parameter, no annotations) and the presence of an output schema, the description still lacks completeness. It omits usage context, parameter details, and behavioral specifics, leaving gaps for the agent.
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?
The schema has one required string parameter 'name' with 0% coverage. The description adds only that it is a 'simple name', without clarifying format, case sensitivity, or whether wildcards are allowed. The parameter's meaning remains vague.
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 tool finds definitions matching a simple name, specifying the resource (definitions) and examples (functions/classes/methods). It differentiates from siblings like find_callers and find_references, which focus on different queries.
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 implies usage when looking for definitions, but lacks explicit guidance on when to use it versus alternatives like find_callers or find_references. No when-not or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All inbound references to name (calls, imports, inheritance).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 indicates the types of references returned (calls, imports, inheritance) but does not clarify if the operation is read-only, or any potential performance implications like pagination. The behavior is typical for a reference finder, but more transparency would be beneficial.
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 a single concise sentence with no wasted words. It effectively communicates the tool's purpose and scope.
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?
Given the tool is simple (single parameter, no annotations), the description covers the key aspect: it finds all inbound references. With an output schema present, the need to describe return values is reduced. The description is fairly complete, though it could be slightly more explicit about the scope across different reference types.
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?
The single parameter 'name' has no schema description (0% coverage). The description adds meaning by stating that references are found for this name, but it lacks details such as required format, case sensitivity, or examples. Some compensation is provided but not complete.
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 specifies what the tool does: find all inbound references to a given name, including calls, imports, and inheritance. It distinguishes from sibling tools like find_callers or find_definition by specifying the scope of references.
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 implies usage for finding inbound references but does not explicitly state when to use it versus alternatives like find_callers or impact_of. No exclusions or conditional guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Counts of nodes/edges by kind — quick health check.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full burden. It indicates a read-only operation but does not disclose potential costs, scope, or what 'kind' means. The phrase 'quick health check' implies lightweight, but not explicitly.
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 a single sentence that is front-loaded and contains no unnecessary words. It efficiently conveys the tool's function and intent.
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?
Given zero parameters and an output schema, the description adequately states what the tool returns. However, it is vague about 'kind' and does not explain the scope (e.g., entire graph or current context). Acceptable but with gaps.
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?
There are zero parameters, and schema description coverage is 100%. The description does not need to add parameter information. Baseline of 4 for no parameters is appropriate.
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 tool provides counts of nodes/edges by kind, which conveys its core purpose. However, it does not explicitly differentiate from sibling tools like find_references or impact_of, though 'quick health check' implies a high-level summary versus detailed queries.
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 on when to use this tool versus alternatives. The phrase 'quick health check' vaguely suggests it is for overview, but there is no explicit when-to-use, when-not-to-use, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transitive callers — predict what may break if name changes.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| max_depth | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it finds transitive callers but omits details like whether results are exhaustive, if read-only, or auth requirements. Inadequate for a mutation-like analysis tool.
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?
Extremely concise (8 words) and front-loaded with key purpose. However, brevity sacrifices necessary detail for parameter understanding.
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?
Despite having an output schema, the description lacks details on how the tool works, meaning of 'transitive', and parameter semantics. Incomplete for a tool with two parameters and complex behavior.
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 0%. Description only mentions 'name' but not its nature (e.g., function name, identifier). 'max_depth' is completely unexplained, leaving agents to guess its purpose.
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 tool predicts transitive callers to assess breakage risk, using a specific verb 'predict' and resource 'callers'. It distinguishes from siblings like 'find_callers' (likely direct callers) by emphasizing transitivity.
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?
Implies usage for impact analysis but no explicit 'when to use' or 'when not to use' compared to alternatives. Lacks context like needing to run before changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summary of a single module: exports, imports, most-called internal symbols.
path is the file path relative to the indexed root.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 discloses a read-only operation (summary of module data) but lacks details on permissions, caching, or potential costs. It is adequate but minimal.
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?
Two sentences, no fluff. The description is front-loaded with purpose, followed by parameter explanation. Every sentence is necessary.
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?
With an output schema present, the description need not detail return values. It covers the tool's scope and parameter format sufficiently. Minor gap: no mention of scope (single module) but implied.
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?
The description adds context for 'path' beyond the schema (relative file path), which is helpful. With only one parameter and moderate coverage, it provides meaningful guidance.
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 tool provides a summary of a module, listing exports, imports, and most-called internal symbols. It distinguishes itself from siblings like find_callers and find_references by focusing on a high-level overview.
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 on when to use this tool versus alternatives. It does not indicate context or prerequisites for use, leaving the agent to infer from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rails-specific: HTTP routes that hit a controller (or controller#action).
Accepts a bare class ("UsersController"), fully qualified ("Api::V1::UsersController"), or qualified action ("Api::V1::UsersController#create"). Returns verb/url/handler.
| Name | Required | Description | Default |
|---|---|---|---|
| controller_or_action | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes input formats and output format but does not disclose whether the operation is read-only, has side effects, or requires authentication. The implied read behavior is not explicitly stated.
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 two sentences, front-loading the purpose and then detailing input formats and return structure. Every sentence is informative without redundancy.
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?
Given the output schema exists (though not shown), the description adequately covers input and output expectations. It lacks some behavioral context (e.g., read-only guarantee) but otherwise provides sufficient detail for a simple query tool.
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?
The input schema has 0% description coverage, providing only a title for the parameter. The description compensates by clearly explaining the accepted formats (bare class, fully qualified, or qualified action) with concrete examples, adding significant meaning beyond the schema.
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 tool's purpose: returning HTTP routes that hit a controller or controller#action. It explicitly specifies it is Rails-specific and describes the return format (verb/url/handler). This differentiates it from sibling tools which deal with code analysis and definitions.
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 mentions the tool is 'Rails-specific', giving context for when to use it (Rails projects). However, it does not explicitly state when not to use it or provide alternatives among sibling tools. No exclusions or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct aspect of code analysis: definitions, references, callers, impact, module overview, and Rails-specific associations/routes. No overlap in purpose.
All tool names follow a consistent snake_case pattern with a clear verb_noun or noun_of structure, making them predictable.
8 tools is well-scoped for a code analysis server, covering both general and Rails-specific functionality without bloat.
The set covers key analysis operations (definitions, references, callers, impact, module overview, routes, associations). A minor gap is the lack of a tool to list all modules without a specific path.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ground-truth code graph for your codebase: exact callers, callees, symbols & dependencies.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Samagra001/claude-code-graphdb'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
