LayerMap
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LAYERMAP_CACHE | No | Directory where LayerMap keeps its maps. Defaults to ~/Library/Caches/layermap on macOS, or $XDG_CACHE_HOME/layermap or ~/.cache/layermap on Linux. | |
| LAYERMAP_JAVA_HOME | No | Path to a JDK 21 or later used to analyze Java projects. Without a JDK found through LAYERMAP_JAVA_HOME, JAVA_HOME, PATH, Homebrew or SDKMAN, Java files are listed but have no declarations or calls. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| project_explore_mapA | Use this before grep or reading files to answer what calls a function or method, what changing it affects (callers traced up to entry points such as HTTP routes, handlers, jobs and commands), what it calls, and what a directory or file contains: one call returns the callers or callees up to 8 levels deep, with file paths and line numbers, for TypeScript, JavaScript, Go, Python and Java. Read the static project map, zooming from the whole project to one declaration. path "." or a directory lists modules, module imports, external packages and its files: with exported declarations when the listing is small, as file names and line counts by directory when larger, and as modules only when very large. Start here to see what exists before searching or reading. A file path lists its declarations and members, imports, importers and top-level statements. A file path with name (or Container.member), optionally narrowed by its start line, or with a line alone, shows that declaration's calls, callers (including uses as a value), writes, heritage, decorators and members, aggregated per related declaration with @line sites; closures and locals are folded into their named container. depth also expands the related declarations hop by hop: up to 8 in one direction, which traces callers up to entry points (INCOMING) or callees down (OUTGOING), and up to 3 for BOTH. To find what a change affects, select the declaration with direction INCOMING and a depth up to 8, continue from any NOT EXPANDED declarations the view names, then confirm the entry points in source. Test files and standard-library call targets are hidden and counted by default; includeTests and includeUnresolved show them. Read source at the printed line ranges. The map is static: calls through an interface, type or base member continue to the members it links as implementations (dispatches to, dispatched from), while trace stops, possible callers by name (calls of a same-named member on a receiver of unknown type), framework wiring and unresolved targets need source reading, and a missing relationship does not prove absence. When a page reports more entries, continue with offset and otherwise unchanged arguments. |
| project_search_mapA | Use this to find where a function, method, class or type is declared, by name or by words in its name, path or documentation, before exploring its callers with project_explore_map. Find declarations and files whose names, paths or source documentation match query terms. ANY (default) matches any term, ALL requires every term, LITERAL matches the exact text. Results are ranked by relevance and grouped by file with the declaration name, kind, 1-based line range and matched fields. Zoom into a result with project_explore_map({path,name}) or read its line range in the file. This is not a full-text search and does not prove absence; search the source text itself for exact text. Continue with offset and unchanged conditions. |
| project_find_referencesA | Use this to list every place a declaration is used (calls, imports, re-exports, reads and writes), compiled from current source: more complete than searching for its name. Compute usages of a mapped declaration from current source, including aliases, re-exports and non-call references. Select it with symbol {path,name,line?} as printed by project_explore_map or project_search_map (line is its start line when names repeat), or with an entityRef or locator {path,start,kind}. Broader and more expensive than the cached callers in project_explore_map; file or unsupported declarations may lack a reference target. path and kinds filter usage locations before paging. objects contains compact declarations; targetRef and reference ownerRef identify them. Read a reference at its line range. A file that several compiler contexts read (such as packages of one workspace) lists its references once per context, each with that context's configPath. Continue with nextCursor and unchanged conditions, including after an empty partial page. Filtered exhaustion and missing results do not prove absence. |
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 3 tools
Three tools map to distinct phases—locate declarations (search), map structure/callers (explore), and enumerate all usages (find_references)—but explore_map is a broad multi-modal tool whose cached caller tracing overlaps with find_references. Descriptions explicitly differentiate cached vs. computed references and search vs. exploration, so confusion is limited.
All names use snake_case with a consistent project_ prefix and a clear verb_noun structure (explore_map, search_map, find_references). There are no mixed conventions or vague names.
Three tools is compact yet covers the core navigation operations of search, exploration, and reference lookup. The count is on the low end because explore_map is overloaded, but it is not too thin for the purpose.
The surface covers declaration search, structural/call exploration, and reference enumeration, with no major lifecycle gaps for a static code map. Direct source retrieval and exact full-text search are intentionally out of scope and left to external tools, which agents can work around.