Skip to main content
Glama

twining_housekeeping

Run periodic maintenance on Twining stores: remove duplicates, flag stale decisions, prune orphaned entities, rotate old metrics, repair index desyncs. Preview by default; execute applies changes.

Instructions

Run periodic maintenance on Twining stores. Preview by default (dry run); preview simulates the full pass pipeline, so its counts match what execute will do on the same state (#39). Removes duplicates, surfaces stale decisions and dangling warnings, prunes orphaned graph entities, rotates old metrics, and backfills missing superseded_by back-links on superseded decisions. The blackboard archive pass is OPT-IN (archive: true): it sweeps every archivable entry regardless of age, keeping decisions, unresolved need/warning/question entries (#40), and the newest archive.retain_recent entries (D4). Pass staleness_review: true to also flag entries whose scope/files/branch are gone. Pass execute: true to apply changes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
archiveNoDefaults to FALSE (D4) — housekeeping no longer sweeps the board as a side effect; repairs like compact_archives can run with execute: true safely. Set archive: true to run the blackboard archive pass: it takes no age cutoff, archiving every archivable entry except decisions, unresolved need/warning/question entries, and the newest archive.retain_recent entries (default 200).
executeNoSet to true to apply changes. Default is false (preview only).
stale_daysNoFlag provisional decisions older than this many days (default: 7)
merge_sweepNoSet to true to detect branches deleted since the last housekeeping run (typically post-merge cleanup) and flag entries provenance-stamped with those branches. First call records the initial branch snapshot and returns no candidates. The branch snapshot is advanced only when execute=true; preview passes leave the baseline untouched so deletions stay visible across multiple previews. Returns candidates only; use twining_archive_stale to act on them. When run alongside staleness_review, branch-gone duplicates are removed from staleness_review (merge_sweep is the more specific signal).
repair_indexNoFiles backend only: detect decision files on disk that are missing from decisions/index.json (index desync — such decisions are invisible to every read path). Preview reports orphan ids; with execute: true, orphans that are recognizably decisions (id matches filename, core fields present) are appended to the index under the index lock; anything else counts in skipped_invalid and is never modified or deleted. This pass runs last, so other housekeeping passes see salvaged decisions on the NEXT call, not this one. On the sqlite backend this reports index_repair_error instead of silently succeeding.
dedup_relationsNoDedup legacy duplicate (source, target, type) graph relations left from before the 2.11 upsert. Survivor is the edge live upserts already merge into (seq-first; the created-at-oldest on the file backend); later duplicates fold their properties in under origin precedence (derived never downgrades declared) and are removed. Duplicates with non-unique ids and groups that fail to fold (e.g. dangling endpoints) are skipped and counted in the report, never silently dropped. Preview by default; execute applies.
amend_candidatesNoReport candidate affected_files for active decisions whose list is empty (scope walk ranked by term overlap). ALWAYS report-only regardless of execute — confirm per record with twining_amend({decision_id, add_affected_files}). Caps: 50 decisions/run, 500 files/scope, 5 candidates each; truncation is reported, never silent.
compact_archivesNoSet to true to scan .twining/archive/*.jsonl for junk generated by the pre-1.24.0 auto-archive feedback loop ('Archive: N entries archived' summary findings, #35) and report how much is reclaimable. With execute: true, junk lines are dropped (streaming, atomic rewrite), archive files left empty are deleted, and an audit-trail finding is posted. Only entries matching the archiver's exact signature are dropped — everything else, including unparseable lines, is preserved.
staleness_reviewNoSet to true to scan blackboard entries and decisions for staleness — flags items whose scope path, affected files, or originating branch no longer exist. Returns candidates only; use twining_archive_stale to act on them.
promote_provisionalsNoSet to true to auto-promote stale provisional decisions to active. Default is false (report only).
repair_entity_scopesNoSet to true to recompute knowledge-graph entity scopes from their decided_by relations. Before scopes became a union, a decision in one scope overwrote the scope another decision had stamped on the same file — leaving entities asserting a single scope that was merely the most recent. Reports what would change; with execute: true, rewrites them. Safe to run repeatedly.
metrics_retention_daysNoRemove metrics older than this many days (default: 30)
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and succeeds. It discloses that preview is a full dry-run simulation whose counts match execute, that the blackboard archive pass is opt-in and ignores age, and that execute:true is required to apply changes. This gives an agent a clear and honest safety model for a multi-pass maintenance tool.

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 front-loaded with the preview/execute safety model, then gives a compact summary of passes, then adds opt-in flags. At roughly 200 words for a 12-parameter tool, it is dense but appropriate; a little redundancy with the parameter schema prevents a perfect score.

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 complex, mutation-capable tool with 12 parameters and no output schema, the description is complete enough: it explains the default safe mode, how to opt into destructive passes, and what the preview simulates. The highly detailed parameter schemas fill in per-pass semantics, and the sibling references for acting on candidates cover the main workflow handoffs.

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 each parameter already has a rich, behavior-focused description (e.g., merge_sweep baseline semantics, repair_index backend differences, compact_archives audit-trail behavior). The top-level description adds only a few parameter pointers like archive:true and staleness_review:true, so it does not elevate meaning beyond the schema.

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 job ('Run periodic maintenance on Twining stores') and enumerates concrete passes: removing duplicates, surfacing stale decisions, pruning orphaned graph entities, rotating metrics, and backfilling back-links. This distinguishes it from focused siblings like twining_prune_graph or twining_archive_stale, though it does not explicitly name those alternatives.

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 actionable invocation rules: preview by default, use execute:true to apply changes, set archive:true for the blackboard pass, and set staleness_review:true for broader staleness detection. The parameter descriptions further point to twining_archive_stale for acting on candidates, which provides explicit alternative routing for some passes, though not for every sibling overlap.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/daveangulo/twining-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server