Detects HTTP calls made using Axios, enabling analysis of frontend-to-backend communication.
Detects Express backend routes, handlers, and middleware, allowing mapping of API endpoints.
Detects FastAPI route definitions and handlers for backend analysis.
Detects Flask route definitions and handlers for backend analysis.
Detects React components and their relationships, including imports and render hierarchy.
Detects React Router route definitions, enabling frontend route analysis.
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., "@code-graph-mcp where does LoginPage land in the backend?"
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.
Local code-intelligence MCP server for mono-repos. It indexes your repo once into a knowledge graph — packages, components, frontend routes, HTTP calls, backend routes, handlers — and lets any MCP client (Claude Code, Cursor, Codex CLI, OpenCode…) query structure directly instead of grepping and re-reading files on every question.
Ask "where does LoginPage land in the backend?" and get
LoginPage → POST /api/auth/login → auth.login in one tool call, from a graph
that's already in memory. No file reads, no grep round-trips.
Agents burn most of their tokens re-discovering structure: listing directories, grepping for usages, opening five files to trace one request path. This server front-loads that discovery into a single index pass and then answers structural questions from memory, with output engineered to be cheap:
Compact line-oriented output — no pretty-printed JSON, no prose padding.
Hard token budgets per response (default ~2k tokens, tunable per call)
with …+N more (refine query) truncation instead of overflow.
Path compression — repo-relative paths, common prefixes stripped in lists.
Incremental re-index — content-hash manifest; unchanged files are never reparsed.
Savings tracking — repo_summary reports how many tokens of raw file
reads the session avoided.
Zero query-time I/O — every tool answers from in-memory indexes; only
reindex touches disk.
Related MCP server: code-graph-mcp
Layer | Detected |
Packages | npm workspaces, any |
Frontend | React Router routes ( |
HTTP calls |
|
Backend | FastAPI ( |
Cross-layer | frontend call ↔ backend route matching by method + normalized path, |
Parsing is regex/heuristic (deliberately: fast, zero native deps). It won't catch every dynamic pattern — that's the tradeoff for indexing thousands of files in milliseconds with two pure-JS dependencies.
github:dorkian/code-graph-mcpvs@dorkian/code-graph-mcp? Thegithub:form tells npx to install straight from https://github.com/dorkian/code-graph-mcp — it works the moment the repo is public, no npm account involved.@dorkian/code-graph-mcpis the package's name on the npm registry and only works afternpm publish; once published, you can use either interchangeably (npm installs are faster since they're cached and versioned).
# Claude Code — writes .mcp.json AND installs the companion skill
npx -y github:dorkian/code-graph-mcp install claude-code --repo .
# Cursor — writes .cursor/mcp.json
npx -y github:dorkian/code-graph-mcp install cursor --repo .
# anything else — prints ready-to-paste config for Claude Desktop, Codex CLI, …
npx -y github:dorkian/code-graph-mcp installThat's it — restart your client and ask "where does LoginPage land in the backend?"
Paste this into Claude Code, Cursor, Codex, or any coding agent with shell access, from inside the repo you want indexed:
Install the code-graph-mcp server in this repo:
1. Run: npx -y github:dorkian/code-graph-mcp install claude-code --repo .
(if this isn't Claude Code, run `npx -y github:dorkian/code-graph-mcp install`
and apply the printed config for the client you are instead)
2. Add `.codegraph/` to .gitignore if it isn't there.
3. Run: npx -y github:dorkian/code-graph-mcp --repo . --index
and show me the node/edge counts it reports.
4. From now on, prefer the code-graph MCP tools (repo_summary,
find_component_relations, map_frontend_to_backend, search_symbols,
impact_of_change, visualize_graph) over grep/read_file for questions
about repo structure, and call reindex after you edit files.Step 4 is a summary of the bundled skill — Claude Code users get the full version automatically at .claude/skills/code-graph/SKILL.md.
git clone https://github.com/dorkian/code-graph-mcp.git
cd code-graph-mcp && npm install
node bin/code-graph-mcp.js --repo /path/to/your/repoThe graph lives at <repo>/.codegraph/ — add it to your repo's .gitignore.
Pre-warm the cache (e.g. in CI or a git hook):
code-graph-mcp --repo . --index # incremental
code-graph-mcp --repo . --index --full # rebuild from scratch{
"mcpServers": {
"code-graph": {
"command": "npx",
"args": ["-y", "github:dorkian/code-graph-mcp", "--repo", "."]
}
}
}Then copy skills/code-graph/ into .claude/skills/ (the install claude-code command does both).
{
"mcpServers": {
"code-graph": {
"command": "npx",
"args": ["-y", "github:dorkian/code-graph-mcp", "--repo", "${workspaceFolder}"]
}
}
}{
"mcpServers": {
"code-graph": {
"command": "npx",
"args": ["-y", "github:dorkian/code-graph-mcp", "--repo", "/abs/path/to/repo"]
}
}
}[mcp_servers.code-graph]
command = "npx"
args = ["-y", "github:dorkian/code-graph-mcp", "--repo", "/abs/path/to/repo"]Any other MCP client: it's a plain stdio server — run
node bin/code-graph-mcp.js --repo <path> and speak MCP over stdin/stdout.
Claude's custom connectors only accept remote MCP servers: Claude connects
to your server URL from Anthropic's cloud, not from your machine, so a local
stdio process can't be added directly — the server must be reachable on the
public internet over Streamable HTTP. That's what --http mode is for:
# on your VPS, next to a checkout of the repo you want indexed
npx -y github:dorkian/code-graph-mcp --repo /srv/my-monorepo \
--http --port 3333 --auth-token "$(openssl rand -hex 24)"Put it behind your reverse proxy with TLS (Caddy example):
graph.yourdomain.com {
reverse_proxy 127.0.0.1:3333
}Then in Claude: Settings → Connectors → Add custom connector and paste
https://graph.yourdomain.com/mcp/<your-token>The token-in-URL form exists exactly for this: the connector UI takes a plain
URL (or OAuth), so the secret rides in the path; API/CLI clients can send
Authorization: Bearer <token> instead. Keep in mind what you're exposing —
the graph reveals your repo's structure (routes, endpoints, file names), so
treat the URL like a password, rotate the token if it leaks, and never run
--http without a token on anything internet-facing. Run it as a systemd
service and add a cron/git-hook --index call to keep the graph fresh after
pushes.
Who can use your hosted URL — and what they get. Anyone you share
https://graph.yourdomain.com/mcp/<token> with can add it as a custom
connector in their own Claude (Settings → Connectors → Add custom connector;
available on all plans — Free accounts can add one custom connector). But be
clear about the model: one running instance indexes one repo on your
server, and every connected user queries that same shared graph. It is
not multi-tenant — users can't point your instance at their own codebases.
Host it to demo the tool or to give a team a shared brain for one codebase;
for their own repos, users run their own instance (stdio locally via the
install command, or --http on their own box).
Tool | Purpose | Key params |
| Packages, deps, FE/BE routes, counts, session token savings |
|
| Everything related to a component/route: children, parents, hooks, endpoints, imports |
|
| Full chain |
|
| Mermaid/DOT slice: |
|
| Fuzzy find any node by name/path — replaces grep for "where is X" |
|
| Blast radius: transitive dependents of a node or file |
|
| Refresh graph; incremental by default |
|
Every tool accepts max_tokens (response budget) and, where lists appear,
detail: "compact" | "full".
Example output (map_frontend_to_backend, name: "LoginPage"):
LoginPage -> POST /api/auth/login -> POST /api/auth/login (services/api/app/auth.py) -> auth.loginExample diagram (visualize_graph, kind: "fe-to-be"):
graph LR
n1(("route /login")) --> n2["LoginPage"]
n2 -- calls --> n3["POST /api/auth/login"]
n3 -- hits --> n4[/"POST /api/auth/login"/]
n4 -- handled by --> n5[["fn login"]].codegraph/graph.json — versioned node/edge lists, loaded into in-memory
Maps (by id, name, file, endpoint path) at startup; a ~1k-file repo loads in
well under a second. .codegraph/manifest.json — sha1 per indexed file,
drives incremental re-index and deleted-file pruning. Corrupted or missing
graph files trigger a clean full re-index, never a crash.
npm install
npm test # 57 unit assertions against a bundled fixture mono-repo,
# an MCP smoke test speaking real JSON-RPC over stdio,
# and an HTTP smoke test covering --http mode + token authThe fixture under test/fixture/ is a miniature mono-repo (React app, FastAPI
service, Express service) exercising every detection path including
include_router alias resolution and template-literal endpoints.
Credentials never leave your machine, so push it yourself:
cd code-graph-mcp
git init && git add -A && git commit -m "code-graph-mcp v0.2.0"
git branch -M main
git remote add origin https://github.com/dorkian/code-graph-mcp.git
git push -u origin main
# optional: publish to npm so npx works
npm login
npm publish --access publicMIT © dorkian
Given a component or route name, return everything related: child components it renders, parents that render it, hooks/stores used, endpoints it calls, and file import relationships. Use instead of grepping for usages.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | component or route name, e.g. LoginPage or /login | |
| detail | No | compact (default) = terse line output; full = expanded lists | |
| max_tokens | No | response token budget (default 2000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It lists what the tool returns but does not mention non-destructive behavior, error handling, or any side effects. The description implies a read-only operation but does not confirm auth needs or rate limits.
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 with no fluff. The first sentence front-loads the purpose and expected output. The second sentence provides a usage guideline. Every sentence 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 the complexity (3 params, no output schema), the description provides a comprehensive list of relationship types. However, it does not describe the return format (e.g., JSON structure) or how results are structured. With no output schema, a more detailed explanation of the output would improve completeness.
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 coverage is 100%, so baseline is 3. The description adds value for the 'name' parameter by explaining it includes component or route names with examples. For 'detail' and 'max_tokens', it adds little beyond the schema; 'max_tokens' simply says 'response token budget' which is already in 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: given a component or route name, return related elements. It uses specific verbs like 'return' and lists concrete outputs (children, parents, hooks/stores, endpoints, imports). It also distinguishes itself from the common alternative 'grepping for usages'.
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 gives clear guidance on when to use: when you need to find relations of a component or route. It also explicitly suggests using this tool instead of grepping. However, it does not compare to sibling tools like 'search_symbols' or 'impact_of_change', nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a component, handler, endpoint, or file path, list everything that depends on it (directly and transitively, up to depth N). Use before refactors and when debugging 'what breaks if I change this?'.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | node name or repo-relative file path | |
| depth | No | ||
| max_tokens | No | response token budget (default 2000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses transitive behavior up to depth N, but omits performance implications, auth needs, or whether results are real-time. Adequate but not thorough.
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, front-loaded with key action, no wasted words. Efficiently conveys purpose and usage.
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?
No output schema, so description should explain return format. It says 'list everything', but doesn't specify structure (e.g., list of nodes, paths, depth levels). Missing details on max_tokens truncation behavior. Adequate but incomplete for agent invocation.
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 coverage is 67%, so baseline 3. Description adds context to 'depth' parameter via 'up to depth N', but doesn't add significant meaning beyond schema descriptions for 'name' and 'max_tokens'.
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?
Description clearly states verb 'list' and resource 'dependencies', specifies input types (component, handler, endpoint, file path), and distinguishes from siblings like find_component_relations and map_frontend_to_backend.
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?
Explicitly says 'Use before refactors and when debugging what breaks if I change this?', providing clear context for when to use, though no exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trace the full chain Component/Route -> HTTP call -> backend route -> handler function. Accepts a frontend name (LoginPage), a route (/login), or an endpoint path (/api/login) and works from either end. Use for 'where does X land in the backend?' questions.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | component name, frontend route, or endpoint path | |
| max_tokens | No | response token budget (default 2000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions inputs and directionality but does not disclose details like matching exactness, handling of multiple matches, performance implications, or whether it requires network access.
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 with no wasted words. First sentence states the action, second gives examples and use case. Highly structured and front-loaded.
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?
The description covers purpose, inputs, and use case well. However, it does not mention what the output looks like (e.g., a list of chain steps), which is important for an agent to interpret results. Given no output schema, this gap affects completeness.
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 coverage is 100% with descriptions, but the tool description adds examples ('LoginPage', '/login', '/api/login') and clarifies that it works from either end, providing context 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 traces the full frontend-to-backend chain, specifying inputs like component name, route, or endpoint. It uses a specific verb ('trace') and resource ('full chain'), distinguishing it from siblings.
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 explicitly says 'Use for where does X land in the backend?' and provides examples of acceptable inputs. It implies the context of use but does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refresh the graph. Incremental by default (only changed files reparsed); pass full:true to rebuild from scratch. Call after significant code edits.
| Name | Required | Description | Default |
|---|---|---|---|
| full | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It explains the two modes (incremental and full) but does not disclose whether the operation is safe, reversible, or has side effects beyond updating the graph.
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 with no wasted words. The key action and parameter usage are front-loaded, making it easy to parse.
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 optional parameter, no output schema), the description covers the purpose and usage adequately. Could mention return value or effect on state, but not essential.
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 has one boolean parameter with no description (0% coverage). The description adds meaning by specifying that `full:true` triggers a full rebuild, which 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 it refreshes the graph and explains incremental vs full rebuild. It distinguishes from sibling tools that focus on relations or analysis, though could be more explicit about the graph's context.
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?
Explicitly states when to call ('after significant code edits') and how to use the `full` parameter. No mention of when not to use, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
High-level overview of the indexed repo: packages, dependency highlights, frontend routes, backend routes, node/edge counts, and session token-savings stats. Call this FIRST for any structural question instead of listing directories.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | compact (default) = terse line output; full = expanded lists | |
| max_tokens | No | response token budget (default 2000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Mentions 'session token-savings stats' hinting at cost tracking, but does not disclose caching, auth needs, or side effects. Adequate but not thorough.
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 concise sentences. Front-loaded with main purpose, no wasted words.
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?
Covers what the tool returns (packages, routes, stats) and notes token-savings. No output schema, but description is sufficient for a summary tool. Could mention it returns text.
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 coverage is 100%, so baseline is 3. Description adds no extra parameter-specific guidance beyond what schema already provides.
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 'high-level overview' and lists specific content (packages, routes, stats), distinguishing it from directory listing. The verb 'Call' implies retrieval.
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?
Explicitly says 'Call this FIRST for any structural question instead of listing directories,' providing clear context. Could be improved by comparing to siblings like find_component_relations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fuzzy search any indexed node (components, routes, endpoints, handlers, files, packages) by name or path. Use instead of grep/find for 'where is X defined?'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| types | No | ||
| max_tokens | No | response token budget (default 2000) |
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 describes fuzzy search and lists indexed node types, implying a read-only, non-destructive operation. However, it lacks details about result format, pagination, or performance characteristics, which would enhance 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 extremely concise: two sentences with no redundant information. Every word adds value, and the key information is front-loaded.
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 presence of sibling tools like find_component_relations and impact_of_change, the description sets appropriate context for a search tool. However, it lacks details about output format, sorting, or behavior when the query is empty. For a search tool with four parameters and no output schema, more completeness would be beneficial.
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 only 25%, meaning most parameters lack descriptions. The tool description does not explain how to use 'types', 'limit', or 'max_tokens'. For example, it does not clarify that 'max_tokens' sets a response token budget. This leaves the agent underinformed about parameter usage.
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 performs fuzzy search over indexed nodes (components, routes, etc.), and distinguishes itself from grep/find by explicitly stating 'Use instead of grep/find for 'where is X defined?'. This provides a specific verb-resource combination and differentiates from alternative tools.
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 explicitly suggests using this tool instead of grep/find for finding definitions. It implies a clear usage context. While it doesn't list exclusions or mention sibling tools, the context is adequate and the provided alternative is concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a Mermaid (default) or Graphviz DOT diagram for a slice of the graph: kind 'component-tree' (render hierarchy under a component) or 'fe-to-be' (frontend-to-backend flow). Paste the Mermaid block directly into chat to render it.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| name | Yes | root component/route/endpoint for the slice | |
| format | No | ||
| max_nodes | No | ||
| max_tokens | No | response token budget (default 2000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits fully. It describes the return format and the two kinds, but does not disclose any side effects, authorization needs, or rate limits. The read-only nature is implied but 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-loaded with the core purpose and parameters, followed by a practical usage tip. Every sentence earns its place with no 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?
With 5 parameters, no output schema, and no annotations, the description should provide more depth. It explains the output format and kinds but omits details on 'max_nodes' behavior and the exact nature of the returned diagram. The practical tip helps, but there is room for improvement.
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 coverage is 40%, but the description adds meaning for 'kind' (explains the two options) and 'format' (states default). It does not add info for 'max_nodes' or 'max_tokens' beyond the schema. The added value for key parameters warrants a score above the baseline.
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 it returns a Mermaid or Graphviz DOT diagram for a graph slice, with explicit kinds 'component-tree' and 'fe-to-be'. This distinguishes it from sibling tools like 'find_component_relations' and 'map_frontend_to_backend' which perform different operations.
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 on when to use (for visual graph slices) and a practical tip to paste the Mermaid block into chat. It does not explicitly state when not to use or compare with alternatives, but the sibling list and distinct purpose imply appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.1find_component_relationsimpact_of_changemap_frontend_to_backendreindexrepo_summarysearch_symbolsvisualize_graphEach tool has a clearly distinct purpose: finding relations, impact analysis, frontend-to-backend mapping, reindexing, repo summary, symbol search, and visualization. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., find_component_relations, impact_of_change, map_frontend_to_backend). The naming is predictable and intuitive.
With 7 tools, the set is well-scoped for a code graph analysis tool. Each tool serves a necessary role without redundancy or bloat.
The tools cover key operations: search, retrieval, impact analysis, mapping, visualization, and reindexing. A minor gap is direct access to file content or diff capabilities, but the set is comprehensive for its stated purpose.
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.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dorkian/code-graph-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
