Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 path; no prior scan is required. Reads the local filesystem only, executes nothing, and sends nothing over the network. Supports TypeScript/JavaScript, Python, Go and Rust; external packages are dropped, test files are excluded, and layer labels (entry/business/data/util/unknown) are filename heuristics, not semantic judgements.

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 path; no prior scan is required. The HTML embeds the repository file paths and graph data, so treat it as repository information when sharing. The page loads pinned Cytoscape.js libraries from a public CDN when opened; nothing else leaves the machine.

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 path; no prior scan is required. If changedFile is not found, the result is an error that lists the closest matching file ids so you can retry. Static analysis only: dynamic or computed imports and custom path aliases may be missed, and external packages are not tracked.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 3 tools

Disambiguation5/5

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.

Naming Consistency5/5

All three names follow a strict verb_noun snake_case pattern (scan_repository_graph, generate_architecture_html, query_impact_path) with unambiguous verbs.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues