Dependency Tracer MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HIE_READER_BIN | No | Path to the compiled hie-reader Haskell binary. Without it, Haskell indexing falls back to source parsing. | |
| DEP_TRACER_BACKEND | No | Storage backend: native (better-sqlite3), wasm (sql.js), or unset (auto: native first, fall back to wasm). | auto |
| DEP_TRACER_DB_PATH | No | SQLite database path. Set to a project-relative path (e.g. .dep-tracer/index.db) for per-project isolation. | ~/.dep-tracer/deps.db |
| DEP_TRACER_LOG_LEVEL | No | debug, info, warn, error. All logs go to stderr (stdout is reserved for MCP stdio). | info |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| index_codebaseA | Index a codebase to build the dependency graph. Supports Haskell and ReScript. Performs incremental indexing (only changed files) unless force_full is set. For Haskell, optionally uses hie-reader binary for rich type info; falls back to source parsing. |
| index_statusA | Get indexing status for all codebases or a specific one. Shows file count, symbol count, edge count, last indexed time. |
| trace_calleesA | Trace what a function/component depends on (outgoing edges). Shows all functions called, types used, and components rendered. Use this to answer: "What do I need to mock to test function X?" or "What is the full flow from this endpoint to the database?" |
| trace_callersA | Trace what depends on a function/component (incoming edges). Shows all callers, importers, and parent components. Use this to answer: "I changed function X, what tests need updating?" or "What entry points reach this code?" |
| trace_module_depsA | Trace module-level dependencies (coarser but always available). Shows which files/modules depend on which. |
| impact_analysisA | Given changed files or symbols, determine the full impact: what tests might break, what entry points are affected, what downstream consumers exist. |
| get_symbolA | Get detailed information about a specific symbol: definition location, type signature, direct callees, and direct callers. |
| get_module_symbolsB | List all symbols defined in a module/file: functions, types, components, exports. |
| search_symbolsA | Search for symbols by name pattern. Supports partial matching and * wildcards. Use when you know a function name but not its full module path. |
| get_test_contextA | Get everything needed to write tests for a function or module: the function itself, all its direct dependencies (what to mock), all its callers (usage examples), type definitions it uses, and file paths for all involved code. |
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 10 tools
Each tool has a distinct purpose: listing symbols, getting detailed info, tracing callers/callees, searching, impact analysis, indexing, and status. No ambiguity between them.
All tools follow a consistent verb_noun pattern (e.g., get_module_symbols, trace_callees, index_codebase). The naming is clear and predictable.
With 10 tools, the set covers the core functionality of dependency tracing without being bloated. Each tool seems necessary and well-scoped.
The tools cover indexing, symbol lookup, dependency tracing in both directions, impact analysis, and test context generation. Minor gap: no explicit tool to list all modules or files, but search_symbols and get_module_symbols partially cover it.