klypix-mcp

Overview Schema Source Related Servers Discussions Admin

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

brain_note

Record decisions, questions, milestones, or skills in the project brain with deduplication and full decision lifecycle handling.

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") kept until corrected and shown first to sessions that touch the files it names, distinct from a one-time decision. When the mistake is mechanical, end the text with a rule: suffix to make the lesson RULE-READY: repo globs, then never "<text>", never /<regex>/, must "<text>", listed-in <file>[,<file>], keep-eol or costly — e.g. rule: web/tests/**/*.test.ts never "from '@/". The globs must name tracked files; it lands as a visible "⚙ rule candidate" line that nothing checks until brain_rules adds it and a person approves it. 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").

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "text": "<text>"
    },
    "name": "brain_note"
  }
}

Input Schema

Name	Required	Description
`area`	No	Area/topic — routes the card into that titled container and becomes a #tag (e.g. "Auth", "Release").
`text`	Yes	The note — one concise idea; the first line becomes the card title.
`guard`	No	GUARD 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.
`canvas`	No	Brain canvas filename/path. Defaults to the project brain ("brain").
`closes`	No	Title or [[wikilink]] of a strategy/question card this note fulfils — resolves+archives it and draws a "closed by" arrow.
`marker`	No	(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.
`verify`	No	Verification instructions or command text to retain and display. Never executed by KLYPIX. On ~, an empty string clears it.
`evidence`	No	Supporting 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.
`question`	No	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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.86.0Sep 17, 2026

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"
+}

First observedv0.1.0Sep 8, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden well: it discloses deduplication, superseding of overlapping decisions, resolution/archiving, in-place updates, skill persistence, and that rule candidates are inert until brain_rules adds them and a person approves. It does not describe the response or error behavior, but it adds substantial lifecycle context beyond what an agent could infer from the name.

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 front-loaded with the core purpose and sibling differentiation before moving into marker and rule details. Most sentences earn their place by explaining non-obvious behavior, though the density and examples make it heavier than strictly necessary.

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 complex write tool with nine parameters, nested guard data, and no output schema, the description covers the decision lifecycle, skill behavior, rule readiness, and default targeting. The remaining gaps are mostly around result/error behavior, while guard mechanics are documented in the schema rather than the main description.

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 schema already defines most parameters. The description still adds useful semantic context for marker usage, especially '+' for skills and the `rule:` suffix syntax, and it clarifies that the default canvas is the project brain; this goes beyond simply restating the schema fields.

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 states a specific verb and resource: 'Record something in the project brain', and explicitly distinguishes this tool from the sibling add_to_canvas by saying it routes through the capture engine rather than performing a flat append. It also names the lifecycle operations it supports (supersede, resolve/archive, update), so an agent can identify the tool's role without opening the schema.

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?

It gives explicit usage conditions: ON DEMAND capture for any client, use '+' for reusable skills, use a `rule:` suffix for mechanical mistakes, and use it to remember decisions, ask questions, mark milestones, log skills, resolve items, or correct cards. It also names add_to_canvas as the alternative for flat appends, making the routing decision clear.

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