Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{}
resources
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 <kind> --json.

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 stale --json.

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 matched array does not guarantee the proposal avoids every ruled-out alternative.

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 active_decisions, verification_gaps, possible_revival_matches, guard_confidence and cache_key. Pass path alone for context. Pass proposal as well to also run the guard against that path's Ruled-out records; without it guard_confidence is "not-run" and possible_revival_matches is empty because nothing was checked, not because nothing matched. The guard is an experimental advisory: precision 44.8%, recall 22.0% on the 417-decision corpus. An empty possible_revival_matches does not guarantee the proposal avoids every ruled-out alternative.

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 repository; if your working directory is a linked worktree or another clone, pass repository to assert it and this refuses rather than binding to the wrong HEAD.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
commitlore-contextEvery active CommitLore record in this repository, in the schema `commitlore context --json` prints.

TDQS

A4/5.0

Scored across 8 tools

Disambiguation3/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityActive
ResponsivenessResponsive