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

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_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.

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. Accepts only a nonce; all bindings are server-owned and computed from stored state.

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

A3.9/5.0

Scored across 8 tools

Disambiguation2/5

commitlore_before_change and commitlore_guard have identical descriptions and appear to be the same tool under different names, creating a serious selection ambiguity. The remaining tools are distinct enough, but this duplicate pair prevents an agent from reliably choosing between them.

Naming Consistency3/5

All names share the commitlore_ prefix and use snake_case, which provides some coherence. However, the suffixes mix patterns: verb_noun for capture tools, bare verbs like query, adjectives like stale, and descriptive phrases like before_change and runtime_identity.

Tool Count5/5

Eight tools is well within the ideal range for a focused domain. The count covers runtime introspection, querying, advisory checking, and the prepare-verify-stage capture lifecycle without feeling bloated.

Completeness4/5

The main workflow is well covered: query records, check proposals, prepare/verify/stage captures, and identify stale records. The most notable gap is the lack of an explicit cancel or discard path for a prepared capture transaction, though this may be a minor operational concern rather than a critical dead end.

Maintenance

ActivityActive
ResponsivenessResponsive