Skip to main content
Glama
dahshanlabs

klypix-mcp

by dahshanlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

KLYPIX Context Gateway — synchronize task, peers, conflicts, and relevant memory

brain_sync
Idempotent

APPROVAL-FREE task gateway over the authorized MCP connection. Call FIRST with a concise intent and expected files, again when scope changes, and with phase:"complete" before the final response.

Instructions

APPROVAL-FREE task gateway over the authorized MCP connection. Call FIRST with a concise intent and expected files, again when scope changes, and with phase:"complete" before the final response. One bounded response returns compact task-relevant brain context, active TASK peers (idle connections hidden), one-time messages, structured exact-file conflicts, and late-arrival overlap alerts. A completion that supplies machine-checkable result manifests is fail-closed: invalid, conflicting, or incomparable evidence returns needs-reconciliation and retains task scope. results is ONLY for such manifests, never a summary of the work: with nothing machine-checkable to claim, complete without it. Works on any MCP host — it needs only the authorized MCP connection, so native lifecycle hooks are optional. LIMITS: blocking overlap is EXACT-PATH over the declared files of each session plus the edits its host observed; sessions on different branches are also test-merged with git merge-tree (committed work only); a same-folder overlap is an advisory notice; coordination/result reconciliation is machine-local and OS-user-local (a teammate on another machine is invisible), and file overlap remains ADVISORY.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesNoProject-relative files you expect to touch or have touched. Exact overlaps with peers are flagged.
phaseNostart replaces prior task scope; checkpoint merges changed scope; complete clears task intent/files. Default: checkpoint.
intentNoOne sentence describing the current task. Supply for start/checkpoint; completion clears it.
projectNoNonempty absolute current project root that directly contains brain.klypix or brain.any. Supply it on phase "start" so routing stays correct even when the MCP host launches from its own install directory.
resultsNoOn phase complete, 1-8 result manifests for stable claim keys. The in-handler versioned validator rejects malformed, empty, unknown-field, or incomparable evidence and retains task scope.
releaseClaimNoStake a durable claim that specific commits ride the NEXT release — the promise "you'll see it in the next build" made machine-readable. Unlike presence rows (which age out ~10min after a session ends), a claim persists until fulfilled (the release ref contains the shas — auto-retired with a courtesy note), withdrawn, or expired (14d). A release that would drop claimed shas is REFUSED until they are acknowledged BY NAME, and acknowledging them away notifies the owner. Use exactly one of shas (stake/extend) or withdraw.
releaseIntentNoDeclare EXCLUSIVE intent to prepare a release of this project. The first declarer takes a ~2h lease (refreshed by checkpoints, freed by phase "complete", by expiry, or when the holder session ends); a second declarer gets a structured hard conflict naming the holder, version, and ref. While any lease is active every peer's sync gains a "release in preparation" footer line. A NEW declaration is also checked against what the release would LEAVE BEHIND: if the ref is missing commits that are on trunk or on a branch a live peer session is working on, OR commits any session STAKED a releaseClaim on (even one that has since ended), the lease is REFUSED (nothing is changed) and the response lists them — report those commits to the user, then re-declare with acknowledge:[...] naming each sha if the release should go ahead without them. Acknowledging away a claimed or live-owned commit queues its owner a notification automatically.
include_contextNoInclude fast task-relevant brain cards and offer queued coordination notes in the same response. Defaults true; false also defers note delivery so internal supervisor probes cannot consume model-visible messages.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only give the safety profile (idempotent, non-destructive, closed-world), and the description adds substantial behavior beyond that: fail-closed reconciliation that "retains task scope" on invalid evidence, the rule that block overlap is EXACT-PATH plus git merge-tree test-merges, that same-folder overlap is advisory, and that coordination is machine-local and OS-user-local ("a teammate on another machine is invisible"). The scope, failure, and visibility limits are fully disclosed.

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 key action — call first, call on scope change, call before completion — is front-loaded, and the response payload is summarized early. It is information-dense and each clause carries load, though the LIMITS block and lowercase-est clause stacking make it heavier to parse than ideal.

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 an 8-parameter, no-output-schema, nested-object tool, the description supplies the lifecycle, the returned payload, and the hard limits, which is close to complete. It does not cover include_context or the release-lease mechanics in prose (left to the schema), so it is not exhaustive, but nothing needed to call it correctly is missing.

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 schema already documents every parameter, including phase, files, results, releaseClaim, and releaseIntent in depth. The description reinforces a few of these (results is "ONLY for such manifests, never a summary of the work"; phase-based scope replacement), but adds little that the schema does not already state. Baseline 3 is appropriate.

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 uses a specific verb and resource — "task gateway" that returns "compact task-relevant brain context, active TASK peers... one-time messages, structured exact-file conflicts, and late-arrival overlap alerts" — so an agent knows precisely what comes back. It is clear and multi-faceted, but it never names a sibling (e.g. brain_reconcile, brain_handoff) to bound it, which is the only thing keeping it short of a 5.

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?

It gives explicit call timing: "Call FIRST with a concise intent and expected files, again when scope changes, and with phase:'complete' before the final response." That is a concrete lifecycle recipe. It stops short of a 5 because it offers no exclusions or named alternatives for when another tool would be preferable.

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