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 clearly distinct scopes: log_change is the only writer; diff is entity-scoped history, history is cross-entity, changeset groups by id, and search is full-text. The main ambiguity is diff vs. blame — blame returns only the newest event and adds a status field, but it is effectively the first row of diff, so an agent could reasonably pick either for 'what changed most recently.'
The naming mixes three conventions: git-style single-word verbs (diff, blame, search), bare nouns (history, changeset), and descriptive snake_case phrases (log_change, prior_attempts, stale_decisions). The styles are individually readable and the git-inspired cluster ties the read tools together, but there is no single predictable verb_noun pattern across the set.
Eight tools is well within the ideal 3-15 range and each tool earns its place in the change-logging domain: one writer, four retrieval views (per-entity, latest, global, changeset-grouped), one search, one pre-edit decision helper, and one maintenance/review tool. The count feels tightly scoped with no obvious redundancy or bloat.
The surface fully covers the domain's lifecycle: log_change handles all event types (including rename, reject, revert, and supersede), and the read side provides entity-scoped history, latest state, cross-entity filters, changeset reconstruction, full-text search, pre-edit attempt lookup, and stale-decision review. The append-only design intentionally omits update/delete, which the descriptions explicitly justify, so there are no real dead ends for the stated purpose.