aspark-graph
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| build_graphA | (Re)scan a repository and its .spark/ artifacts and persist the graph. Writes /.aspark-graph/ — this is the one MCP tool that writes. |
| get_nodeB | Look up a single node by its id (e.g. 'file:src/foo.py'). |
| story_traceB | Full thread of a user story: acceptance criteria (with their latest QA verdict), mapped plan tasks, and any best-effort code links. |
| impactA | Blast radius of a change: the stories and acceptance criteria that depend
on the given files (or the files in a git |
| gate_healthC | The aSPARK gate invariants as data: orphan tasks, unverified acceptance criteria, and open findings for a feature. |
| stalenessC | Report whether the built graph still matches the repo on disk (US-4). |
| find_nodesC | Find nodes whose id or name contains a substring, optionally by type. |
| get_neighborsC | Nodes within |
| shortest_pathC | An ordered path connecting two nodes, or an explicit 'no path' result. |
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 9 tools
Most tools are clearly distinct: get_node is exact-id lookup while find_nodes is substring search, and get_neighbors/impact/shortest_path are separated by adjacency vs. dependency impact vs. pathfinding. There is mild conceptual overlap between story_trace and gate_health, and between impact and get_neighbors, but the descriptions provide enough boundary clarity.
All names use snake_case, and several follow verb_noun (build_graph, get_node, find_nodes, get_neighbors), but others are concept-noun phrases (story_trace, gate_health, impact, shortest_path, staleness). The mix is readable but not a consistent naming convention.
Nine tools is a well-scoped set for a repository graph server: one write/build operation, multiple query modes, traversal, impact analysis, health checks, and staleness reporting. Each tool contributes a distinct capability without obvious bloat.
The surface covers the core graph lifecycle well: build/rescan, node lookup, substring search, neighbor traversal, shortest path, story tracing, gate health, impact, and repo freshness. Minor gaps exist, like no explicit raw edge listing or graph-level metadata query, but agents can complete the intended workflows.