Skip to main content
Glama
dahshanlabs

klypix-mcp

by dahshanlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Reconcile the brain — contradictions, unrecorded migrations, and what a release already closed

brain_reconcile

Scan your brain for contradictions, unrecorded migrations, legacy cards, and release-ready items. Confirm or dismiss findings to keep knowledge accurate and current.

Instructions

Truth maintenance. (1) CONTRADICTIONS: finds same-subject live card pairs where one carries an explicit correction cue (uppercase "CORRECTION", "was WRONG", "OBSOLETE" — that side is the presumed truth, UNLESS the cue predates its counterpart: then the pair is marked "presumed superseded" and the newer card is presumed current — verify before retiring) or the two use opposite polarity words (deferred↔wired, broken↔fixed, dead↔live), i.e. stale facts whose correction never got linked — candidates only, YOU confirm each: retire the stale card via brain_note ✓. Dismiss a FALSE positive (either kind) by connecting the two ids with brain_connect pairs + relationship:"not_contradiction" — persisted, so it never resurfaces (and its cue stops overlaying recall/ask for that pair). (2) MIGRATIONS: lists committed migration files (Supabase / Rails / Prisma / Knex / generic) that NO brain card references, so an applied-but-unnarrated rollout can be recorded. (3) LEGACY: pre-v1.15 raw-bash ship cards to tidy. (4) RELEASE: which open cards look fulfilled by the commits a release ref already carries (subject+body coverage, the card's own #commit- receipt, or a hint edge whose milestone is in the ref). READ-ONLY by default and on every other mode. THE ONE EXCEPTION: on mode "claims" and mode "release" you may pass confirm/dismiss to actually close what you verified — confirm names exact card ids, so nothing is matched by prose; covering only part of a multi-item clause writes "✔ partial" and KEEPS the card open unless you pass whole:true; a call whose every entry is refused leaves the brain byte-identical. Never reads the database or the network. Run it periodically, when recall surfaces something you believe is stale, or right before cutting a release.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refNomode "release": the git ref being cut. Defaults to this session's active release lease, else HEAD.
modeNoWhich pass to run (default "all"): contradictions · migrations · legacy (pre-v1.15 raw-bash ship cards to tidy) · claims (open "remaining:/next:" clauses a later milestone likely fulfilled — receipts + ✓ markers; confirm with {id, milestoneId}) · plans (plan / proposal / "design decided" cards a LATER 🏁 appears to have built — embedding-first because the ship is usually renamed) · release (open cards the commits in `ref` look to have fulfilled; confirm with {id, sha}).
noteNoOne line of why, echoed in the receipt.
rootNoProject root holding the migrations dir / git repo (default: the brain file's folder).
canvasNoBrain canvas filename/path. Defaults to the project brain ("brain").
confirmNoPairs YOU verified. Honoured on mode "claims" and mode "release" only. Each confirmed card is stamped ✅, archived, and arrowed "closed by" to its evidence.
dismissNoWrong hints to retire permanently as "not_fulfilled" edges between two CARDS — never re-suggested by claims, release, or the self-heal. A card-to-card pair is what makes the dismissal durable; a coverage hint built straight from a commit has no card to point at and will be re-listed at the next release cut until the open card is resolved or the pair is named with a cardId.
sinceRefNomode "release": the baseline the range starts from. Defaults to the highest release-shaped tag in the repo.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.86.0
    • addedInput schema / properties / confirm
      Added value: +{
+  "description": "Pairs YOU verified. Honoured on mode \"claims\" and mode \"release\" only. Each confirmed card is stamped ✅, archived, and arrowed \"closed by\" to its evidence.",
+  "items": {
+    "properties": {
+      "id": {
+        "description": "The OPEN card id to close.",
+        "maxLength": 64,
+        "type": "string"
+      },
+      "milestoneId": {
+        "description": "mode \"claims\": the live milestone card that fulfilled it. Requires an existing \"likely closed by\" link or a current coverage gap on this exact pair.",
+        "maxLength": 64,
+        "type": "string"
+      },
+      "sha": {
+        "description": "mode \"release\": a commit the listing named as covering this card (cov ≥ 0.6, confirmable). Omit to use the card's own #commit- receipt.",
+        "maxLength": 40,
+        "type": "string"
+      },
+      "whole": {
+        "description": "Assert the WHOLE card is done. Without it, covering one item of a multi-item clause writes \"✔ partial\" and the card stays open.",
+        "type": "boolean"
+      }
+    },
+    "required": [
+      "id"
+    ],
+    "type": "object"
+  },
+  "maxItems": 64,
+  "type": "array"
+}
    • addedInput schema / properties / dismiss
      Added value: +{
+  "description": "Wrong hints to retire permanently as \"not_fulfilled\" edges between two CARDS — never re-suggested by claims, release, or the self-heal. A card-to-card pair is what makes the dismissal durable; a coverage hint built straight from a commit has no card to point at and will be re-listed at the next release cut until the open card is resolved or the pair is named with a cardId.",
+  "items": {
+    "properties": {
+      "cardId": {
+        "description": "The milestone/evidence card to dismiss it against (required unless the listing already named one).",
+        "maxLength": 64,
+        "type": "string"
+      },
+      "openId": {
+        "description": "The open card the hint was wrong about.",
+        "maxLength": 64,
+        "type": "string"
+      },
+      "sha": {
+        "description": "Informational only — the commit that produced the wrong hint. A dismissal is recorded against a CARD, so a hint whose only evidence is a raw commit (no milestone card) cannot be dismissed: pass a cardId, or retire the open card itself.",
+        "maxLength": 40,
+        "type": "string"
+      }
+    },
+    "required": [
+      "openId"
+    ],
+    "type": "object"
+  },
+  "maxItems": 64,
+  "type": "array"
+}
    • changedInput schema / properties / mode / description
      Previous value: -"Which pass to run (default \"all\"): contradictions · migrations · legacy (pre-v1.15 raw-bash ship cards to tidy) · claims (open \"remaining:/next:\" clauses a later milestone likely fulfilled — receipts + ✓ markers, never auto-archived) · plans (plan / proposal / \"design decided\" cards a LATER 🏁 appears to have built — embedding-first because the ship is usually renamed; receipts + ✓ markers, never auto-archived)."New value: +"Which pass to run (default \"all\"): contradictions · migrations · legacy (pre-v1.15 raw-bash ship cards to tidy) · claims (open \"remaining:/next:\" clauses a later milestone likely fulfilled — receipts + ✓ markers; confirm with {id, milestoneId}) · plans (plan / proposal / \"design decided\" cards a LATER 🏁 appears to have built — embedding-first because the ship is usually renamed) · release (open cards the commits in `ref` look to have fulfilled; confirm with {id, sha})."
    • changedInput schema / properties / mode / enum
      Previous value: -[
-  "all",
-  "contradictions",
-  "migrations",
-  "legacy",
-  "claims",
-  "plans"
-]New value: +[
+  "all",
+  "contradictions",
+  "migrations",
+  "legacy",
+  "claims",
+  "plans",
+  "release"
+]
    • addedInput schema / properties / note
      Added value: +{
+  "description": "One line of why, echoed in the receipt.",
+  "maxLength": 400,
+  "type": "string"
+}
    • addedInput schema / properties / ref
      Added value: +{
+  "description": "mode \"release\": the git ref being cut. Defaults to this session's active release lease, else HEAD.",
+  "maxLength": 200,
+  "type": "string"
+}
    • changedInput schema / properties / root / description
      Previous value: -"Project root holding the migrations dir (default: the brain file's folder)."New value: +"Project root holding the migrations dir / git repo (default: the brain file's folder)."
    • addedInput schema / properties / sinceRef
      Added value: +{
+  "description": "mode \"release\": the baseline the range starts from. Defaults to the highest release-shaped tag in the repo.",
+  "maxLength": 200,
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so comprehensively. It discloses read-only default ('READ-ONLY by default and on every other mode'), the single exception, the exact effects of confirm/dismiss ('stamped ✅, archived, and arrowed "closed by"'), the partial-write behavior ('writes "✔ partial" and KEEPS the card open'), the atomicity guarantee ('a call whose every entry is refused leaves the brain byte-identical'), and the network/database isolation ('Never reads the database or the network'). This is exemplary transparency.

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 it is exceptionally well-structured with numbered sections and clear sub-points. Each sentence contributes to understanding a complex tool with eight parameters and four modes. It is front-loaded with the core purpose ('Truth maintenance') and the read-only safety note. While it could be tightened (e.g., some redundancy in the contradictions section), the length is justified by the tool's complexity, earning a 4 rather than 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?

Given the tool's complexity, eight parameters, and no output schema, the description is fully complete. It covers all modes, the confirm/dismiss actions with their prerequisites, edge cases like multi-item clauses and false positives, and the persistence of dismissals. An agent has everything needed to call this tool correctly, including when to use each mode and how to interpret results. Nothing essential is missing.

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

Parameters5/5

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

While the schema already describes all 8 parameters (100% coverage), the description adds significant semantic depth beyond the schema. For example, it explains the confirm object's interplay with 'whole:true', the dismiss object's requirement for a cardId to make dismissal durable, and the mode-specific meaning of 'ref' and 'sinceRef'. It also clarifies defaults ('Defaults to this session's active release lease, else HEAD') that the schema does not fully convey. This goes well beyond the baseline.

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 'Truth maintenance' and then enumerates four distinct passes (contradictions, migrations, legacy, release) with concrete examples ('same-subject live card pairs', 'committed migration files', 'pre-v1.15 raw-bash ship cards'). This clearly states what the tool does and differentiates it from any sibling tool, none of which perform this kind of reconciliation. The verb 'reconcile' and resource 'brain' are explicit.

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?

The description explicitly states when to run: 'Run it periodically, when recall surfaces something you believe is stale, or right before cutting a release.' It also explains the exception modes ('on mode "claims" and mode "release" you may pass confirm/dismiss') and gives conditions for each mode, such as what constitutes a contradiction and how to handle false positives. It does not list alternatives, but it references brain_note and brain_connect as complementary tools in the workflow, which effectively routes the agent.

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

Deploy Server

Other Tools