What can you do with this server?

Selvedge is a local MCP server that captures and queries the "why" behind code changes — recording structured change events with agent reasoning and surfacing prior attempts and stale decisions so AI agents don't repeat rejected approaches. * log_change — append a change event (add, remove, modify, rename, revert, reject, supersede, …) with entity path, reasoning, diff, constraint, stale_when, changeset, and optional expiry/revisit metadata. * diff — get change history for an entity or dotted prefix, newest first, with each event’s superseded_by link. * blame — most recent change on an exact entity plus derived decision status (active/reverted/reopened) and superseding context. * history — filtered change history across all entities, with time windows (15m, 7d, ISO dates), entity/project/changeset filters, and pagination. * changeset — retrieve all events grouped under a feature/task slug (e.g. add-stripe-billing). * search — full-text substring search across entity paths, diffs, reasoning, and agent fields. * prior_attempts — before editing, look up prior tried → reverted → reopened attempts on an entity (exact or fuzzy), including confidence levels and outcome reasoning, to avoid repeating dead ends. * stale_decisions — list decisions due for revisit: expired expiry conditions, past revisit dates, or stale_when conditions matched by later changes — all deterministic and locally evaluated.

Which integrations are available for this server?

Allows change events to be linked as observability metadata in Datadog stack traces for richer debugging context. Allows change events to be linked as observability metadata in Sentry stack traces for richer debugging context.

de en es ja ko ru zh

Selvedge

by masondelan

Overview Schema Source Related Servers Discussions Admin

Python

Local

Long-term memory for AI-coded codebases — including what was already tried and rejected.

Line attribution tells you who wrote something. Selvedge tells your agent what not to write next: the approaches this codebase already tried, reverted, and why. It's a git blame for AI agents, for the why rather than which model touched which line — captured live, by the agent, as the change happens, so nothing downstream has to guess at it.

Selvedge is a local MCP server. AI coding agents (Claude Code, Codex, Copilot, Cursor, Gemini CLI and Windsurf) call it as they work to log structured change events with reasoning. Your data stays in a SQLite file under .selvedge/ next to your code.

Local-first by default, team-server by choice, zero-LLM always.

Six months ago, your AI agent added a column called user_tier_v2. You don't know why. git blame points to a commit from claude-code with a generated message that says "Update schema." The session that made the change is long gone — and so is the prompt that produced it.

With Selvedge, you run this instead:

$ selvedge blame user_tier_v2

  user_tier_v2
  Changed     2025-10-14 09:31:02
  Agent       claude-code
  Commit      3e7a991
  Reasoning   User asked to add a grandfathering flag for legacy free-tier
              users during the pricing migration. Stores the original tier
              so we can backfill discounts without touching billing history.

That reasoning was captured by the agent in the moment — written into Selvedge from the same context that produced the change. Not inferred from the diff afterward by a second LLM. Not a hand-typed commit message.

Who Selvedge is for

Selvedge has two audiences. Same tool, same pip install, same SQLite file under .selvedge/. Different scale of pain.

Teams running long-term, AI-coded codebases. When the project is big enough that you (or someone else) will touch it again in six months, twelve months, three years — but most of it was written by an agent whose context evaporated the day each PR shipped. git blame tells you what changed. Selvedge tells you why — even after the agent session, the prompt template, the developer who asked for it, and the model version are all long gone. This is the original use case: production codebases, schema decisions, migrations, dependency changes that need an audit trail that survives turnover.

Solo developers using Claude Code on everyday projects. Side projects, weekend builds, the small internal tool you keep poking at. You don't need enterprise governance — you just need to remember why you (or your agent) did the thing you did yesterday, last week, last sprint. Run selvedge init once. Add four lines to your CLAUDE.md. From then on, selvedge blame is muscle memory — a way to talk to your past self when your past self was an LLM.

If you've ever come back to your own AI-built project and thought "what was this for again?", Selvedge is the missing piece.

Related MCP server: claude-engram

The problem

Human-written code leaks intent everywhere — commit messages, PR descriptions, inline comments, the Slack thread that preceded it. AI-written code doesn't. The agent has perfect clarity about why it made each decision, but that context lives in the prompt and evaporates when the conversation ends.

Six months later, your team is debugging a schema decision with no trail. git blame tells you what changed and when. It can't tell you why.

Selvedge captures the why — live, by the agent itself, as the change is made. The diff is git's job. The why is Selvedge's.

What's new in v0.3.14

Explicit seven-day lookups work as documented.

The MCP prior_attempts tool now accepts window_minutes=10080, matching its seven-day default. Previously, sending that value explicitly failed validation because the time window incorrectly shared the 1,000-result pagination cap. The allowed window is 1–10,080 minutes; result limits remain capped at 1,000. No new dependencies, migrations or MCP tools.

What's new in v0.3.13

Keep the review context with a recorded rejection.

Session-start summaries show when a decision has expired or needs manual review, including in the rejection section.
Superseded decisions leave the revisit list without hiding unrelated decisions on the same path. History stays intact; reopening remains explicit.
Feedback and correction guide: how reports become product decisions, and how to reopen a mistaken rejection using supersede.

Where Selvedge fits

AI agents call Selvedge as they work. Selvedge captures the why into a durable, queryable store and emits it back out — as Agent Trace records for cross-tool readers, as observability metadata that links into Sentry/Datadog stack traces, and as compliance artifacts for SOC 2 and EU AI Act audits.

Selvedge does not replace git (line-level what/when), PR review tools (review-time quality), agent observability (LLM call traces), or general-purpose code-host AI features. It sits between them — the provenance-as-first-class-citizen layer that everything else references.

How Selvedge compares

There's a fast-growing "git blame for AI agents" category. Here's where Selvedge fits — and where it deliberately doesn't.

	Rejected paths	Reasoning source	Granularity	Mechanism	Grouping	Storage
Selvedge	Queryable — `prior_attempts` returns tried → reverted → re-opened	Captured live, by the agent in the same context that produced the change	Entity — DB column, table, env var, dep, API route, function	MCP server — agent calls it as work happens	Changesets — named feature/task slugs across many entities	SQLite, zero deps
OpenLore	Purged — `rejected` is an inactive status, dropped from the queryable store after each decision sync (the annotation survives in the synced spec markdown)	Derived — tree-sitter static analysis of code state, plus commit-gated decision notes	AST node (18 languages + 12 IaC)	MCP server — one-time index + commit-time certificates	Call-graph edges	SQLite graph in `.openlore/`
AgentDiff (sunilmallya)	None	Inferred post-hoc by Claude Haiku from the diff at session end	Line	Claude Code lifecycle hooks → local daemon	Session/task	JSONL on disk
AgentDiff (codeprakhar25)	None	ed25519-signed cross-agent provenance	Line	Per-agent editor hooks + git hooks (sign at commit)	None	Signed traces in git refs
Origin	None — `rework` flags reverted AI code post-hoc, without rationale	Prompt receipts, captured live per turn	Line	Agent lifecycle hooks + git post-commit hook	None	Git notes + sessions branch
Git AI	None	Attribution metadata	Line	Agent-invoked checkpoint → Git notes at commit	None	Git notes
BlamePrompt	None	Prompt receipts — prompt, cost, tools; no stated rationale	Line	Agent-lifecycle hooks + post-commit hook	None	Git notes

Why "rejected paths" matter — the one that isn't copyable. The expensive failure isn't forgetting why a column exists. It's an agent confidently re-implementing something the team already killed for a good reason, six months after everyone who knew that left the context window. None of the line-attribution tools above surface rejected paths at all, and it isn't a feature gap they can close in a release — a line-oriented store has no notion of an entity that persisted across a try → revert → retry cycle. See docs/demos/prior-attempts.md.

Why determinism matters. Selvedge's reasoning is the agent's own intent, written from the same context window that produced the change. There is no model anywhere in the storage or retrieval path, so the same query returns the same answer today and in two years, across model versions. Tools that infer reasoning post-hoc are running a second LLM that never saw the original prompt: what it produces is paraphrase, and re-running it can produce different categories for the same change. As a Hacker News commenter put it about a competing approach, "grep won't find your commit because you rejected 'oauth-library'… unless there is deterministic enforcement" (0x457).

Determinism alone is no longer a separator — OpenLore is deterministic-native too, and says so. The compound that separates is append-only testimony: reasoning the agent wrote itself, kept in a store where a rejection is a first-class record rather than an inactive status to be swept up.

Why "entity-level" matters. Most tools attribute lines. Selvedge attributes things you actually search for: users.email, env/STRIPE_SECRET_KEY, api/v1/checkout, deps/stripe. The first question after git blame is usually "what's the history of this column", not "what's the history of lines 40–48 of users.py".

Why "captured live" matters. Not a differentiator on its own — every tool here claims some flavour of it — but it's the mechanism that makes the reasoning trustworthy. Writing at the moment of the change, from the context that produced it, is the reason there's no second model in the path to hallucinate an explanation. An empty reasoning field is itself an honest signal: the agent didn't have one.

Comparison current as of 2026-08-05; OpenLore at v2.1.8 / 265★, verified against its source. Corrections welcome as an issue.

Why "changesets" matter. A Stripe billing rollout touches the users table, two new env vars, three new API routes, one dependency, and four functions across the codebase. Tag every event with changeset:add-stripe-billing and you can pull the entire scope back later — even if the original PR was broken into eight smaller ones over a month.

Selvedge ↔ Agent Trace. Agent Trace is an open AI code-attribution wire format published by Cursor (RFC, Jan 2026). Its original GitHub home went 404 in August 2026 and the multi-vendor momentum behind it has faded, but the spec and schema still resolve at agent-trace.dev, frozen at v0.1.0. Since v0.3.9, selvedge export --format agent-trace emits Agent Trace v0.1.0 records and selvedge import --format agent-trace reads them back — a portable, documented interchange format for file/line AI attribution, with reasoning and entity-level provenance carried in each record's dev.selvedge metadata. The mapping is in docs/agent-trace-interop.md; Selvedge vendors the schema and has no runtime dependency on the upstream project.

Quickstart

Claude Code — install the plugin (recommended)

Two commands, inside Claude Code. No prior pip install — the plugin bootstraps the server itself via uvx (or pipx):

/plugin marketplace add masondelan/selvedge
/plugin install selvedge@selvedge

That's the whole agent-facing surface in one step:

the MCP server — 8 tools (log_change, prior_attempts, blame, diff, history, changeset, search, stale_decisions);
a skill that tells the agent when to call them — before editing a tracked entity, after any substantive change;
the PreToolUse enforcement hook — schema/migration edits are blocked until prior_attempts has been checked this session, with the prior reasoning in the block message;
slash commands — /selvedge:status, /selvedge:blame <entity>, /selvedge:history, /selvedge:prior-attempts <entity>.

The store (.selvedge/selvedge.db) creates itself on the first logged change. Two optional extras stay CLI-side: the post-commit hook that stamps each event with its commit hash (selvedge install-hook), and — if you want the selvedge command on your own shell PATH — pip install selvedge, which the launcher then prefers over uvx for an exact pinned version.

Plugin or selvedge setup for Claude Code? Pick one. Both wire the MCP server; running both registers it twice. The plugin is the lighter path and the one that updates itself. If you're on the plugin and only want the post-commit commit-hash stamping, run selvedge install-hook on its own.

Choose your coding agent

With uv installed:

uv tool install --upgrade selvedge
selvedge demo
cd your-project
selvedge setup --agent codex

Use codex, claude-code, cursor, copilot, gemini or windsurf. Repeat --agent for multiple tools, or omit it to detect installed agents. Prefer pip? Use python -m pip install --upgrade selvedge in a virtual environment. The selvedge-server executable must be on your editor's PATH; launch the editor from that environment or use the executable's absolute path in its MCP config.

Setup asks before changing files, backs up existing content, installs MCP and agent instructions, initializes the project, and offers a Git post-commit hook. For Codex it writes .codex/config.toml and AGENTS.md; Gemini CLI gets .gemini/settings.json and GEMINI.md; Copilot gets .vscode/mcp.json and .github/copilot-instructions.md. Custom Codex TOML entries require manual reconciliation, even with --force.

Restart your agent in the project and approve Selvedge's tools if prompted. Codex must trust the project to load project-scoped configuration. Ask the agent:

Use Selvedge to record one approach we considered and rejected in this project. Include why, and what would change our mind. Then look it up with prior_attempts.

Start a new session and look up the same entity to verify that the decision carries forward. MCP access does not automatically capture every decision: the installed instructions guide the agent to use it. Session delivery and enforcement hooks are currently Claude Code integrations.

For CI bootstrap or devcontainer.json postCreateCommand:

selvedge setup --non-interactive --yes

Verify the wiring — open a second terminal in the same project:

selvedge watch

Make any change in your AI tool — add a column, rename a function, add an env var. selvedge watch should print the new event within a second of the agent calling log_change. If nothing arrives, run selvedge doctor for a single-command health check that tells you which step is silently broken.

Query your history:

selvedge status                        # recent activity + missing-commit count
selvedge diff users                    # all changes to the users table
selvedge diff users.email              # changes to a specific column
selvedge blame payments.amount         # what changed last and why
selvedge history --since 30d           # last 30 days of changes
selvedge history --since 15m           # last 15 minutes ('m' = minutes)
selvedge changeset add-stripe-billing  # all events for a feature/task
selvedge search "stripe"               # full-text search
selvedge stats                         # log_change coverage report (per-agent)
selvedge import migrations/            # backfill from migration files
selvedge export --format csv           # dump history to CSV

If you don't want to run the wizard, the four manual steps it automates:

1. Initialize in your project

cd your-project
selvedge init

2. Register the MCP server

Selvedge is a standard stdio MCP server, so it works with any MCP client — Claude Code, Cursor, Windsurf, Codex CLI, Gemini CLI, and more. See Works with any MCP client for the exact config per client. For Claude Code:

claude mcp add selvedge -- selvedge-server

3. Tell your agent to use it

selvedge prompt --install CLAUDE.md

Point --install at whichever prompt file your client reads — the block itself is identical across clients:

Client	Prompt file
Claude Code	`CLAUDE.md`
Codex CLI (and other `AGENTS.md`-aware tools)	`AGENTS.md`
Cursor	`.cursor/rules/selvedge.md` (or legacy `.cursorrules`)
Gemini CLI	`GEMINI.md`

This installs the canonical agent-instructions block, sentinel-bracketed ( / ) so future --install calls update the bracketed region without disturbing anything else in the file. Or pipe it:

selvedge prompt | tee -a CLAUDE.md

Prefer to copy-paste? The same block is one click away on the website: selvedge.sh/prompt-block — with a copy button and notes on what your agent does with it.

4. Install the post-commit hook

selvedge install-hook

That's the same four steps the wizard runs.

Works with any MCP client

Selvedge is a standard stdio MCP server — its launch command is selvedge-server, put on your PATH by pip install selvedge. Any MCP-capable client can run it. Pick yours:

claude mcp add selvedge -- selvedge-server

Or commit a project-level .mcp.json so your whole team gets it:

{
  "mcpServers": {
    "selvedge": { "command": "selvedge-server" }
  }
}

Docs: https://code.claude.com/docs/en/mcp

.cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

{
  "mcpServers": {
    "selvedge": { "command": "selvedge-server" }
  }
}

Cursor's newer schema also accepts an explicit "type": "stdio"; the command-only form works too (Cursor infers stdio from command). Docs: https://cursor.com/docs/mcp

~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "selvedge": { "command": "selvedge-server" }
  }
}

Windsurf hot-reloads the file — no restart needed. The in-app Plugins → View raw config button opens the exact file Cascade reads. Docs: https://docs.windsurf.com/windsurf/cascade/mcp

~/.codex/config.toml:

[mcp_servers.selvedge]
command = "selvedge-server"

Or run codex mcp add selvedge -- selvedge-server. Docs: https://developers.openai.com/codex/config-reference

~/.gemini/settings.json (or .gemini/settings.json per project):

{
  "mcpServers": {
    "selvedge": { "command": "selvedge-server" }
  }
}

Or run gemini mcp add -s user selvedge selvedge-server. Docs: https://github.com/google-gemini/gemini-cli/blob/main/docs/tools/mcp-server.md

Most clients share the same JSON shape — point yours at:

{
  "mcpServers": {
    "selvedge": { "command": "selvedge-server" }
  }
}

If selvedge-server isn't found, use its absolute path (which selvedge-server).

How it works

Selvedge runs as an MCP server. AI agents in tools like Claude Code call Selvedge's tools as they work — logging structured change events to a local SQLite database.

Each event records:

What changed (entity path, change type, diff)
When (timestamp)
Who (agent, session ID)
Why (reasoning — captured from the agent's context in the moment)
Where (git commit, project)

The diff is git's job. The why is Selvedge's.

Selvedge tracks its own history

This repo dogfoods Selvedge: its .selvedge/selvedge.db is committed, so a fresh clone ships with Selvedge's own why-history. Clone it and ask why any part of Selvedge changed:

git clone https://github.com/masondelan/selvedge
cd selvedge
selvedge status                       # recent changes to Selvedge itself
selvedge search "telemetry"           # why the opt-in heartbeat shipped
selvedge blame selvedge/semantic.py   # why semantic search was added

Every event was logged by the agents that built Selvedge — the same log_change calls this README asks you to make in your own project.

Entity path conventions

users.email           DB column (table.column)
users                 DB table
src/auth.py::login    Function in a file (path::symbol)
src/auth.py           File
api/v1/users          API route
deps/stripe           Dependency
env/STRIPE_SECRET_KEY Environment variable

Prefix queries work everywhere: users returns users, users.email, users.created_at, and any other entity under the users. namespace.

MCP tools

When connected as an MCP server, Selvedge exposes:

Tool	Description
`log_change`	Record a change event with entity, diff, and reasoning. `rename_from` + `change_type="rename"` records the dual-event rename pattern; `change_type="supersede"` re-opens a reverted decision (append-only); optional `constraint` / `stale_when` keep the decision's principle and its invalidation condition queryable
`diff`	History for an entity or entity prefix, each row annotated with `superseded_by`
`blame`	Most recent change + context for an exact entity, plus the derived decision `status` (active / reverted / reopened)
`history`	Filtered history across all entities
`changeset`	All events grouped under a named feature/task slug
`search`	Full-text search across all events
`prior_attempts`	Prior change attempts on an entity + inferred outcome (tried → reverted → re-opened) — call it before editing. Optional `fuzzy` query adds semantically similar records (needs the `semantic` extra; falls back to substring)
`stale_decisions`	Decisions due for a revisit: past their `revisit_after` and still in active use (`flag="revisit_due"`), or whose `stale_when` condition matched a later change (`flag="review_suggested"`)

CLI reference

selvedge init [--path PATH]               Initialize in project
selvedge status                           Recent activity summary
selvedge diff ENTITY [--limit N]          Change history for entity
selvedge blame ENTITY                     Most recent change + context
selvedge history [--since SINCE]          Browse all history
              [--entity ENTITY]
              [--project PROJECT]
              [--changeset CS]
              [--summarize]
              [--limit N]
selvedge changeset [CHANGESET_ID]         Show events in a changeset
                  [--list]                or list all changesets
                  [--project NAME]
                  [--since SINCE]
selvedge search QUERY [--limit N]         Full-text search
selvedge prior-attempts ENTITY            Prior attempts + inferred outcome,
                       [--description T]   with the tried → reverted →
                       [--all]             re-opened trail + status line
                       [--window 7d]       (--all widens recall)
                       [--fuzzy TEXT]      add semantic matches (needs the
                                           semantic extra; substring fallback)
selvedge supersede ENTITY                 Re-open a reverted decision —
                  --reasoning TEXT         append-only, links the prior
                  [--constraint TEXT]      reverted event (or --supersedes ID)
                  [--stale-when TEXT]
                  [--supersedes ID]
selvedge index [--model NAME]             Build/update the optional semantic
              [--json]                     embeddings index (selvedge[semantic])
selvedge stale [--entity ENTITY]          Decisions due for a revisit: past
              [--project NAME]            revisit_after + still in use, or
              [--agent NAME]              stale_when matched by a later change
              [--json]                    ("review suggested")
selvedge stats [--since SINCE]            Tool call coverage report (per-tool, per-agent)
selvedge doctor [--json]                  Health check: DB path, schema, hook, MCP wiring
selvedge install-hook [--path PATH]       Install git post-commit hook
                     [--window MIN]       (default 60 minutes)
selvedge backfill-commit --hash HASH      Backfill git_commit on recent events
                        [--window MIN]    (default 60 minutes)
selvedge import PATH                      Import migrations (SQL / Alembic) or
              [--format auto|sql|         an Agent Trace file (agent-trace)
                 alembic|agent-trace]
              [--from-git]                or walk git history for reverts:
              [--since REF|DATE]          revert-message commits + deletions
              [--project NAME]            become change_type="revert" events
              [--dry-run]                 (idempotent on commit + entity)
selvedge export [--format json|csv|       Export history (agent-trace =
                 markdown|agent-trace]      Agent Trace v0.1.0 records;
                                            markdown = reviewable digest)
              [--since SINCE]
              [--entity ENTITY]
              [--ndjson]                  agent-trace: one record per line
              [--collapse-by-session]     agent-trace: merge a session into one
              [--output FILE]
selvedge log ENTITY CHANGE_TYPE           Manually log a change
             [--diff TEXT]                CHANGE_TYPE: add, remove, modify,
             [--reasoning TEXT]           rename, retype, create, delete,
             [--agent NAME]               index_add, index_remove, migrate,
             [--commit HASH]              revert, supersede
             [--project NAME]
             [--changeset CS]
             [--revisit-after WHEN]       ISO date or offset (e.g. 90d)
             [--rename-from OLD]          OLD path when CHANGE_TYPE is 'rename'
             [--constraint TEXT]          the principle behind the decision
             [--stale-when TEXT]          what would invalidate it
             [--supersedes ID]            with CHANGE_TYPE 'supersede'
selvedge migrate-paths                    Re-canonicalize stored entity paths
                      [--apply]           (dry-run by default; --apply writes)
                      [--json]

All read commands support --json for machine-readable output.

Relative time in --since:

15m → last 15 minutes (m = minutes)
24h → last 24 hours
7d → last 7 days
5mo → last 5 months (mo or mon = months)
1y → last year

Unparseable inputs (e.g. --since yesterday) exit with a clear error rather than silently returning empty results. ISO 8601 timestamps are also accepted and normalized to UTC.

Configuration

Method	Format	Example
Env var	`SELVEDGE_DB=/path/to/db`	Per-session override
Project init	`selvedge init`	Creates `.selvedge/selvedge.db` in CWD
Global fallback	`~/.selvedge/selvedge.db`	Used if no project DB found
Hook watch globs	`.selvedge/config.toml`	`[hook]watch_globs = ["/migrations/", "db/*/.sql"]` — replaces the enforcement hook's default schema/migration globs
Project settings	`.selvedge/config.toml`	See the key list below — retention, size bounds, redaction patterns
Global settings	`~/.selvedge/config.toml`	Same keys; the project file wins where both set one
Hook bypass	`SELVEDGE_HOOK_DISABLE=1`	Disables the PreToolUse enforcement hook for the shell
Semantic extra	`pip install "selvedge[semantic]"`	Enables `selvedge index` + `prior-attempts --fuzzy` (local model2vec embeddings, ~30 MB; core never depends on it)

`.selvedge/config.toml`

Every key is optional; a missing file means the defaults below. Precedence is CLI flag → env var → project .selvedge/config.toml → global ~/.selvedge/config.toml → default. SELVEDGE_DB is the one exception: it always wins for database resolution, because the config file is found by resolving that path. selvedge doctor prints the effective value and the step that produced it for every setting.

retention_days_events     = 0       # 0 = never delete events (the default)
retention_days_tool_calls = 90      # local telemetry retention
backup_keep_last          = 7
diff_bytes                = 65536   # truncate oversized diffs at log time
reasoning_bytes           = 32768   # truncate oversized reasoning
db_size_warn_mb           = 500     # doctor warns above this
stale_days                = 0       # 0 = off
digest_max_bytes          = 4096    # cap on the session-start digest
redaction_patterns        = []      # extra secret shapes to warn about

[hook]
watch_globs = ["**/migrations/**", "db/**/*.sql"]

Every key also has an env override (SELVEDGE_DIFF_BYTES, SELVEDGE_RETENTION_DAYS_EVENTS, …).

Reviewing captured intent in a pull request

.selvedge/selvedge.db is a SQLite file, so the reasoning inside it doesn't show up in a diff. Export a Markdown digest next to it and commit both:

selvedge export --format markdown -o .selvedge/DECISIONS.md
git add .selvedge/

The digest is grouped by entity with reverted decisions first, and it is deterministic — regenerating with no new events produces a zero-line diff, so it stays reviewable instead of becoming noise everyone learns to skip. Heading anchors derive from the entity path, so links into it keep working as it grows. Regenerate it in the same commit as the code, or from a pre-commit hook.

Coverage checking

Wondering how often your agent actually calls log_change? Two ways to check:

# Quick summary in the terminal
selvedge stats

# Cross-reference against git commits
python scripts/coverage_check.py --since 30d

The coverage script compares your git log against Selvedge events and shows which commits have associated change events. Low coverage usually means the system prompt needs strengthening — see docs/fallbacks.md for guidance.

In CI (GitHub Action)

The same check ships as the Selvedge Coverage Check composite Action, so you can track agent coverage on every push — and optionally fail the build when it drops:

# .github/workflows/selvedge-coverage.yml
name: Selvedge coverage
on: [push, pull_request]
jobs:
  coverage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0            # full history so commits can be matched
      - uses: masondelan/selvedge@v0.3.14   # pin to a release tag (or @main for latest)
        with:
          since: 30d
          fail-under: "0.5"         # optional: fail below 50% coverage; omit to report only

It writes a coverage summary to the job summary and exposes coverage-ratio, covered, and total as step outputs. The action cross-references your git history against the Selvedge event log, so the runner needs the project's .selvedge/selvedge.db (commit it, or restore it before this step) and full git history (fetch-depth: 0). Inputs: since, window, limit, fail-under, selvedge-version, python-version, working-directory, db-path.

Contributing

Read the feedback and review process for reporting problems, evaluating feature requests and following up on discussions.

git clone https://github.com/masondelan/selvedge
cd selvedge
pip install -e ".[dev]"
pytest

See CLAUDE.md for architecture details and the phase roadmap.

License

MIT — see LICENSE.

Available Tools

8 tools

blameBlame an entityA

Read-onlyIdempotent

Most recent change to an entity — what changed, when, who, why.

Like git blame but for semantic entities (DB columns, functions, env vars, dependencies) and AI agents. Also carries the derived decision state: status (active / reverted / reopened) and superseded_by (id of a later supersede overriding this change, or ""). If no history exists for the entity, returns {"error": "..."} with protocol-level isError: false.

ParametersJSON Schema

Name	Required	Description	Default
`entity_path`	Yes	Exact entity path (no prefix matching). Examples: 'users.email', 'src/auth.py::login', 'env/STRIPE_SECRET_KEY'.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`diff`	Yes
`agent`	Yes
`error`	Yes
`status`	Yes
`project`	Yes
`metadata`	Yes
`reasoning`	Yes
`timestamp`	Yes
`constraint`	Yes
`git_commit`	Yes
`session_id`	Yes
`stale_when`	Yes
`supersedes`	Yes
`change_type`	Yes
`entity_path`	Yes
`entity_type`	Yes
`changeset_id`	Yes
`expires_when`	Yes
`revisit_after`	Yes
`superseded_by`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate safe read-only idempotent operation. The description adds value by detailing return fields (status, superseded_by) and error handling behavior (returns error object with isError: false). No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short paragraphs, no fluff. The first sentence immediately states the core purpose. Every sentence adds necessary context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a single parameter, existing output schema, and comprehensive annotations, the description covers the tool's functionality, return data, and error case fully and clearly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter with 100% schema coverage. The description adds the constraint 'exact entity path (no prefix matching)' and provides examples, enhancing the schema's description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the most recent change to an entity, likening it to git blame for semantic entities. It distinguishes from siblings like history or diff by focusing on the latest change and including decision state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does and notes error behavior when no history exists. It lacks explicit guidance on when not to use or alternatives, but the purpose is clear enough for correct selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

changesetGet a changesetA

Read-onlyIdempotent

All events that share a changeset_id, oldest first.

Use to reconstruct the full scope of a feature or task across multiple entities. If the changeset has no events, returns [{"error": "..."}] so the caller can distinguish "unknown changeset" from "empty history."

ParametersJSON Schema

Name	Required	Description	Default
`changeset_id`	Yes	The changeset identifier (the same slug or UUID passed to `log_change`'s changeset_id parameter). Examples: 'add-stripe-billing', 'fix-auth-redirect'.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive. Description adds ordering (oldest first) and specific error format, going beyond annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, each with clear purpose. No wasted words. First sentence states what the tool does, second gives usage context and error handling.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple single-parameter tool with full schema coverage and an output schema, the description sufficiently covers ordering, error condition, and intended use. No gaps identified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and fully describes the changeset_id parameter. Description adds no new parameter semantics beyond what the schema provides, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'All events that share a changeset_id, oldest first.' It specifies the resource (events) and ordering, distinguishing it from siblings like 'history' (likely broader) and 'search' (different target).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use to reconstruct the full scope of a feature or task across multiple entities,' providing clear context. Also describes error behavior for empty changesets. Lacks explicit when-not or alternative comparisons.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

diffDiff an entity's historyA

Read-onlyIdempotent

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 superseded_by id ("" when nothing overrode it), so the tried → reverted → re-opened trail reads straight off the history.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of events to return.
`entity_path`	Yes	Entity path, or a DOTTED prefix of one: 'users' also covers 'users.email'. Not a raw string prefix — 'src/' matches nothing, and 'src/auth.py' does not cover 'src/auth.py::login'.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context: newest-first ordering, dotted-prefix matching scope, and the derived `superseded_by` id with empty-string semantics for the latest event. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded: the first sentence gives the core purpose, and the second provides high-value examples of prefix matching and derived data. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema and safety annotations, the description sufficiently covers the essential behavior: ordering, prefix semantics, and the derived superseded_by trail. It does not discuss sibling-tool selection, but the core functionality is thoroughly described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers both parameters fully (100% coverage), so the baseline is 3. The description restates prefix matching with an example but does not add new parameter-level semantics beyond what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns change history for a codebase entity, newest first, and highlights unique behaviors like prefix matching and the derived `superseded_by` field. However, it does not explicitly differentiate from the similarly-named sibling tool `history`, so it stops short of full sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use is implied: call this when you need a chronological change history for an entity, especially with prefix matching. But the description does not compare this tool to alternatives like `history` or `blame`, nor does it mention exclusions or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

historyBrowse historyA

Read-onlyIdempotent

Filtered change history across all entities, newest first.

Combine since, entity_path, project, and changeset_id to scope the result. On unparseable since input the response is [{"error": "..."}] so the caller sees the problem.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of results.
`since`	No	Time window — ISO 8601 datetime OR relative shorthand: '15m' (last 15 minutes), '24h' (last 24 hours), '7d' (last 7 days), '5mo' (last 5 months), '1y' (last year). 'm' means minutes; 'mo' or 'mon' means months. Unparseable values produce an error rather than silently returning empty results. Empty = all time.
`project`	No	Filter to a specific project/repository.
`entity_path`	No	Filter to an entity, or a DOTTED prefix of one ('users' also covers 'users.email'). Not a raw string prefix.
`changeset_id`	No	Filter to a specific changeset (feature/task group).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnly=true, idempotent=true, and destructive=false, so safety is covered. The description goes beyond by disclosing the error behavior for unparseable 'since' input, returning a JSON error array instead of silently returning empty results. This is valuable behavioral context not in the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states purpose and ordering, the second gives usage guidance and error handling. It is front-loaded, with no wasted words, and every sentence contributes meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and the description covers purpose, filtering, ordering, and error behavior, the tool is fully specified for an agent. The description is complete for this 5-parameter optional-input tool without needing to explain return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed descriptions for each parameter, so the baseline is 3. The description adds minor value by explicitly stating these parameters can be combined, but it does not explain syntax or semantics beyond what the schema already provides. No compensation needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Filtered change history across all entities, newest first.' It uses a specific verb ('browse' implicitly via 'history') and resource ('all entities'), and the 'newest first' ordering adds precision. This distinguishes it from siblings like log_change, diff, and search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance on how to combine filter parameters ('since', 'entity_path', 'project', 'changeset_id') to scope results. It does not explicitly mention when not to use this tool or name alternatives, but the usage context is clear enough for an agent to know when to invoke it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

log_changeLog a code 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 warnings array — the event is still stored.

Renames: pass the new path in entity_path, set change_type="rename", and pass the old path in rename_from. Selvedge then writes two events — a rename on the old path and a create on the new path with metadata.renamed_from set — so the entity's history follows it. Example:

log_change(
    entity_path="src/auth/session.py::login",   # new path
    change_type="rename",
    rename_from="src/auth.py::login",            # old path
    entity_type="function",
    reasoning="Split auth.py into an auth/ package; login moved.",
)

Rejections: when you consider an approach and decide against it WITHOUT writing the change, record the verdict with change_type="reject" — the abandoned path is a first-class event, and the next agent's prior_attempts query finds it as a high-confidence ("exact") row instead of re-deriving the dead end. Name what was rejected AND what was chosen instead, and record the condition that would invalidate the verdict. Example:

log_change(
    entity_path="users.card_pan",
    change_type="reject",
    entity_type="column",
    reasoning="Rejected storing raw card PANs on the user row — "
              "went with provider tokens instead; PANs in our own "
              "DB put us in PCI scope.",
    stale_when="payment provider changed",
    expires_when="entity:deps/stripe:changes",
)

Use change_type="revert" for the sibling case — the change WAS written and then rolled back (clearer than a plain remove).

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 change_type="supersede" and the reason. The new event links the prior revert (auto-resolved when supersedes is empty) and every read surface then reports the trail tried → reverted → re-opened. Never re-apply a reverted change without superseding it first.

On validation failure (invalid change_type, missing entity_path, rename_from set without change_type='rename', supersedes set without change_type='supersede', a supersede with nothing to re-open, or an expires_when outside the closed grammar) the result is {"status": "error", "error": "..."} with no event written.

ParametersJSON Schema

Name	Required	Description	Default
`diff`	No	The actual change — SQL migration text, code diff, or a human-readable description of what changed. Optional but strongly recommended for non-trivial changes.
`agent`	No	Name/ID of the AI agent making the change (e.g. 'claude-code', 'cursor', 'copilot', 'human').
`project`	No	Repository or project name. Useful when one DB tracks multiple projects.
`reasoning`	No	Why the change was made. Include the user's original request, the problem being solved, or any context that won't be obvious from the diff alone. Good example: 'User asked to add 2FA — needs phone number to send SMS verification codes.' Avoid generic placeholders like 'user request' or 'done' — these are flagged by the quality validator and returned in `warnings`.
`constraint`	No	Optional: the testable principle behind the decision, kept queryable (e.g. 'card data in our own DB = PCI scope').
`git_commit`	No	The git commit hash this change will land in. Can be backfilled later via `selvedge backfill-commit` or the post-commit hook.
`session_id`	No	The agent session or conversation ID, if available.
`stale_when`	No	Optional: what would invalidate this decision (e.g. 'payment provider changed'). stale_decisions matches it against later events and flags 'review suggested' — surfacing only.
`supersedes`	No	Id of the prior event this change overrides; only valid with change_type='supersede'. Empty auto-links the entity's most recent removal event (remove/delete/index_remove/revert/reject) — so after a standalone rejection it re-opens the rejection. Append-only — the old verdict is never edited, just derived as superseded.
`change_type`	Yes	What kind of change. One of: add, remove, modify, rename, retype, create, delete, index_add, index_remove, migrate, revert (tried and rolled back), reject (considered and decided against, without writing the change), supersede (re-open a reverted decision). Invalid values are rejected — pick the closest match.
`entity_path`	Yes	Dot/slash-notation path to the entity. Required and non-empty. Examples: 'users.email' (DB column), 'users' (DB table), 'src/auth.py::login' (function in file), 'src/auth.py' (file), 'api/v1/users' (API route), 'deps/stripe' (dependency), 'env/STRIPE_SECRET_KEY' (env variable).
`entity_type`	No	Category of entity. One of: column, table, file, function, class, endpoint, dependency, env_var, index, schema, config, other. Unknown values are coerced to 'other'.	other
`rename_from`	No	The entity's previous path, when this change is a rename. Set it together with change_type='rename' and put the NEW path in entity_path. Selvedge records the dual-event rename pattern: a 'rename' event on the old path and a 'create' event on the new path whose metadata.renamed_from points back to the old one, so blame/diff/prior_attempts on the new path still see the history. Leave empty for any non-rename change.
`changeset_id`	No	Optional grouping ID for related changes that belong to the same feature or task. Use a short slug like 'add-stripe-billing'. All events sharing a changeset_id can be queried together via the `changeset` tool.
`expires_when`	No	Optional machine-checkable expiry condition for this decision. Closed grammar, validated at write time: 'library:NAME>=VERSION' (revisit when the named dependency reaches a version, e.g. 'library:django>=5.0'), 'entity:PATH:changes' (revisit when that entity next changes, e.g. 'entity:users.email:changes'), 'date:ISO' (revisit on a date, e.g. 'date:2027-01-01'), or 'manual:LABEL' (opaque label for human review; never auto-fires). `stale_decisions` evaluates these from local state — no network, no LLM — and flags 'expired' with the pattern that fired. Values outside the grammar are rejected.
`revisit_after`	No	Optional revisit date for an architectural decision (table, schema, dependency, config). An ISO date OR a relative offset from this event's timestamp (e.g. '90d', '6mo'). `stale_decisions` surfaces it once it passes, if the entity is still in active use. Leave empty otherwise.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`error`	Yes
`status`	Yes
`warnings`	Yes
`timestamp`	Yes
`supersedes`	Yes

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations carry near-zero information (all false except openWorldHint), so the description carries the full burden. It comprehensively discloses: the warnings array on quality-validator failure, the exact error shape on validation failure, the dual-event rename behavior, supersede auto-linking, and append-only semantics. No contradiction with annotations (readOnlyHint=false correctly implies a write).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Long, but every section earns its place given the complexity — headers ('Renames:', 'Rejections:', 'Superseding a reverted decision:') with code examples make it scannable. Slightly verbose in repeating rename semantics already in the schema's rename_from field, but organized enough that the density is justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Comprehensive for a 16-parameter write tool with 5 complex change_type workflows. The description covers all change types, the validation grammar, failure/error shapes, examples for each major flow, and the output schema exists. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, giving a baseline of 3, but the description adds genuine orchestration semantics beyond the schema: rename's dual-event pattern (rename on old path + create on new path with metadata.renamed_from), the reject naming requirement ('name what was rejected AND what was chosen instead'), and that empty supersedes auto-links the most recent removal event. This is behavioral glue the schemas don't spell out.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Record a change to a codebase entity' — and immediately distinguishes itself: call it after a meaningful change, while siblings diff/blame/history/prior_attempts are read surfaces. An agent can clearly separate it from the sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use for each change_type: 'Call this immediately after making any meaningful change,' with dedicated workflows for rename, reject, revert, and supersede. Names why reject is preferable to re-deriving dead ends ('the next agent's prior_attempts query finds it as a high-confidence row') and why supersede beats editing history. Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

prior_attemptsPrior attempts on an entityA

Read-onlyIdempotent

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 reasoning and change_type plus an inferred outcome — so you can change your plan instead of repeating a rejected approach.

Each result is a change event plus the trail fields: outcome ("reverted" — a later removal on the path; "reopened" — closed but a later supersede re-opened it; "rejected" — a standalone reject event that closed no earlier attempt, surfaced as its own row whose reasoning IS the record; "active"), confidence ("exact" — the attempt was closed by an explicit revert/reject, or the row is a standalone rejection; "proximity_high" / "proximity_low" — the add->remove window heuristic for implicit removals), outcome_reasoning (WHY it was rejected), superseded_by + supersede_reasoning (the re-open, when present), and current_status — the entity's standing now. Treat "reverted" and "rejected" as "don't repeat this without a supersede"; "reopened" means the old verdict no longer stands. Together they read: tried → reverted → re-opened. Templated and deterministic — no LLM call; pull-only.

Conservative by design — min_confidence defaults to "proximity_high", so an empty list (nothing clearly tried-and-rejected) is the normal, preferred answer over a speculative false positive; "exact" rows always clear that default floor. Pass min_confidence="proximity_low" to widen recall. Rows carry match_type ("exact" / "substring" / "fuzzy") and similarity.

ParametersJSON Schema

Name	Required	Description	Default
`fuzzy`	No	Optional semantic query: also return attempts on entities whose prior reasoning is similar to this text — catches renames (payment_token vs card_token). Rows are labeled match_type='fuzzy' with a similarity score; without the selvedge[semantic] extra it falls back to substring matching and says so in a leading note row.
`limit`	No	Maximum number of results.
`description`	No	Free-text description of what you're about to do, when you don't have an exact entity_path. Matched as a substring against prior reasoning, diffs, and entity paths. Provide this OR `entity_path` (entity_path takes precedence if both are given).
`entity_path`	No	The entity you're about to change. Exact path with prefix matching — 'users' also covers 'users.email'. Examples: 'src/auth.py::login', 'users.email', 'env/STRIPE_SECRET_KEY'. Provide this OR `description`.
`min_confidence`	No	Confidence floor. 'proximity_high' (default) returns the high-signal rows: attempts closed by an explicit revert/reject (confidence 'exact' — always clears this floor, including standalone rejections) plus attempts reverted within the window. Pass 'proximity_low' to also see the noisy tail (still-active changes and far-apart reverts).	proximity_high
`window_minutes`	No	Proximity window in minutes for the add->remove revert heuristic — the tiebreaker for IMPLICIT removal types only. An attempt removed within this many minutes is 'proximity_high'; beyond it, 'proximity_low'. Attempts closed by an explicit revert/reject are 'exact' regardless of the window. Default 10080 (7 days).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, non-destructive behavior, and the description reinforces and expands this with 'Templated and deterministic — no LLM call; pull-only.' It discloses nuanced behaviors: conservative defaults, the meaning of outcome/confidence values, and that an empty list is the preferred normal answer. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but information-dense, with a sensible structure: core purpose, usage timing, outcome semantics, and confidence policy. Every sentence carries meaningful guidance, though some sections could be tightened. The front-loading is effective; the most important instruction appears early.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the description covers purpose, usage timing, result semantics, confidence filtering, recall widening, and edge cases like standalone rejections and reopen events. The output schema exists and the description also explains return fields thoroughly. Nothing critical is missing for an agent to select and invoke this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema itself documents all parameters. The description adds meaningful extra context, such as the default min_confidence behavior, how 'exact' rows clear the confidence floor, and the role of window_minutes as a tiebreaker for implicit removals. This goes beyond simple schema repetition, though it could have been slightly more parameter-by-parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's purpose: retrieving prior change attempts on an entity with inferred outcomes. It states a specific action context ('Call this BEFORE editing an entity') and distinguishes the data it returns. However, it does not explicitly differentiate itself from siblings like 'history' or 'changeset', so an agent must infer which tool covers which kind of history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs when to use the tool: before editing an entity, to avoid repeating a rejected approach. It also explains how to widen recall via min_confidence. However, it does not say when NOT to use it or name any alternative tool, so the usage guidance is strong on 'when' but missing exclusions and alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

searchSearch eventsA

Read-onlyIdempotent

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

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of results.
`query`	Yes	Search string (case-insensitive substring). Searches across entity_path, diff, reasoning, and agent fields. SQL LIKE wildcards (`_` and `%`) are escaped, so 'stripe_customer_id' matches the literal underscore rather than any single char.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds search semantics: full-text across four fields and substring matching with escaped wildcards (from schema). This contextualizes behavior beyond annotations, though pagination/ordering are not mentioned (but output schema covers returns).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: one declarative purpose statement and one illustrative set of examples. No redundant content and the main intent is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with two parameters, full schema coverage, output schema, and clear annotations, the description adequately conveys what it searches. The example questions help the agent map natural language to tool invocation; however, it does not mention result ordering or the limit parameter behavior (though schema covers limit).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including the case-insensitive substring behavior and wildcard escaping. The tool description adds only usage examples, not new parameter semantics, so it meets baseline but does not exceed schema detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'search' and names the exact resources (entity paths, diffs, reasoning, agents). Example queries like 'what changes were made for the billing feature?' clarify the scope and distinguish it from sibling tools like diff or blame.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit example questions that signal appropriate use cases, such as cross-cutting search across multiple entities. It does not directly name alternatives or state when not to use this tool, but the examples imply broad search rather than targeted diffs or history queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

stale_decisionsStale decisions due for revisitA

Read-onlyIdempotent

Decisions due for a revisit — expired, past their date, or with a triggered stale condition.

Three deterministic rules. Expiry-based (flag="expired"): events whose expires_when condition fired, evaluated from local state only — date: against now, entity:PATH:changes against the event log, library:NAME>=VERSION against installed dist metadata; the pattern kind that fired is in expired_pattern. A library: condition whose dependency isn't locally observable surfaces as flag="manual_review" instead of a guess; manual:LABEL never auto-fires. Date-based (flag="revisit_due"): events whose revisit_after has passed AND the entity is still live (queried via blame/diff/prior_attempts after the decision, or its changeset saw later activity) — pure age alone never surfaces. Condition-based (flag="review_suggested"): events whose stale_when text shares keywords with a LATER change event — the named invalidation evidence may have happened. Surfacing only: nothing is un-retired automatically; follow up with a supersede if the condition really was triggered. A later supersede that re-opens the candidate (explicit supersedes id, or the same id-less auto-link prior_attempts uses) drops it from this list; a same-path sibling the supersede did not target still surfaces.

Each result is the change event plus flag, revisit_due, days_overdue, active_use_signals, matched_terms, matched_event_id, expires_status, expired_pattern, expires_detail, and a one-line stale_reason. Date-due rows first, most-overdue leading; filter by entity_path, project, or agent. Templated and deterministic; no LLM call, no network.

ParametersJSON Schema

Name	Required	Description
`agent`	No	Optional filter to the agent that logged the decision.
`limit`	No	Maximum number of results.
`project`	No	Optional filter to a specific project/repository.
`entity_path`	No	Optional filter to a single entity or path prefix — 'users' also covers 'users.email'. Empty = every entity.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even with annotations marking readOnly, deterministic, and non-destructive, the description adds substantial behavioral detail: no LLM call, no network, no automatic un-retiring, fallback to manual_review when dependency state is unobservable, and effects of later supersede events. This is far beyond what annotations alone convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average, but the tool has complex deterministic rules and edge cases that warrant the detail. It is front-loaded with the core purpose and organized by flag type, followed by output fields, ordering, and guarantees. The output field enumeration is slightly redundant with the existing output schema, preventing a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with this complexity, the description is complete: it explains all three surfacing mechanisms, non-obvious edge cases like manual_review, output shape, ordering, filtering, and determinism guarantees. Combined with the rich annotations and output schema, an agent has everything needed to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline of 3 applies. The description mentions filtering by entity_path, project, or agent, which reinforces the schema but does not add much new semantic depth. It does not describe parameter formats beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Decisions due for a revisit,' then enumerates the three deterministic rules and their resulting flags. It clearly distinguishes this tool from siblings by emphasizing it is surfacing-only, deterministic, and local-state-based.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when results surface: expiry-based, date-based, and condition-based rules, with explicit caveats like 'pure age alone never surfaces' and 'manual:LABEL never auto-fires.' It does not explicitly name sibling alternatives for exclusion, but the behavioral specificity makes intended usage unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updatev0.3.14Sep 19, 2026
- Changedprior_attempts1 field changed
  - changedInput schema / properties / window_minutes / maximum
```
Previous value: -1000New value: +10080
```

2 tool updatesSep 1, 2026

Changedlog_change3 fields changed

changedInput schema / properties / change_type / description

Previous value: -"What kind of change. One of: add, remove, modify, rename, retype, create, delete, index_add, index_remove, migrate, revert (tried and rolled back), supersede (re-open a reverted decision). Invalid values are rejected — pick the closest match."New value: +"What kind of change. One of: add, remove, modify, rename, retype, create, delete, index_add, index_remove, migrate, revert (tried and rolled back), reject (considered and decided against, without writing the change), supersede (re-open a reverted decision). Invalid values are rejected — pick the closest match."

addedInput schema / properties / expires_when

Added value: +{
+  "default": "",
+  "description": "Optional machine-checkable expiry condition for this decision. Closed grammar, validated at write time: 'library:NAME>=VERSION' (revisit when the named dependency reaches a version, e.g. 'library:django>=5.0'), 'entity:PATH:changes' (revisit when that entity next changes, e.g. 'entity:users.email:changes'), 'date:ISO' (revisit on a date, e.g. 'date:2027-01-01'), or 'manual:LABEL' (opaque label for human review; never auto-fires). `stale_decisions` evaluates these from local state — no network, no LLM — and flags 'expired' with the pattern that fired. Values outside the grammar are rejected.",
+  "title": "Expires When",
+  "type": "string"
+}

changedInput schema / properties / supersedes / description

Previous value: -"Id of the prior event this change overrides; only valid with change_type='supersede'. Empty auto-links the entity's most recent remove/delete. Append-only — the old verdict is never edited, just derived as superseded."New value: +"Id of the prior event this change overrides; only valid with change_type='supersede'. Empty auto-links the entity's most recent removal event (remove/delete/index_remove/revert/reject) — so after a standalone rejection it re-opens the rejection. Append-only — the old verdict is never edited, just derived as superseded."

Changedprior_attempts2 fields changed

changedInput schema / properties / min_confidence / description

Previous value: -"Confidence floor. 'proximity_high' (default) returns only attempts that were clearly tried and then reverted within the window — the high-signal 'rejected before' cases. Pass 'proximity_low' to also see the noisy tail (still-active changes and far-apart reverts)."New value: +"Confidence floor. 'proximity_high' (default) returns the high-signal rows: attempts closed by an explicit revert/reject (confidence 'exact' — always clears this floor, including standalone rejections) plus attempts reverted within the window. Pass 'proximity_low' to also see the noisy tail (still-active changes and far-apart reverts)."

changedInput schema / properties / window_minutes / description

Previous value: -"Proximity window in minutes for the add->remove revert heuristic. An attempt removed within this many minutes is 'proximity_high'; beyond it, 'proximity_low'. Default 10080 (7 days)."New value: +"Proximity window in minutes for the add->remove revert heuristic — the tiebreaker for IMPLICIT removal types only. An attempt removed within this many minutes is 'proximity_high'; beyond it, 'proximity_low'. Attempts closed by an explicit revert/reject are 'exact' regardless of the window. Default 10080 (7 days)."

5 tool updatesv0.3.11Aug 2, 2026

Changeddiff2 fields changed

changedInput schema / properties / entity_path / description

Previous value: -"Entity path or path prefix. Prefix matching is supported: 'users' returns history for the users table AND all its columns ('users.email', 'users.created_at', etc.). Use a more specific path to narrow the result."New value: +"Entity path, or a DOTTED prefix of one: 'users' also covers 'users.email'. Not a raw string prefix — 'src/' matches nothing, and 'src/auth.py' does not cover 'src/auth.py::login'."

addedInput schema / properties / limit / maximum
```
Added value: +1000
```

Changedhistory2 fields changed

changedInput schema / properties / entity_path / description

Previous value: -"Filter to a specific entity or path prefix."New value: +"Filter to an entity, or a DOTTED prefix of one ('users' also covers 'users.email'). Not a raw string prefix."

addedInput schema / properties / limit / maximum
```
Added value: +1000
```

Changedprior_attempts2 fields changed
- addedInput schema / properties / limit / maximum
```
Added value: +1000
```
- addedInput schema / properties / window_minutes / maximum
```
Added value: +1000
```
Changedsearch1 field changed
- addedInput schema / properties / limit / maximum
```
Added value: +1000
```
Changedstale_decisions1 field changed
- addedInput schema / properties / limit / maximum
```
Added value: +1000
```

3 tool updatesv0.3.10Jul 13, 2026

Changedblame6 fields changed

addedOutput schema / properties / constraint

Added value: +{
+  "title": "Constraint",
+  "type": "string"
+}

addedOutput schema / properties / stale_when

Added value: +{
+  "title": "Stale When",
+  "type": "string"
+}

addedOutput schema / properties / status

Added value: +{
+  "title": "Status",
+  "type": "string"
+}

addedOutput schema / properties / superseded_by

Added value: +{
+  "title": "Superseded By",
+  "type": "string"
+}

addedOutput schema / properties / supersedes

Added value: +{
+  "title": "Supersedes",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "id",
-  "timestamp",
-  "entity_type",
-  "entity_path",
-  "change_type",
-  "diff",
-  "reasoning",
-  "agent",
-  "session_id",
-  "git_commit",
-  "project",
-  "changeset_id",
-  "metadata",
-  "revisit_after",
-  "expires_when",
-  "error"
-]New value: +[
+  "id",
+  "timestamp",
+  "entity_type",
+  "entity_path",
+  "change_type",
+  "diff",
+  "reasoning",
+  "agent",
+  "session_id",
+  "git_commit",
+  "project",
+  "changeset_id",
+  "metadata",
+  "revisit_after",
+  "expires_when",
+  "supersedes",
+  "constraint",
+  "stale_when",
+  "superseded_by",
+  "status",
+  "error"
+]

Changedlog_change6 fields changed

changedInput schema / properties / change_type / description

Previous value: -"What kind of change. One of: add, remove, modify, rename, retype, create, delete, index_add, index_remove, migrate. Invalid values are rejected — pick the closest match."New value: +"What kind of change. One of: add, remove, modify, rename, retype, create, delete, index_add, index_remove, migrate, revert (tried and rolled back), supersede (re-open a reverted decision). Invalid values are rejected — pick the closest match."

addedInput schema / properties / constraint

Added value: +{
+  "default": "",
+  "description": "Optional: the testable principle behind the decision, kept queryable (e.g. 'card data in our own DB = PCI scope').",
+  "title": "Constraint",
+  "type": "string"
+}

addedInput schema / properties / stale_when

Added value: +{
+  "default": "",
+  "description": "Optional: what would invalidate this decision (e.g. 'payment provider changed'). stale_decisions matches it against later events and flags 'review suggested' — surfacing only.",
+  "title": "Stale When",
+  "type": "string"
+}

addedInput schema / properties / supersedes

Added value: +{
+  "default": "",
+  "description": "Id of the prior event this change overrides; only valid with change_type='supersede'. Empty auto-links the entity's most recent remove/delete. Append-only — the old verdict is never edited, just derived as superseded.",
+  "title": "Supersedes",
+  "type": "string"
+}

addedOutput schema / properties / supersedes

Added value: +{
+  "title": "Supersedes",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "id",
-  "timestamp",
-  "status",
-  "error",
-  "warnings"
-]New value: +[
+  "id",
+  "timestamp",
+  "status",
+  "error",
+  "warnings",
+  "supersedes"
+]

Changedprior_attempts1 field changed

addedInput schema / properties / fuzzy

Added value: +{
+  "default": "",
+  "description": "Optional semantic query: also return attempts on entities whose prior reasoning is similar to this text — catches renames (payment_token vs card_token). Rows are labeled match_type='fuzzy' with a similarity score; without the selvedge[semantic] extra it falls back to substring matching and says so in a leading note row.",
+  "title": "Fuzzy",
+  "type": "string"
+}

4 tool updatesv0.3.8Jun 17, 2026

Changedblame3 fields changed

addedOutput schema / properties / expires_when

Added value: +{
+  "title": "Expires When",
+  "type": "string"
+}

addedOutput schema / properties / revisit_after

Added value: +{
+  "title": "Revisit After",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "id",
-  "timestamp",
-  "entity_type",
-  "entity_path",
-  "change_type",
-  "diff",
-  "reasoning",
-  "agent",
-  "session_id",
-  "git_commit",
-  "project",
-  "changeset_id",
-  "metadata",
-  "error"
-]New value: +[
+  "id",
+  "timestamp",
+  "entity_type",
+  "entity_path",
+  "change_type",
+  "diff",
+  "reasoning",
+  "agent",
+  "session_id",
+  "git_commit",
+  "project",
+  "changeset_id",
+  "metadata",
+  "revisit_after",
+  "expires_when",
+  "error"
+]

Changedlog_change2 fields changed

addedInput schema / properties / rename_from

Added value: +{
+  "default": "",
+  "description": "The entity's previous path, when this change is a rename. Set it together with change_type='rename' and put the NEW path in entity_path. Selvedge records the dual-event rename pattern: a 'rename' event on the old path and a 'create' event on the new path whose metadata.renamed_from points back to the old one, so blame/diff/prior_attempts on the new path still see the history. Leave empty for any non-rename change.",
+  "title": "Rename From",
+  "type": "string"
+}

addedInput schema / properties / revisit_after

Added value: +{
+  "default": "",
+  "description": "Optional revisit date for an architectural decision (table, schema, dependency, config). An ISO date OR a relative offset from this event's timestamp (e.g. '90d', '6mo'). `stale_decisions` surfaces it once it passes, if the entity is still in active use. Leave empty otherwise.",
+  "title": "Revisit After",
+  "type": "string"
+}

Addedprior_attempts
Addedstale_decisions

6 tool updatesv0.3.2May 3, 2026

Changedblame2 fields changed

addedInput schema / properties / entity_path / description

Added value: +"Exact entity path (no prefix matching). Examples: 'users.email', 'src/auth.py::login', 'env/STRIPE_SECRET_KEY'."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "agent": {
+      "title": "Agent",
+      "type": "string"
+    },
+    "change_type": {
+      "title": "Change Type",
+      "type": "string"
+    },
+    "changeset_id": {
+      "title": "Changeset Id",
+      "type": "string"
+    },
+    "diff": {
+      "title": "Diff",
+      "type": "string"
+    },
+    "entity_path": {
+      "title": "Entity Path",
+      "type": "string"
+    },
+    "entity_type": {
+      "title": "Entity Type",
+      "type": "string"
+    },
+    "error": {
+      "title": "Error",
+      "type": "string"
+    },
+    "git_commit": {
+      "title": "Git Commit",
+      "type": "string"
+    },
+    "id": {
+      "title": "Id",
+      "type": "string"
+    },
+    "metadata": {
+      "additionalProperties": true,
+      "title": "Metadata",
+      "type": "object"
+    },
+    "project": {
+      "title": "Project",
+      "type": "string"
+    },
+    "reasoning": {
+      "title": "Reasoning",
+      "type": "string"
+    },
+    "session_id": {
+      "title": "Session Id",
+      "type": "string"
+    },
+    "timestamp": {
+      "title": "Timestamp",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "timestamp",
+    "entity_type",
+    "entity_path",
+    "change_type",
+    "diff",
+    "reasoning",
+    "agent",
+    "session_id",
+    "git_commit",
+    "project",
+    "changeset_id",
+    "metadata",
+    "error"
+  ],
+  "title": "BlameResult",
+  "type": "object"
+}

Changedchangeset1 field changed

addedInput schema / properties / changeset_id / description

Added value: +"The changeset identifier (the same slug or UUID passed to `log_change`'s changeset_id parameter). Examples: 'add-stripe-billing', 'fix-auth-redirect'."

Changeddiff3 fields changed

addedInput schema / properties / entity_path / description

Added value: +"Entity path or path prefix. Prefix matching is supported: 'users' returns history for the users table AND all its columns ('users.email', 'users.created_at', etc.). Use a more specific path to narrow the result."

addedInput schema / properties / limit / description

Added value: +"Maximum number of events to return."

addedInput schema / properties / limit / minimum
```
Added value: +1
```

Changedhistory6 fields changed

addedInput schema / properties / changeset_id / description

Added value: +"Filter to a specific changeset (feature/task group)."

addedInput schema / properties / entity_path / description

Added value: +"Filter to a specific entity or path prefix."

addedInput schema / properties / limit / description
```
Added value: +"Maximum number of results."
```
addedInput schema / properties / limit / minimum
```
Added value: +1
```

addedInput schema / properties / project / description

Added value: +"Filter to a specific project/repository."

addedInput schema / properties / since / description

Added value: +"Time window — ISO 8601 datetime OR relative shorthand: '15m' (last 15 minutes), '24h' (last 24 hours), '7d' (last 7 days), '5mo' (last 5 months), '1y' (last year). 'm' means minutes; 'mo' or 'mon' means months. Unparseable values produce an error rather than silently returning empty results. Empty = all time."

Changedlog_change11 fields changed

addedInput schema / properties / agent / description

Added value: +"Name/ID of the AI agent making the change (e.g. 'claude-code', 'cursor', 'copilot', 'human')."

addedInput schema / properties / change_type / description

Added value: +"What kind of change. One of: add, remove, modify, rename, retype, create, delete, index_add, index_remove, migrate. Invalid values are rejected — pick the closest match."

addedInput schema / properties / changeset_id / description

Added value: +"Optional grouping ID for related changes that belong to the same feature or task. Use a short slug like 'add-stripe-billing'. All events sharing a changeset_id can be queried together via the `changeset` tool."

addedInput schema / properties / diff / description

Added value: +"The actual change — SQL migration text, code diff, or a human-readable description of what changed. Optional but strongly recommended for non-trivial changes."

addedInput schema / properties / entity_path / description

Added value: +"Dot/slash-notation path to the entity. Required and non-empty. Examples: 'users.email' (DB column), 'users' (DB table), 'src/auth.py::login' (function in file), 'src/auth.py' (file), 'api/v1/users' (API route), 'deps/stripe' (dependency), 'env/STRIPE_SECRET_KEY' (env variable)."

addedInput schema / properties / entity_type / description

Added value: +"Category of entity. One of: column, table, file, function, class, endpoint, dependency, env_var, index, schema, config, other. Unknown values are coerced to 'other'."

addedInput schema / properties / git_commit / description

Added value: +"The git commit hash this change will land in. Can be backfilled later via `selvedge backfill-commit` or the post-commit hook."

addedInput schema / properties / project / description

Added value: +"Repository or project name. Useful when one DB tracks multiple projects."

addedInput schema / properties / reasoning / description

Added value: +"Why the change was made. Include the user's original request, the problem being solved, or any context that won't be obvious from the diff alone. Good example: 'User asked to add 2FA — needs phone number to send SMS verification codes.' Avoid generic placeholders like 'user request' or 'done' — these are flagged by the quality validator and returned in `warnings`."

addedInput schema / properties / session_id / description

Added value: +"The agent session or conversation ID, if available."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "error": {
+      "title": "Error",
+      "type": "string"
+    },
+    "id": {
+      "title": "Id",
+      "type": "string"
+    },
+    "status": {
+      "title": "Status",
+      "type": "string"
+    },
+    "timestamp": {
+      "title": "Timestamp",
+      "type": "string"
+    },
+    "warnings": {
+      "items": {
+        "type": "string"
+      },
+      "title": "Warnings",
+      "type": "array"
+    }
+  },
+  "required": [
+    "id",
+    "timestamp",
+    "status",
+    "error",
+    "warnings"
+  ],
+  "title": "LogChangeResult",
+  "type": "object"
+}

Changedsearch3 fields changed

addedInput schema / properties / limit / description
```
Added value: +"Maximum number of results."
```
addedInput schema / properties / limit / minimum
```
Added value: +1
```

addedInput schema / properties / query / description

Added value: +"Search string (case-insensitive substring). Searches across entity_path, diff, reasoning, and agent fields. SQL LIKE wildcards (`_` and `%`) are escaped, so 'stripe_customer_id' matches the literal underscore rather than any single char."

6 tool updatesv0.3.1Apr 25, 2026
- First observedblame
- First observedchangeset
- First observeddiff
- First observedhistory
- First observedlog_change
- First observedsearch

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-09-19 04:10 across 8 tools

Disambiguation4/5

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

Naming Consistency3/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Maintenance

ActivityActive

ResponsivenessResponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

chat-recallOAuth
io.github.munhq
One searchable history across every AI coding tool, with secret scanning and a shared task board.
Knowledge & Memory Security Code Analysis
12
SpiderbrainOAuth
ai.spiderbrain
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Code Analysis Developer Tools RAG Systems
13
TeamShared C
io.github.xhad
Shared memory for coding agents. Stop re-explaining your codebase every session.
Knowledge & Memory Developer Tools
1501
Brain Scanner DOAuth
io.github.kevin-lozada-santos
Codebase graphs, caller impact analysis, and recorded project context for AI coding agents.
Code Analysis Developer Tools Knowledge & Memory
1361

Related MCP Servers

gitwhy-mcp
Version Control Knowledge & Memory Developer Tools
gitwhy-cli
A
license
Not graded
quality
D
maintenance
The shared AI context engine for git — save, search, and share the reasoning behind code changes. Captures the why behind every commit and slide on PRs for coding agents.
Updated 6 months ago (2026-04-02 03:34 UTC)
24 npm
MIT
claude-engram
AI & Machine Learning Developer Tools Knowledge & Memory
20alexl
A
license
B
quality
B
maintenance
Persistent memory and session intelligence for AI coding assistants. Auto-tracks mistakes, decisions, and context via hooks. Mines your full session history for patterns, predictions, and cross-session search.
Updated 24 days ago (2026-08-27 21:38 UTC)
21
16
MIT
Projectmem
Knowledge & Memory Developer Tools
riponcm
A
license
A
quality
A
maintenance
Local-first memory layer for AI coding agents — captures issues, attempts, fixes, and decisions, and warns at git commit before you repeat a mistake.
Updated 6 days ago (2026-09-15 00:14 UTC)
17
372 PyPI
823
MIT
MemoVofficial
Knowledge & Memory Version Control Developer Tools
memovai
A
license
Not graded
quality
C
maintenance
Provides a memory layer for AI coding agents with Git-powered version control, enabling automatic tracking of prompts, context, and code diffs.
Updated 8 months ago (2026-02-05 11:11 UTC)
193
MIT

Who Selvedge is for

The problem

What's new in v0.3.14

What's new in v0.3.13

Where Selvedge fits

How Selvedge compares

Quickstart

Claude Code — install the plugin (recommended)

Choose your coding agent

Works with any MCP client

How it works

Selvedge tracks its own history

Entity path conventions

MCP tools

CLI reference

Configuration

.selvedge/config.toml

Reviewing captured intent in a pull request

Coverage checking

In CI (GitHub Action)

Contributing

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

MemoVofficial

`.selvedge/config.toml`