CommitLore
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 | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| commitlore_runtime_identityA | Report the exact CommitLore entrypoint, package root, version and index schema this MCP server executes. |
| commitlore_queryA | Active CommitLore records for a path: the constraints, ruled-out alternatives and warnings recorded in git history. Same answer as |
| commitlore_staleA | Records that are no longer carrying their weight: superseded, past a date-form Expires:, or flagged for review by a condition-form one. Same answer as |
| commitlore_guardA | Check a proposal against the Ruled-out records for a path before acting on it. Returns every record whose alternative matches, with the reason it was rejected. Experimental advisory: precision 44.8%, recall 22.0% on the 417-decision corpus. An empty |
| commitlore_before_changeA | Everything recorded about a path, before editing it: the active decisions, the gaps in what could be verified, and any ruled-out alternative a proposal would revive. Returns |
| commitlore_prepare_captureA | Prepare a capture transaction: computes binding conditions (HEAD, staged diff, tree, policy hash), generates the prompt contract for the agent to use, and persists a phase:"prepared" pending transaction. Returns the nonce needed for verify and stage. The prompt carries the end of the transcript rather than all of it; transcript_window says which lines, numbered as the whole transcript numbers them. Verification still reads the whole transcript, so quote only what the prompt shows you. The transaction binds to THIS server's checkout, returned as |
| commitlore_verify_captureA | Verify a capture draft against the transcript and diff that were hashed at prepare time. Evidence citations are checked mechanically (verbatim match); fabricated quotes are discarded. Stores the verified result in the pending transaction for stage to consume. |
| commitlore_stage_captureA | Stage a verified capture transaction: advances the pending record from verified to staged, stamps expires_at (staged_at + 5 minutes), and makes it eligible for the prepare-commit-msg hook. All bindings are server-owned and computed from stored state; the only inputs are the nonce and, optionally, the receipt your verification was issued. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| commitlore-context | Every active CommitLore record in this repository, in the schema `commitlore context --json` prints. |
TDQS
Scored across 8 tools
The capture lifecycle tools (prepare/verify/stage) are clearly separated by phase, and stale/runtime_identity are distinct. However, before_change, query, and guard overlap: before_change already runs the guard when a proposal is supplied, and query also returns ruled-out alternatives for a path. The descriptions help, but an agent could easily pick the wrong one for a pre-edit context lookup.
All tools share the commitlore_ prefix and use lowercase snake_case, which is a clear and consistent pattern. The capture tools use verb_noun (prepare_capture, verify_capture, stage_capture), but before_change, stale, and runtime_identity are stylistic deviations, so the set is mostly consistent rather than fully uniform.
Eight tools is well-scoped for this server's purpose: three for the capture pipeline, three for reading/guarding context, plus stale and runtime identity. Each tool has a place and the set feels neither bloated nor thin.
The core workflow is covered: retrieving records/context, checking proposals, and the prepare/verify/stage capture pipeline. Minor gaps exist—such as no direct way to update, dismiss, or resolve stale records—but these are workable and may be intentionally outside the MCP surface.