Selvedge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SELVEDGE_DB | No | Path to the SQLite database file. Overrides project and global defaults. | |
| SELVEDGE_QUIET | No | Set to '1' to suppress warnings about using global database fallback. | |
| SELVEDGE_LOG_LEVEL | No | Logging level for the Selvedge server. One of DEBUG, INFO, WARNING, ERROR. | WARNING |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| log_changeA | Record a change to a codebase entity. Call this immediately after making any meaningful change. The event is
written to the local SQLite store and returned with its assigned id and
timestamp. If the reasoning fails the quality validator (empty, too
short, or a generic placeholder), or the entity_path doesn't match the
usual shape for its entity_type, the result includes a Renames: pass the new path in Rejections: when you consider an approach and decide against it WITHOUT
writing the change, record the verdict with Use Superseding a reverted decision: when a reverted change becomes correct
again (the constraint that killed it no longer holds), do NOT delete or
edit history — log with On validation failure (invalid change_type, missing entity_path,
|
| diffA | Get change history for a codebase entity, newest first. Supports prefix matching — e.g. 'users' returns all events for the users
table and any users.* column. Each event carries a derived
|
| blameA | Most recent change to an entity — what changed, when, who, why. Like |
| historyA | Filtered change history across all entities, newest first. Combine |
| changesetA | All events that share a Use to reconstruct the full scope of a feature or task across multiple
entities. If the changeset has no events, returns
|
| searchA | Full-text search across entity paths, diffs, reasoning, and agents. Useful for questions like 'what changes were made for the billing feature?', 'which columns were added by cursor?', or 'show everything related to authentication'. |
| prior_attemptsA | Prior change attempts on an entity, each with an inferred outcome. Call this BEFORE editing an entity. If the same change was tried before
and reverted, you get the prior Each result is a change event plus the trail fields: Conservative by design — |
| stale_decisionsA | Decisions due for a revisit — expired, past their date, or with a triggered stale condition. Three deterministic rules. Expiry-based ( Each result is the change event plus |
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 8 tools
Most tools have clear, distinct purposes: logging changes, querying history, searching, and finding stale decisions. However, `diff` (entity history) and `history` (filtered history across entities) overlap somewhat—both return change history, differing mainly in scope and filtering. `blame` is distinct (latest change per entity) and `prior_attempts` is distinct (outcome-focused), but the overlap between diff/history could cause occasional misselection.
Tool names are mostly two-word lowercase verbs or nouns (log_change, prior_attempts, stale_decisions), but the pattern is inconsistent: some are verb_noun (log_change, stale_decisions), others are single nouns (diff, blame, history, changeset, search). This mix of action-oriented and entity-oriented names breaks a strict pattern, though each name is still readable and intuitive.
With 8 tools, the server is well-scoped for its domain (change logging and history management). Each tool serves a distinct purpose—recording events, querying history at different granularities, searching, proactive checks, and maintenance. No tool feels redundant, and the count is within the ideal range, making the surface manageable without overwhelming an agent.
The tool set covers the full lifecycle: logging changes (log_change), retrieving history (diff, history, blame), reconstructing changesets, searching, checking prior attempts before editing, and flagging stale decisions for revisit. It even supports renames, rejects, reverts, and supersedes, showing thorough coverage of decision evolution. No obvious missing operations like deleting events (likely intentionally immutable), and the stale_decisions tool closes the loop on maintenance, so the surface feels complete.