git-reflog-archaeologist-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GIT_ARCHAEOLOGY_ROOT | Yes | The root directory that the selected repository must stay inside. |
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 |
|---|---|
| reflog_signalsA | Summarize local reflog activity by count and age bucket without returning ref names, hashes, subjects, paths, or remotes. |
| recovery_signalsA | Count unreachable Git object types and recovery hints without returning object IDs, messages, paths, or contents. |
| stash_signalsA | Summarize local stash age buckets and count without returning stash messages, refs, hashes, or paths. |
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
Each tool targets a distinct Git data source: reflog, unreachable objects, and stash. The descriptions clearly separate their inputs and outputs, leaving no ambiguity about which tool to choose for a given task.
All tool names follow the exact same pattern of '<domain>_signals', creating a predictable and uniform naming scheme. This consistency makes it easy to infer the purpose of any tool in the set.
With only three tools, the server is tightly scoped to its 'archaeologist' purpose. Each tool covers a different aspect of Git history recovery, and none feel redundant or extraneous.
The server covers the main recovery-related signals: reflog activity, unreachable objects, and stash state. While other signals like branch or tag history could be added, the core recovery workflow is well represented and no critical gaps are apparent.