SwiftKG MCP Server
SwiftKG MCP Server lets you query and analyze a Swift codebase's knowledge graph through semantic search, graph navigation, ranking, and snapshot comparison.
Run hybrid natural-language queries over Swift code and expand results through graph edges.
Extract source-grounded Markdown snippet packs for LLM ingestion.
Find callers and reverse relations such as CALLS, INHERITS, CONFORMS, and IMPORTS.
Inspect Swift type relationships: conformers, subclasses, extensions, declared conformances, and supertypes.
List the declared public/open API surface for a module path.
Fetch node details and edges by stable ID, and list or find nodes by path, kind, or name.
Get graph statistics and doc-comment coverage.
Compute centrality, module connectivity, framework/hub modules, and CodeRank rankings.
Explain a code node's role, location, callers, callees, and docs, or explain its rank components.
Rank query results with CodeRank-enhanced hybrid or personalized PageRank.
Find the definition at a file/line and run a full structural repository analysis.
List, show, and diff temporal snapshots to track codebase metrics over time.
Provides tools for building and querying a knowledge graph of Swift codebases, enabling semantic and structural search, type hierarchy analysis, conformance and extension discovery, and public API surface inspection.
Click on "Deploy 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., "@SwiftKG MCP Server How is error handling structured in the networking layer?"
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.
SwiftKG
Knowledge graph for Swift codebases -- deterministic AST extraction, hybrid semantic + structural search.
Overview
SwiftKG builds a queryable knowledge graph from Swift source using:
tree-sitter for deterministic, parser-level AST extraction (no LLM inference during indexing)
SQLite for the structural graph (nodes, edges, provenance)
sqlite-vec for the semantic vector index (embeddings via
BAAI/bge-small-en-v1.5)Hybrid retrieval: semantic seed → graph hop expansion → lexical re-ranking
It needs no Swift toolchain, no Xcode, and no buildable project. Point it at any checkout, on macOS or on Linux CI, and it indexes.
Related MCP server: mcp-sqlite-graph-memory
What Swift makes different
Three things about Swift are not cosmetic differences from the Python and TypeScript modules in this fleet, and they shape the whole graph.
Inheritance and conformance are written identically. : Base, Proto gives
no syntactic signal about which is which:
final class DiskStorage: Storage<Data> {} // superclass
struct Point: Equatable, Hashable {} // two protocols
class Storage<T>: NSObject, Repository {} // superclass, then protocolSwiftKG runs two passes. The first builds a repository-wide table of every
declared type and its kind; the second resolves each specifier against it, so
a protocol target becomes CONFORMS and a class or actor target becomes
INHERITS. When the target is external — NSObject, Codable, anything from
a dependency — it falls back to the language's own rule: only a class or actor
may have a superclass, and it must be written first.
There are no per-file imports within a module. Every file in a target sees
every other file's declarations without an import statement. That makes the
repository the correct resolution scope rather than an approximation of one,
so calls and type references resolve across files. A name declared twice
resolves to nothing rather than to an arbitrary one of the two — an honest
sym: stub beats a confidently wrong edge.
Extensions are a unit of authorship. A type's conformances and much of its
behaviour routinely live in an extension in a different file. Each extension
gets its own node and an EXTENDS edge to the type, with members qualified
under the type (Point.scaled), so swiftkg can answer "where is the rest of
this type" without losing where the code actually is. Since it is idiomatic to
write one extension per conformance, an extension's own ID carries its
conformance list (ext:…:Point+Codable) rather than colliding on the type name.
Swift also states access level with a keyword, so public / open /
internal / private is recorded as a fact rather than guessed from a naming
convention. The public-API report, the centrality penalty for private symbols,
and explain's reasoning about zero-caller declarations all read it directly.
Node types
Kind | Description |
| Every indexed |
| Class declaration |
| Struct declaration |
| Enum declaration |
| Protocol declaration |
| Actor declaration |
| Extension declaration |
| Free function at file scope |
| Function, initializer, deinitializer or subscript inside a type |
| Stored or computed property, enum case, or file-scope |
| Type alias, and |
| Unresolved import or call stub |
Edge types
Relation | Description |
| module → type/function, type → member |
| module → |
| function/method → function, method, or type initializer |
| class or actor → superclass |
| type or extension → protocol |
| extension → the type it extends |
Quick start
pip install swift-kg
# First-time setup (downloads model, builds graph, installs hooks, snapshots)
swiftkg init --repo /path/to/swift-repo
# Build the KG for a Swift repo
swiftkg build --repo /path/to/swift-repo
# Query
swiftkg query "networking layer"
swiftkg pack "request error handling" --hop 2
# Understand the repository
swiftkg analyze /path/to/swift-repo
swiftkg centrality --top 20
swiftkg explain "proto:Sources/Networking/Client.swift:HTTPClienting"build wipes and rebuilds; update upserts without wiping. The split is
deliberate — a rebuild is correct after renames or deletions, where an upsert
leaves phantom nodes behind, so the safe operation is the bare verb and the
surprising one has to be asked for by name.
MCP tools
swiftkg mcp --repo /path/to/swift-repo exposes 22 tools. Two exist only in
this module:
Tool | Purpose |
| Conformers, subclasses, extensions and declared supertypes of one type, together — for a Swift type these are one question |
| The declared |
The fleet's canonical five come first, under the same names on every KG
server: stats, query, pack, get_node, neighbors. The rest match the
other code-graph modules: callers, list_nodes, find_node, centrality,
bridge_centrality, framework_nodes, find_definition_at, analyze_repo,
explain, rank_nodes, query_ranked, explain_rank, snapshot_list,
snapshot_show, snapshot_diff. swiftkg mcp --manifest prints the live
list.
See docs/MCP.md for client configuration.
Snapshots & git hook
swiftkg snapshot save records graph metrics under .swiftkg/snapshots/, and
swiftkg install-hooks installs a pre-commit hook that keeps them current.
Alongside the shared metrics, SwiftKG records what actually characterises a
Swift codebase: counts by type kind, conformance and inheritance counts, and
extensions-per-type — how much behaviour is declared away from the type it
belongs to.
Snapshots, not per-node timestamps, are how a code KG answers temporal questions. Git already owns when the code changed.
Python API
from swift_kg import SwiftKG
with SwiftKG(repo_root="/path/to/swift-repo") as kg:
kg.build(wipe=True)
result = kg.query("networking layer", k=8)
pack = kg.pack("request error handling")
pack.save("context.md")
protocol_id = "proto:Sources/Networking/Client.swift:HTTPClienting"
kg.conformers(protocol_id) # every conforming type and extension
kg.subclasses(class_id) # direct subclasses
kg.extensions_of(type_id) # extensions, wherever they are declaredConfiguration
When the target repository has a pyproject.toml, SwiftKG reads
[tool.swiftkg]:
[tool.swiftkg]
include = ["Sources"] # top-level dirs to index (unset = all)
exclude = ["Vendor"] # extra dirs to skip at every depthMost Swift repositories have no pyproject.toml, which is fine: with no
config, everything is indexed. .build, .swiftpm, DerivedData, Pods,
Carthage, xcuserdata and *.xcodeproj / *.xcworkspace bundles are always
skipped.
Architecture
Swift source ─► tree-sitter ─► pass 1: symbol table
└► pass 2: NodeSpec / EdgeSpec
│
├─► SQLite (authoritative graph)
└─► sqlite-vec (semantic index)
│
hybrid query ◄────┘
│
CLI · MCP server · Python APIEverything below the extractor — persistence, indexing, hybrid retrieval,
snippet packing, snapshots — comes from
kgmodule-utils. This package
implements the Swift-specific layer and nothing else.
Status
The visualizers (swiftkg viz, viz3d, viz-timeline) are registered and
report that they are not yet available; see the CHANGELOG's Unreleased
section. Everything else is complete.
Author
Eric G. Suchanek, PhD — Flux-Frontiers
Citation
If you use SwiftKG in your research or project, please cite it:
Suchanek, E. G. (2026). SwiftKG: Semantic Knowledge Graph for Swift Codebases (Version 0.5.1) [Software]. Flux-Frontiers. https://doi.org/10.5281/zenodo.22759432
@software{suchanek_swift_kg,
author = {Suchanek, Eric G.},
title = {{SwiftKG}: Semantic Knowledge Graph for Swift Codebases},
version = {0.5.1},
year = {2026},
publisher = {Flux-Frontiers},
doi = {10.5281/zenodo.22759432},
url = {https://github.com/Flux-Frontiers/swift_kg},
}Full citation metadata in CITATION.cff.
License
Elastic License 2.0. See
LICENSE.
Available Tools
21 toolsanalyze_repoA
Run a full structural analysis of the indexed Swift repository.
Executes the 14-phase SwiftKG analysis pipeline — baseline metrics, CodeRank, fan-in/fan-out, module coupling, critical call chains, public API surface, doc-comment coverage, type hierarchy and conformance, insights, snapshot history, and SIR centrality — and returns the results as Markdown.
:return: Markdown-formatted analysis report.
Inputs: no named parameters. Returns: result
bridge_centralityA
Compute module connectivity: how many unique modules each module interacts with.
For well-modularized codebases, identifies orchestrator and hub modules that touch many other modules. Replaces betweenness centrality (which is meaningless when inter-module edges are zero).
Connectivity score = (unique modules called + unique modules calling this) / 30 + frequency / 50 Higher score = more complex coupling with other modules.
Scores are persisted to the centrality_scores table under the
module_connectivity metric for use by framework_nodes().
:param top: Number of top connectivity modules to return (default 20). :param include_imports: Whether to include IMPORTS in connectivity (default True). :return: Markdown-formatted ranking table of modules by connectivity.
Inputs: top, include_imports. Returns: result
callersA
Return all nodes that call a given node, resolving through sym: stubs.
Unlike query_codebase (which seeds on semantics and expands outward),
this tool performs a precise reverse lookup: it finds every caller of the
specified node, including cross-module callers that reference it via an
import alias recorded as a sym: stub.
The rel parameter accepts any edge relation, not just CALLS::
callers(node_id, rel="INHERITS") # find all subclasses
callers(node_id, rel="CONFORMS") # every type conforming to a protocol
callers(node_id, rel="IMPORTS") # find all importersTypical workflow::
# 1. Resolve the exact node ID
get_node("meth:Sources/Networking/Client.swift:HTTPClient.send")
# 2. Find all callers (production code only)
callers("meth:Sources/Networking/Client.swift:HTTPClient.send", paths="Sources/"):param node_id: Target node identifier, e.g.
cls:Sources/Networking/Client.swift:HTTPClient.
:param rel: Relation type to invert (default "CALLS").
:param paths: Comma-separated module path prefixes to include, e.g.
"Sources/" to exclude test callers.
Empty string (default) returns all callers.
:return: JSON with node_id, rel, caller_count, and
callers list of node dicts.
Inputs: node_id (required), rel, paths. Returns: result
centralityA
Compute Structural Importance Ranking (SIR) for the indexed codebase.
Runs a deterministic weighted PageRank over the sym-stub-resolved call graph. Edge weights are tuned per relation type (CALLS > INHERITS/CONFORMS/EXTENDS > IMPORTS > CONTAINS) and amplified for cross-module links; private symbols receive a post-convergence penalty. Scores are normalized to sum to 1.0.
Use this to:
Identify the most structurally critical functions, types, and protocols
Understand which modules are most depended upon
Prioritize code review, refactoring, or test coverage efforts
:param top: Maximum number of ranked entries to return (default 20).
:param kinds: Comma-separated node kinds to include: module, class,
struct, protocol, actor, function, method.
Empty string returns
all kinds. Ignored when group_by='module' (all kinds
contribute to module aggregation).
:param group_by: node (default) returns individual node rankings with
score, inbound edge count, and cross-module inbound count;
module aggregates node scores per module.
:return: Markdown-formatted ranking table.
Inputs: top, kinds, group_by. Returns: result
explainA
Return a natural-language explanation of a code node.
Given a node ID (e.g., meth:Sources/Networking/Client.swift:HTTPClient.send),
returns a markdown-formatted explanation that includes:
What it is: The node's kind, short description from its doc-comment
Where it lives: Module path and source location
What calls it: The callers (reverse call graph)
What it calls: The callees (functions/methods this node invokes)
Documentation: Full doc-comment if available
This is ideal for understanding the role and context of a specific node
without needing to read the full source code. Use pack_snippets()
to then retrieve the actual implementation.
:param node_id: Stable node identifier, e.g.
meth:Sources/Networking/Client.swift:HTTPClient.send.
:param limit: Maximum callers and callees to list (default 10). Pass 0
to list all.
:return: Markdown-formatted explanation ready for LLM consumption.
Inputs: node_id (required), limit. Returns: result
explain_rankA
Explain the CodeRank score components for a specific node.
Returns a Markdown report showing the node's structural position in the graph: how many nodes call it, import it, or inherit from / implement / extend it; its global CodeRank score; and, when a query is provided, its semantic relevance and proximity to the query seed set.
:param node_id: Stable node identifier, e.g.
meth:Sources/Networking/Client.swift:HTTPClient.send.
:param q: Optional query string. When provided, semantic score and
proximity to the query seed set are included in the report.
:return: Markdown-formatted explanation of the node's rank components.
Inputs: node_id (required), q. Returns: result
find_definition_atA
Find the code node whose definition spans a given file location.
Reverse-resolves a (file, line) pair to a graph node ID and returns the
same Markdown report as explain(). Useful when reading a file in an IDE
and wanting to understand the symbol at a specific line without constructing
a node ID manually.
Matches the innermost (most-specific) function, method, type, extension,
type alias, or enum whose lineno ≤ line ≤ end_lineno. Falls back to
the module node when no narrower match exists.
:param file: Module path as stored in the graph, e.g. Sources/Networking/Client.swift.
Leading ./ is stripped automatically.
:param line: Line number (1-indexed) within the file.
:return: Markdown explanation from explain(), or an informative error
message if no node spans that location.
Inputs: file (required), line (required). Returns: result
find_nodeA
Find graph nodes by name without knowing their full stable ID.
Case-insensitive match against name and qualname. Use when you know a function or class name from reading code and need its stable ID.
:param name: Function, type, or protocol name to search for. :param kind: Optional kind filter: module | class | struct | protocol | function | method | etc. :return: JSON array of matching node dicts.
Inputs: name (required), kind, limit. Returns: result
framework_nodesA
Identify framework-like (hub) modules using SIR + module connectivity.
A "framework node" is a module that is both:
Structurally important (high SIR/PageRank — central to the graph)
Highly connected (calls/imports many modules — orchestrator/hub role)
Framework score = 0.6 × normalized SIR + 0.4 × normalized connectivity, both auto-computed on first call. High-scoring modules are critical hubs: architecturally central AND complex in their interactions.
:param top: Number of top framework-like modules to return (default 20). :return: Markdown-formatted ranking table of framework nodes.
Inputs: top. Returns: result
get_nodeA
Fetch a single Swift node by its stable ID and render as Markdown.
Node IDs follow the pattern <kind>:<module_path>:<qualname>, e.g.
cls:Sources/Networking/Client.swift:HTTPClient or
meth:Sources/Networking/Client.swift:HTTPClient.send.
:param node_id: Stable node identifier. :param include_edges: If True, append outgoing edges and incoming callers. :return: Markdown-formatted node summary.
Inputs: node_id (required), include_edges. Returns: result
graph_statsA
Return node and edge counts by kind and relation as Markdown.
Call this first when engaging with a new Swift repo. Reports doc-comment coverage (fraction of functions/methods with doc-comment comments).
:return: Markdown summary with total counts, nodes-by-kind, and edges-by-relation tables.
Inputs: no named parameters. Returns: result
list_nodesC
List nodes filtered by module path prefix and/or kind.
:param module_path: Module path prefix filter (e.g. "Sources/Networking/Client.swift"). :param kind: Node kind filter: module | class | struct | enum | protocol | actor | extension | function | method | property | typealias. :return: JSON array of matching node dicts.
Inputs: kind, limit, module_path. Returns: result
pack_snippetsA
Hybrid query + source-grounded Swift snippet extraction.
Returns a Markdown context pack with ranked, deduplicated code snippets and line numbers — ready for direct LLM ingestion.
:param q: Natural-language query, e.g. "request error handling". :param k: Number of semantic seed nodes (default 8). :param hop: Graph expansion hops (default 1). :param rels: Comma-separated edge types to follow. :param context: Extra context lines around each definition (default 5). :param max_lines: Maximum lines per snippet block (default 60). :param max_nodes: Maximum nodes to include in the pack (default 15). :param min_score: Minimum semantic score for seed inclusion in [0, 1]. :param max_per_module: Maximum nodes per module (default 3; 0 disables). :param rerank_mode: 'hybrid' (default), 'semantic', or 'legacy'. :param rerank_semantic_weight: Semantic weight for hybrid mode (default 0.7). :param rerank_lexical_weight: Lexical weight for hybrid mode (default 0.3). :return: Markdown string with source-grounded code snippets.
Inputs: q (required), k, hop, rels, +8 more. Returns: result
public_apiA
List the declared public API surface.
Swift states access level with a keyword and SwiftKG stores it, so this is
a fact read out of the graph rather than a heuristic. Use it to review what
a module actually exposes, or to find public declarations that no longer
need to be.
:param module_path: Restrict to files under this path prefix. Empty
(default) covers the whole repository.
:param limit: Maximum declarations to return (1-1000).
:return: JSON with count and a declarations list, each carrying its
visibility.
Inputs: limit, module_path. Returns: result
query_codebaseA
Hybrid semantic + structural query over the Swift codebase graph.
:param q: Natural-language query, e.g. "request retry policy". :param k: Number of semantic seed nodes (default 8). :param hop: Graph expansion hops (default 1). :param rels: Comma-separated edge types to follow. :param max_nodes: Maximum nodes to return (default 25). :param min_score: Minimum semantic score for seed inclusion in [0, 1]. :param max_per_module: Maximum nodes per module (default 3; 0 disables). :param rerank_mode: 'hybrid' (default), 'semantic', or 'legacy'. :param rerank_semantic_weight: Semantic weight for hybrid mode (default 0.7). :param rerank_lexical_weight: Lexical weight for hybrid mode (default 0.3). :param format: 'json' (default) or 'markdown'. :return: JSON string or Markdown table.
Inputs: q (required), k, hop, rels, +7 more. Returns: result
query_rankedA
Rank query results using CodeRank-enhanced hybrid or personalized PageRank.
Combines semantic seed scores from the vector index with structural centrality and graph proximity to produce a final ranked list with explainability components.
Two modes are available:
hybrid(default): 0.60 × semantic + 0.25 × centrality + 0.15 × proximityppr: 0.70 × personalized PageRank + 0.30 × semantic
:param q: Natural-language query string.
:param k: Number of semantic seed nodes to retrieve (default 8).
:param mode: Ranking mode — "hybrid" (default) or "ppr".
:param top: Maximum ranked results to return (default 25).
:param rels: Comma-separated relations to include in the local graph.
:param radius: Graph expansion radius around seeds (default 2).
:param exclude_tests: Exclude test-path nodes (default True).
:return: JSON array of ranked result dicts with score components and
why explanation strings. sym: import stub nodes are
always excluded from the output.
Inputs: q (required), k, top, mode, +3 more. Returns: result
rank_nodesA
Compute global weighted CodeRank (PageRank) over the repository graph.
Builds a directed weighted graph from the SQLite store and runs weighted PageRank to identify the most structurally important nodes. Relation weights follow the CodeRank defaults: CALLS=1.0, IMPORTS=0.9, INHERITS/CONFORMS/EXTENDS=0.75. Test paths are excluded by default.
Optionally persists the scores into the node_metrics table under the
given metric name so they can be loaded at query time without recomputing.
:param top: Number of top-ranked nodes to return (default 25).
:param rels: Comma-separated relations to include in the graph
(default "CALLS,IMPORTS,INHERITS,CONFORMS,EXTENDS").
:param persist_metric: If non-empty, persist scores to node_metrics
under this metric name (e.g. "coderank_global").
:param exclude_tests: Exclude test-path nodes from the graph (default True).
:return: JSON array of ranked node dicts with node_id, score,
top_pct (e.g. "top 0.5%"), kind, qualname,
module_path, and rank fields.
Inputs: top, rels, exclude_tests, persist_metric. Returns: result
snapshot_diffA
Compare two codebase metric snapshots side-by-side.
Returns the full metrics dict for both snapshots and a computed delta (b − a) covering node and edge counts, plus per-kind node count and per-relation edge count deltas.
Typical workflow::
# 1. List available snapshots — note the 'key' field in each entry
snapshot_list()
# 2. Diff any two using the key= field values
snapshot_diff(key_a="abc1234ef...", key_b="def5678ab..."):param key_a: First (older) snapshot key — the key field from
snapshot_list() output (a tree-hash string).
:param key_b: Second (newer) snapshot key — the key field from
snapshot_list() output (a tree-hash string).
:return: JSON object with keys a (metrics + issues list for key_a),
b (metrics + issues list for key_b), delta (b − a),
node_counts_delta, and edge_counts_delta. Returns an
error dict if either snapshot is missing.
Inputs: key_a (required), key_b (required). Returns: result
snapshot_listA
List saved temporal snapshots of codebase metrics in reverse chronological order.
Each entry in the returned list contains a key (tree hash snapshot
identifier), branch, timestamp, version, and a summary of
key metrics (node count, edge count, doc-comment coverage) plus deltas vs. the
previous snapshot. Use the key field when calling snapshot_show()
or snapshot_diff(key_a=..., key_b=...).
Use this tool to answer questions like "how has the codebase grown?" or "when did doc-comment coverage improve?" or "show me only main-branch snapshots".
:param limit: Maximum number of snapshots to return (default 10; pass 0 for all).
:param branch: If provided, filter to snapshots from this branch only
(e.g. "main" or "develop").
:return: JSON array of snapshot metadata dicts, most recent first.
Inputs: limit, branch. Returns: result
snapshot_showA
Show full details of a specific codebase metrics snapshot.
Pass a snapshot key (tree hash) to retrieve that exact snapshot, or use
the special value "latest" (default) to retrieve the most recent one.
Snapshot keys are the key field returned by snapshot_list().
The returned object contains the full metrics dict (total_nodes, total_edges, meaningful_nodes, docstring_coverage, node_counts, edge_counts, critical_issues, complexity_median), the top hotspots, and deltas computed vs. both the previous and the baseline (oldest) snapshots.
:param key: Snapshot key to load, or "latest" for the most
recent snapshot (default "latest"). Keys are tree
hashes returned by snapshot_list().
:return: JSON object with full snapshot details, or an error dict if
the requested snapshot does not exist.
Inputs: key. Returns: result
type_hierarchyA
Return everything the graph knows about one Swift type's relationships.
Swift spreads a type across three relations that the sibling language modules do not have to separate, and answering "what is this type" means reading all three at once:
conformers — every type and extension conforming to it, if it is a protocol. This is the question about a protocol.
subclasses — every direct subclass, if it is a class or actor.
extensions — every
extensiondeclared on it, which in Swift routinely live in other files. "Where is the rest of this type" is a real question with a graph answer.conforms_to / inherits_from — what it declares for itself.
Calling callers() three times with three relations returns the same
facts; this returns them together, already labelled, because for a Swift
type they are one question.
:param node_id: Node ID of a class, struct, enum, protocol or actor, e.g.
proto:Sources/SampleKit/Storage.swift:Repository.
:return: JSON with node, conformers, subclasses, extensions,
conforms_to and inherits_from.
Inputs: node_id (required). Returns: result
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 21 tools
The tool set spans distinct areas (discovery, query, explanation, ranking, snapshots), but there is meaningful overlap within clusters: query_codebase, pack_snippets, and query_ranked all perform hybrid semantic/structural queries with different output formats, and centrality/rank_nodes/explain_rank all compute graph centrality. An agent could struggle to choose among these similar tools despite detailed descriptions.
Naming conventions are inconsistent. Several tools follow verb_noun (list_nodes, find_node, get_node, analyze_repo), but many are noun-only (callers, type_hierarchy, centrality, graph_stats), and the snapshot tools are reversed noun_verb (snapshot_list, snapshot_show, snapshot_diff). The mixed styles and inconsistent word order make the API harder to predict.
21 tools is on the heavy side. The server covers a broad domain (code graph query, ranking, snapshots, explanations), so many tools are justified, but consolidation of the overlapping ranking/query tools (query_codebase, query_ranked, pack_snippets; centrality, rank_nodes, explain_rank) would make the surface tighter and reduce cognitive load.
For a read-only code analysis server, the surface is remarkably complete: discovery (list/find/get), query (semantic/structural), reverse lookup (callers), type relationships (type_hierarchy), public API, stats, multi-faceted centrality, and temporal snapshots. Minor gaps exist (e.g., no direct edge query between two nodes, no file-level summary beyond find_definition_at), but these are workable and do not block typical workflows.
Maintenance
Related MCP Connectors
Shared context for your codebase: a hosted code knowledge graph over MCP. Free plan, OAuth sign-up.
Repository knowledge graph MCP server for codebase understanding and debugging.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Related MCP Servers
AlicenseNot gradedqualityBmaintenanceBuilds a semantic graph of codebases across 38 languages and exposes 42 MCP tools for structured code understanding, search, and impact analysis.152Apache 2.0- AlicenseNot gradedqualityDmaintenanceProvides a dynamic SQLite-backed code knowledge graph for AI assistants, with MCP tools to inspect symbols, find dependency paths, and analyze code structure across multiple languages.MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI coding agents to query a local, continuously updated symbol graph of a codebase, providing ranked search, caller/callee exploration, dependency paths, and git-diff impact analysis through MCP tools.14 npmApache 2.0
- AlicenseNot gradedqualityCmaintenanceEnables people and AI agents to query local code repositories as graphs through stdio MCP tools for project listing, search, dependency tracing, impact analysis, bridge detection, node inspection, bounded code reading, and optional LSP definition/reference lookups.MIT