code-index
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | Path to the repository to index |
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 |
|---|---|
| get_contextA | Token-cheap structural summary rooted at a file or folder path (workspace-relative). Structural facts only (names, signatures, line ranges) — no docstrings, use get_details for those. Increase depth to drill from folder -> file -> function/class detail. |
| get_callersA | Every function that calls |
| get_dependenciesA | Every file (workspace-relative path) that |
| get_class_hierarchyA | Transitive ancestors and descendants of a class (a node id from get_context/get_details). |
| get_detailsB | Full structural facts for one node (a node id from get_context), plus its full stored docstring if the source actually has one. |
| query_sparqlA | Prefix: code: http://example.org/code-ontology# Node IRIs: urn:code:<repo/relative/path.py> (module), urn:code:<path.py>::<Qualified.Name> (class/function). Classes: code:Module, code:Class, code:Function Datatype properties: code:name, code:startLine, code:endLine, code:signature, code:returnType, code:description, code:contentHash Object properties: code:defines (parent->child), code:belongsTo (child->parent, inverse of defines), code:reads, code:writes, code:raises, code:decoratedBy, code:imports, code:calls, code:inherits (imports/calls/inherits objects may be a string Literal if unresolved, or a NamedNode if Pyright resolved the target — both may be present) Named graphs: urn:code:graph:<path.py> holds one file's direct/structural triples; urn:code:graph:inferred holds the fully materialized transitive closure (R+, includes direct edges) of calls/imports/inherits across the whole repo. Every query runs with use_default_graph_as_union=True, so a plain WHERE clause with no GRAPH block already searches across every named graph — add an explicit GRAPH urn:code:graph:inferred { ... } block only when you specifically want the transitive/materialized edges rather than a single file's direct ones. |
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 6 tools
Each tool has a distinct purpose: callers, class hierarchy, structural context, dependencies, detailed node info, and SPARQL queries. There is no overlap or ambiguity between them.
Most tools follow the 'get_' prefix pattern (get_callers, get_class_hierarchy, etc.), but query_sparql deviates slightly by using 'query' instead. The naming is still clear and predictable overall.
With 6 tools, the set is well-scoped for a code indexing server. Each tool provides essential functionality without redundancy or excess.
The tools cover structural analysis (context, details) and relational queries (callers, hierarchy, dependencies). The SPARQL endpoint allows arbitrary queries, filling most gaps. Minor missing direct tool for listing all modules, but query_sparql can handle that.