Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
GTAGS_MCP_ROOTNoThe project root directory. Default is the server's working directory. Override with --root or GTAGS_MCP_ROOT environment variable.
GTAGS_MCP_LABELNoForce a specific parser label for GNU Global. Options: 'default' (native-only), 'pygments' (plugin-everything), etc. Override with --label or GTAGS_MCP_LABEL environment variable.

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": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
find_definitionA

Go to definition: where a C/C++ symbol (function, struct, macro, typedef, enum) is defined, with a usage summary — the best first query.

Each definition carries its #if/#ifdef guard stack (several guarded definitions = a config choice) and ctags kind/signature. The summary gives reference and file counts, the hottest files and the EXPORT_SYMBOL* variant. Macro-generated symbols resolve ("sys_read" -> SYSCALL_DEFINE3(read, ...), DEFINE_SPINLOCK names), and definitions the index parser missed are recovered from their EXPORT_SYMBOL* site — both flagged resolved_via. A miss suggests similarly named symbols.

JSON: results are {symbol, path, line, col, kind, typeref, scope, signature, guard, snippet} records; the envelope adds definition_count, guard_variants, reference_count, file_count, top_files, exported.

Args: symbol: Exact symbol name, e.g. "tcp_v4_rcv". case_insensitive: Match ignoring case (skips the usage summary). active_config: Kernel .config path or macro list like "CONFIG_SMP,BITS_PER_LONG=64,!CONFIG_DEBUG"; drops definitions whose guard stack is definitely false under it (count reported as config_filtered). Unknown macros never drop anything.

find_referencesA

Find all references / usages of a C/C++ symbol — every call and use site.

Only real reference sites from the index, each with its #if/#ifdef guard stack. Very widely used symbols (more than 200 sites, e.g. kmalloc) come back grouped by file with counts — see where usage concentrates, then narrow with path_prefix. Symbols with no in-tree definition (libc calls, some variables) work too, flagged "fallback": "symbol_usages".

Args: symbol: Exact symbol name. case_insensitive: Match ignoring case. active_config: Kernel .config path or macro list; drops references whose guard stack is definitely false under it (config_filtered). group_by: "auto" (default: per-file counts above 200 references), "line" (always individual sites) or "file" (always per-file counts). path_prefix: Only references under this directory, e.g. "fs/ext4".

get_symbol_bodyA

Read a symbol's source: the full body of a function, struct or macro definition, without reading the whole file.

Extracts only the definition's lines, so a one-screen function never costs a 5000-line file read. Macro-generated and parser-missed (EXPORT_SYMBOL-recovered) definitions resolve too, flagged resolved_via. JSON results: {path, line, body} items.

Args: symbol: Exact symbol name. max_definitions: Return at most this many bodies when the symbol is multiply defined (default 3).

find_callersA

Who calls this function? Callers / call hierarchy / incoming calls, deduplicated per calling function with call counts.

Each reference is mapped to its enclosing function and shown with the source line of its first call site, so there is nothing to re-grep. The highest signal-to-noise "who uses this?" view for impact analysis; iterate it to walk the caller graph upward. JSON results: {caller, path, sites, call} items (call = source of the first site).

Args: symbol: Exact symbol name whose callers you want.

find_calleesA

What does this function call? Callees / outgoing calls of a function.

Shows a function's dependencies without reading any file: call sites are detected in its body and verified against the index, split into in-tree functions (with locations) and external/unresolved names. Macro-generated and parser-missed (EXPORT_SYMBOL-recovered) definitions resolve too, flagged resolved_via. JSON results: {in_tree: [{symbol, path, line}], external: [names]}.

Args: symbol: Exact name of the function to analyze.

reachabilityA

Call path / call chain: does FROM transitively call TO, and through which functions?

Use this instead of chaining find_callers rounds when the question is "can this function end up in that one?". BFS over the caller graph returns the SHORTEST chain, each hop with the call site's file:line. JSON results: {path_found, hops, depth, nodes_explored}; hops run from from_symbol to to_symbol. Static analysis cannot follow function pointers (ops structs, callbacks).

Args: from_symbol: The caller end ("can this reach ..."). to_symbol: The callee end ("... this function?"). max_depth: Longest chain to consider, in calls (1-12, default 8).

list_file_symbolsA

Outline of one source file: every function, struct and macro it defines (document symbols), with kind, signature and #ifdef guards.

Use this INSTEAD of reading a file when you only need its API surface.

Args: file_path: Source file, relative to the project root or absolute.

update_indexA

Refresh the code index synchronously after editing files — the guaranteed-freshness barrier.

Query tools refresh the index automatically in the background, so results can lag very recent edits by a few seconds. Call this right after editing files when the very next query must see the changes.

Args: full: Rebuild the index from scratch instead of refreshing it incrementally (rarely needed — large branch switch, suspected corruption).

Prompts

Interactive templates invoked by user choice

NameDescription
impactWhich functions does a git diff affect, and who calls them?
explainWhat is this function/struct/macro, how does it work, who uses it?

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 8 tools

Disambiguation4/5

Most tools have clearly distinct purposes — definition lookup, reference enumeration, caller/callee analysis, body extraction, file outline, and reachability — and the verbose descriptions reinforce those boundaries. However, find_callers and find_references both surface call sites (one deduplicated by enclosing function, one listing every use), and find_definition overlaps with get_symbol_body enough that an agent could misselect without reading closely.

Naming Consistency4/5

Four tools follow a clean find_<plural-noun> pattern (find_callers, find_definition, find_references, find_callees), and list_file_symbols, get_symbol_body, and update_index all use verb_noun as well. The bare noun 'reachability' breaks the pattern, and the mix of 'list'/'get'/'find' verbs is slightly varied, but the overall convention is predictable and readable.

Tool Count5/5

Eight tools is well-scoped for a C/C++ code navigation server. Each tool provides a distinct index query — definition, references, callers, callees, call path, symbol body, file outline, and index refresh — with no apparent redundancy, so every tool earns its place.

Completeness4/5

The surface covers the core navigation lifecycle thoroughly: definition resolution, reference enumeration, incoming/outgoing call analysis, transitive reachability, body extraction, file-level outlines, and index maintenance. The notable gap is that symbol lookup requires exact names — there is no prefix/fuzzy search for similarly named symbols, even though find_definition's description hints at such a fallback rather than providing a tool for it.

Maintenance

ActivityMaintained
ResponsivenessNo issues