Skip to main content
Glama
Sign In
klypix-mcp

klypix-mcp

by dahshanlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Independent first pass for a review or decision (withhold peer opinions until you record yours)

brain_review

Collects independent assessments on a topic before revealing peer opinions, so each session records its own first-pass review. Start a pass, submit your assessment, then see what others concluded.

Instructions

Opt-in, for a review or a decision several sessions weigh in on. action "start" with a topic: from then on brain_sync and brain_ask leave out assessments and objections from OTHER sessions on that topic for this session (facts, decisions and evidence stay visible), so your first view is your own. action "submit" with your assessment: records it as a 🔎 ASSESSMENT card and shows you the withheld peer opinions. action "status" says whether a pass is open. LIMIT: KLYPIX only controls what KLYPIX returns; it cannot stop you from reading the brain file, notes or other sessions directly, so this records an independent first pass, it does not enforce one. Related, in brain_note: start the text with "OBJECTION:" to record an objection that stays open until a decision or evidence that links it (closes:) answers it; end it with lines "source: …", "restates: " or "rechecked: " to record where a claim came from.

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": {
      "action": "<action>"
    },
    "name": "brain_review"
  }
}

Input Schema

NameRequiredDescriptionDefault
areaNoOn submit: brain area for the assessment card (default "Review").
topicNoOn start: what you are reviewing or deciding, in a few words.
actionYesstart a pass on a topic, submit your own assessment, or check status.
canvasNoBrain canvas filename/path. Defaults to the project brain ("brain").
assessmentNoOn submit: your own assessment, formed before seeing peer opinions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.110.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only cover openWorldHint/idempotentHint/destructiveHint; the description adds far more: exactly which data is hidden from brain_sync and brain_ask (assessments and objections) versus what stays visible (facts, decisions, evidence), that submit creates a 🔎 ASSESSMENT card and then reveals withheld opinions, and a candid LIMIT clause saying independence is recorded, not enforced. That limit disclosure is precisely the kind of context annotations cannot carry.

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?

Front-loaded with the trigger condition, then the three actions in order, then the limit caveat — a sensible structure with little waste. The closing brain_note sentence is useful cross-referencing but is about a different tool's behavior and adds length that isn't strictly needed to invoke this one.

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?

With five parameters, no output schema, and thin annotations, the description carries most of the burden and does so well: mechanism, data visibility, side effects, and limitations are all covered. Minor gaps remain — what "status" reports back, what happens if a pass is already open, and whether submit without a prior start is valid.

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 is 3. The description reinforces which parameter pairs with which action (topic on start, assessment on submit), but that mapping is already stated in the schema's own parameter descriptions, and area and canvas are left entirely to the schema.

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+resource (start/submit/status a first-pass review) and the mechanism it controls: brain_sync and brain_ask withhold peer assessments and objections for this session. It explicitly names the sibling tools it affects (brain_sync, brain_ask) and the related one (brain_note), so an agent can distinguish it from neighbors without opening schemas.

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?

"Opt-in, for a review or a decision several sessions weigh in on" gives an explicit trigger condition, and each action is bound to its situation (start with a topic, submit with your assessment, status to check whether a pass is open). It also routes objection-recording to brain_note with the exact text convention, so the alternative path is named rather than inferred.

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