repograph
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_repository_graphA | Scan a local repository and return its architecture graph as JSON: one node per source file (id, layer, cluster, in/out degree, lines of code), import edges between files, nested directory clusters, and metrics (totalFiles, totalEdges, density, couplingFactor, deadCodeCount, foldedUtilityCount). Use it to understand how a codebase is organised, find hub files, or feed graph data into further analysis. Use query_impact_path instead when you only need the callers of one file, and generate_architecture_html when a human wants a visual map. Every call performs its own fresh static scan of |
| generate_architecture_htmlA | Scan a local repository and write a single self-contained HTML file with an interactive architecture map: compound boxes per directory, nodes coloured by heuristic layer, click-to-highlight callers (cyan) and dependencies (red), fuzzy search, collapsible directories and a minimap. Use it when a person wants to look at or share the architecture; use scan_repository_graph when you need the data as JSON, or query_impact_path for the blast radius of one file. Returns { success: true, filePath, nodeCount } where filePath is the absolute path of the written file, which you can open in a browser. Every call performs its own fresh static scan of |
| query_impact_pathA | Scan a local repository and report which files would be affected by changing one file: a breadth-first search over reverse import edges. Returns { changedFile, directDependents, transitiveDependents: [{ id, depth }], affectedClusters, blastRadius } where depth 1 means a direct importer, affectedClusters lists the directories touched, and blastRadius counts unique affected files excluding the changed file. Use it before editing, renaming or deleting a file to see who depends on it; use scan_repository_graph when you need the full graph, or generate_architecture_html for a visual. Every call performs its own fresh static scan of |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool produces a clearly different artifact: full graph JSON, a rendered HTML visual, or a reverse-dependency blast radius for one file. Descriptions explicitly cross-reference each other ('use X when you need Y'), so misselection is very unlikely.
All three names follow a strict verb_noun snake_case pattern (scan_repository_graph, generate_architecture_html, query_impact_path) with unambiguous verbs.
Three tools is on the lean side but each covers a genuinely distinct output mode (data, visualization, targeted analysis) with no filler. The narrow scope is intentional and coherent rather than anemic.
The surface covers the core lifecycle: extract graph, export it, and analyze impact of a change, including error recovery hints for unknown files. Minor gaps exist (e.g. no tool to query a single node's details or filter/cluster views without pulling the whole graph), but the full graph output makes these workable.