Skip to main content
Glama
dahshanlabs

klypix-mcp

by dahshanlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Write a deliberate note to the project brain (decision / question / milestone / skill / resolve / update)

brain_note

Record decisions, open questions, milestones, and reusable skills into the project brain, and resolve or update matching cards to keep shared memory current.

Instructions

Record something in the project brain ON DEMAND — the agent-neutral twin of the Claude-Code capture hook, so any client (Cursor / Cline / Desktop) can write the brain, not just read it. Unlike add_to_canvas (a flat append), this routes through the brain's capture engine, so a new decision SUPERSEDES a heavily-overlapping older one, ✓ RESOLVES/archives a matching card, closes: resolves the strategy/question a milestone fulfils, and ~ UPDATES a card in place — the full decision lifecycle, with dedup. Use marker "+" to record a 🛠️ SKILL — a reusable how-to/gotcha/convention ("always dedup zKeys before REORDER") that should resurface every session and never age out, distinct from a one-time decision. Use it to remember a decision, ask an open question, mark a milestone, log a skill, resolve a finished item, or correct a card. Defaults to the project brain ("brain").

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
areaNoArea/topic — routes the card into that titled container and becomes a #tag (e.g. "Auth", "Release").
textYesThe note — one concise idea; the first line becomes the card title.
guardNoGUARD CARDS: make this '+' skill fire BEFORE a matching tool call runs (Claude Code PreToolUse denies on severity block; other hosts warn), not just resurface in briefs. The card stays a normal 🛠️ rule — ✓-resolving it retires the guard, ~ with {remove:true} disarms it.
canvasNoBrain canvas filename/path. Defaults to the project brain ("brain").
closesNoTitle or [[wikilink]] of a strategy/question card this note fulfils — resolves+archives it and draws a "closed by" arrow.
markerNo(none)=decision · ?=open question · !=milestone · +=🛠️ skill (reusable how-to/gotcha; always resurfaces, never ages out) · ✓=resolve+archive the best-matching card · ~=update the matching card in place. Default: decision.
verifyNoVerification instructions or command text to retain and display. Never executed by KLYPIX. On ~, an empty string clears it.
evidenceNoSupporting references. File bytes are fingerprinted as captured working-tree sources; hashes only detect source changes. On ~, [] clears evidence. Not accepted on resolve; use a milestone with closes to attach new evidence.
questionNoThe question this note ANSWERS, phrased as someone would ask it ("how do we keep a draft separate from what runs?"). Recorded as retrieval enrichment beside the vector cache — never on the canvas — so the card is found by paraphrase, not only by its own words. The session's declared intent is recorded as well.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.86.0
    • addedInput schema / properties / question
      Added value: +{
+  "description": "The question this note ANSWERS, phrased as someone would ask it (\"how do we keep a draft separate from what runs?\"). Recorded as retrieval enrichment beside the vector cache — never on the canvas — so the card is found by paraphrase, not only by its own words. The session's declared intent is recorded as well.",
+  "maxLength": 240,
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.7/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 behavioral burden, and it does so thoroughly. It discloses dedup, superseding/resolving/archiving semantics, guard-card firing behavior, the fact that verify instructions are never executed by KLYPIX, evidence fingerprinting caveats, and that question text is stored beside the vector cache rather than on the canvas. This goes far beyond what the schema alone reveals.

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, front-loading purpose and differentiation before moving into marker semantics and guard behavior. Some material is also present in the schema, but the description uses it to convey operational intent rather than mere definitions. It earns most of its length, though a tighter version could reduce minor 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?

For a high-complexity tool with 9 parameters, nested guard objects, and no output schema, the description covers purpose, usage, lifecycle effects, guard behavior, and side effects well. The main gap is that it does not state what the tool returns or how the agent should interpret the outcome, which is more noticeable because no output schema exists.

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 description coverage is 100%, so the baseline is 3; the description adds meaningful semantic context on top of the schema, such as the lifecycle meaning of markers, guard-card triggering, and the distinction between skills and one-time decisions. It does not repeat every parameter definition, which is appropriate given the schema's thoroughness.

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 names a specific verb ('Record something in the project brain ON DEMAND') and a clear resource (the project brain), and explicitly contrasts itself with add_to_canvas as a flat append. The title enumerates the supported note kinds, and the body explains the full decision lifecycle. An agent can tell exactly what this tool is for.

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 gives explicit when-to-use guidance: remember a decision, ask an open question, mark a milestone, log a skill, resolve a finished item, or correct a card. It also names the relevant alternative (add_to_canvas) and states the distinguishing condition ('a flat append' vs routing through the capture engine). Marker-specific guidance further clarifies when to use '+', '✓', and '~'.

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