Kivgraph
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
} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_by_intentB | Which symbols a plain-language description likely names, and the files to open. |
| find_cross_repo_consumersC | Consumers of a symbol in other repositories, exact uses kept apart from package-level dependencies. A language server stops at its workspace. |
| find_referencesA | Who calls or references a symbol. Type-checked, not name-matched: grep cannot separate homonyms, and an empty answer means nobody calls it. A bare name suffices: an ambiguous one returns its candidates, so no lookup call first. |
| find_symbolA | Where a symbol is declared, by name, qualified name, prefix or substring. Narrow with kind, repo and path_prefix. |
| get_blast_radiusB | What a change to this symbol reaches, by repository, package, depth and relation kind. Grep does not follow a chain. |
| get_file_outlineA | Declarations under a path, grouped by file, with kind, signature and range. Use it for a package; one small file is cheaper to read. |
| get_sourceB | The code of several symbols in one call. Prefer it to reading each range: no line numbers, one call across files and repositories. |
| get_symbolB | One symbol's package, signature, visibility and line range, by stable key or by repository, path and qualified name. |
| graph_statusA | The published generation: counts, provenance, and whether a repository moved since it was indexed. Call it when an answer looks stale. |
| index_projectA | Registers projects and rebuilds the graph once, after explicit user approval. Pass every project in one call: a rebuild costs the whole corpus. It never writes inside the source projects. |
| list_repositoriesC | The repositories the published graph covers, with the commit each was indexed at. |
| trace_dependenciesB | What this symbol reaches outward, bounded by depth. Pass to for the route by which it reaches one named symbol. Grep does not follow a chain. |
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 12 tools
Each tool targets a distinct query type—semantic search, identifier search, symbol metadata, reference/consumer lookup, forward/reverse graph traversal, and index administration—but get_blast_radius vs trace_dependencies and find_references vs find_cross_repo_consumers are close enough that an agent must read descriptions carefully to pick correctly.
Most tools follow a verb_noun pattern (find_*, get_*, list_repositories, index_project, trace_dependencies), forming clear families for search and retrieval. graph_status is the notable outlier, reading as a noun phrase rather than a verb-object command.
Twelve tools is well within the ideal range for a code-intelligence server, and each tool earns its place: symbol search, references, cross-repo consumers, dependency/impact analysis, source/outline retrieval, and index administration. None of the tools feels redundant.
The surface covers discovery, metadata, source/outline retrieval, references/consumers, dependency and blast-radius analysis, plus index status and registration, so core workflows are well supported. Minor gaps exist around arbitrary file-content reads and project removal or re-indexing semantics, but agents can work around them.