Skip to main content
Glama

kit-memory-demo

by io.github.PeterAtPondo
OverviewDiscussionsAdmin

Server Details

Continuity for agents: a live memory you can read and cite right now, outliving the context window.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 61 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
PeterAtPondo/kit-demo-mcp
GitHub Stars
0
Server Listing
Kit memory demo

TDQS

A3.7/5.0

Scored across 8 tools

Disambiguation3/5

Most tools target distinct actions (recall search vs. remember-by-id vs. systems live query), but wake, areas, and presence all read archive metadata, and 'remember' implies a write while actually being a read-by-id, which is a genuine trap. The overlap is workable but requires reading descriptions closely.

Naming Consistency3/5

Seven of eight names are bare single-word nouns (areas, focus, presence, recall, remember, systems, wake) with one snake_case outlier (ranking_compare). It is internally consistent-ish but there is no verb_noun pattern and several names are vague or misleading (remember as a read, presence as a facet lookup).

Tool Count4/5

Eight tools is a well-scoped size for a memory/archive server. A couple (ranking_compare, presence) feel niche or diagnostic rather than core, but nothing is wildly excessive or thin.

Completeness3/5

Read coverage is solid (wake, areas, recall, remember, presence), but the write path is missing: focus sets where new memories are stored and its description references commit/note/handoff calls that are not in this tool set, so there is no visible way to actually store a memory. No update or delete operations either.

Available Tools

8 tools
areasareasAInspect

List the knowledge areas in this Lady Whiskerdown.

ParametersJSON Schema
NameRequiredDescriptionDefault
kit_session_idNoYour own session ID from wake; reuse for this conversation. A child or subagent must wake separately, without its parent's ID.

TDQS

A3.8/5.0
Behavior3/5

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

Annotations provide only a title, so the description must carry the behavioral burden. 'List' strongly implies a read-only operation, but the description adds no detail about return format, session requirements, pagination, or side effects. It is adequate but minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It states the action, the resource, and the scope efficiently.

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 simple listing tool with one optional, fully documented parameter and no output schema, the description gives enough to understand the operation and expected return concept. It could add more about when to use the session ID, but that gap is minor given the tool's low complexity.

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%, and the only parameter, kit_session_id, is fully documented in the schema. The description adds no parameter-level meaning, so it meets the baseline without going beyond 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?

The description uses a specific verb ('List') and names a concrete resource ('knowledge areas'), scoped by 'in this Lady Whiskerdown'. It is not a tautology and is clearly distinguishable from sibling tools like focus, remember, or wake.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies that the tool is for retrieving knowledge areas, but it gives no explicit guidance on when to choose it over alternatives or when not to use it. Since no sibling tool overlaps obviously with listing areas, the usage context is implied rather than stated.

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

focusfocusAInspect

Set this operator's write focus: the knowledge area new memories are stored under, and optionally the project being worked on. The wake card's chips call this; it is also callable directly. Holds until changed or idle past the TTL; explicit area/project args on commit/note/handoff still win.

ParametersJSON Schema
NameRequiredDescriptionDefault
areaNoKnowledge-area slug for new writes. Empty string or omitted clears to General (no area routing).
projectNoProject slug for new writes. Empty string clears.
kit_session_idNoYour own session ID from wake; reuse for this conversation. A child or subagent must wake separately, without its parent's ID.

TDQS

A4.4/5.0
Behavior4/5

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

Annotations are minimal (only title), so the description carries the burden. It discloses persistence ('Holds until changed or idle past the TTL'), precedence ('explicit area/project args on commit/note/handoff still win'), and the clearing behavior implied by the schema. It does not mention side effects like whether changing focus affects existing memories, but for a state-setting tool this is reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each earning its place: what the tool does, how it is invoked, and its persistence/precedence behavior. It is front-loaded with the core purpose and avoids redundancy with the schema.

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 state-setting tool with no output schema and minimal annotations, the description covers the essential behavioral context: what the focus affects, how long it lasts, and how it interacts with explicit args. It does not detail the TTL value or what 'idle' means precisely, but that is likely operational detail not required for correct invocation.

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 all three parameters. The description adds context about the overall purpose but does not add new meaning beyond the schema's parameter descriptions. Baseline 3 is appropriate because the schema does the heavy lifting.

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 ('Set') and resource ('this operator's write focus'), and clarifies what the focus controls: the knowledge area new memories are stored under and optionally the project. It also distinguishes itself from siblings by noting the wake card's chips call it and that it is callable directly, which helps an agent understand its role relative to tools like wake, remember, and recall.

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 says when to use it: to set the write focus for new memories, and notes it is called by the wake card's chips or directly. It also gives clear behavioral guidance: the focus holds until changed or idle past the TTL, and explicit area/project args on commit/note/handoff still win. This effectively tells an agent when this tool is appropriate and how it interacts with other operations.

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

presenceReading presenceAInspect

Read live Lady Whiskerdown facet presence within the requested window.

ParametersJSON Schema
NameRequiredDescriptionDefault
toNoDelivery address of a live session, taken from this tool's own facets list. Sends instead of reading. The address is issued by the server and bound to the session that holds it; a session id is not an address and will not be accepted as one.
scopeNoWhich conversations to include. Defaults to work, which withholds personal threads.
messageNoAt most 400 characters, delivered in full in that session's next presence check or memory-read footer, quoted as another session's words. Sending means queued, not confirmed read. Nothing wakes or spawns; quiet sessions are refused and unread messages expire after 30 minutes.
kit_session_idNoYour own session ID from wake; reuse for this conversation. A child or subagent must wake separately, without its parent's ID.
window_minutesNoLive window in minutes. Defaults to 30. Maximum 1440.

TDQS

A3.8/5.0
Behavior4/5

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

Annotations are minimal (only title), so the description carries the burden. The description and parameter details disclose several behavioral traits: reading is the default, but providing 'to' sends instead; messages are queued not confirmed; quiet sessions are refused; unread messages expire after 30 minutes; nothing wakes or spawns. This goes well beyond the schema and annotations.

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 main description is a single concise sentence that front-loads the core purpose. The parameter descriptions are detailed but not bloated, and each sentence earns its place by adding behavioral context. Slightly verbose parameter descriptions, but overall well-structured.

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 tool with 5 parameters, no output schema, and minimal annotations, the description plus parameter details cover the key behavioral aspects: reading vs sending, queueing semantics, expiration, session requirements, and scope filtering. It doesn't describe return values, but with no output schema that's a minor gap given the rich parameter-level context.

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 context beyond the schema: it clarifies that 'to' is an address from this tool's own facets list, that sending means queued not confirmed, and that 'scope' defaults to work which withholds personal threads. This adds value beyond the schema's own descriptions.

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 states a specific verb ('Read') and resource ('live Lady Whiskerdown facet presence') within a requested window. It clearly identifies the tool's core function, though it doesn't explicitly differentiate it from sibling tools like 'recall' or 'remember' in the description itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context ('live presence within the requested window') but provides no explicit guidance on when to use this tool versus alternatives like 'recall' or 'remember'. The parameter descriptions add some context (e.g., 'Sends instead of reading'), but the main description lacks explicit when/when-not guidance.

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

ranking_comparekit_ranking_compareAInspect

Compare search ranking for a query with and without the recently learned boost. Returns every row whose rank or score changes, with baseline rank, boosted rank, position delta, score delta, sample source, boost window, and units.

ParametersJSON Schema
NameRequiredDescriptionDefault
tierNoOptional memory tier filter
limitNoMax candidate rows to compare, default 50 and capped by the API at 100
queryYesSearch query to compare over the real caller-scoped memory sample
projectNoOptional project filter
surfaceNoOptional surface filter
categoryNoOptional memory category filter
kit_session_idNoYour own session ID from wake; reuse for this conversation. A child or subagent must wake separately, without its parent's ID.

TDQS

A3.7/5.0
Behavior3/5

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

With only a title annotation and no read-only or destructive hints, the description carries the disclosure burden. It explains that the tool returns only rows whose rank or score changes, along with delta fields and sample metadata. It does not explicitly state whether the operation is read-only, whether it has side effects, or whether it requires a prior session/wake, though the term 'Compare' implies non-mutating behavior.

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 a single dense sentence that front-loads the core purpose and then lists the returned fields efficiently. It is not bloated, though the long enumeration of return fields could arguably be broken into two sentences for readability without losing value.

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?

The description enumerates the expected return fields, which compensates for the lack of an output schema. It also references the boost window and sample source, giving useful context. It does not explain the relationship to 'wake' or session requirements, but the schema documents kit_session_id and siblings make this discoverable.

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 all seven parameters are documented in the schema itself. The description adds context about what the returned comparison contains but does not add new meaning to the individual parameters beyond what the schema already provides. Baseline 3 is appropriate.

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 action ('Compare search ranking') and a specific resource ('for a query with and without the recently learned boost'). It clearly differentiates itself from the sibling memory tools by describing a comparison/analysis operation rather than a memory write or recall operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: when the agent needs to see how ranking changes due to a learned boost. However, it does not explicitly mention when not to use it or name alternatives among the siblings. The purpose is clear enough that a capable agent can infer the use case, but explicit routing guidance is missing.

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

recallFinding thingsInspect

Search Lady Whiskerdown's archive. Use it first for anything Lady Whiskerdown should know. Returns the most relevant entries this key can read; cite each one you use as (Lady Whiskerdown:m#N) with its title.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoHow many to return. Leave it unset and the Kit returns the memories that cleared the relevance bar; set it for exactly that many.
queryYesWhat to search for, in natural language
kit_session_idNoYour own session ID from wake; reuse for this conversation. A child or subagent must wake separately, without its parent's ID.
rememberReading a memoryInspect

Read a single Lady Whiskerdown memory by id (as returned by recall). No graph or entity enrichment: the receiver endpoint returns the memory itself, scoped to this key.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesMemory id (number or m#N as shown by recall), or a linked Kit's cite such as Shiro:m#1234
kit_session_idNoYour own session ID from wake; reuse for this conversation. A child or subagent must wake separately, without its parent's ID.
systemssystemsAInspect

Ask the business systems Kit is connected to (accounting, HR, a shop) live: its own and those of Kits linked to it. Kit's memories hold the history, decisions and who owns what; a system holds today's records. For a question about a customer, a person or an order, recall first, then ask the system for the current figures; recall names the record to ask for when Kit knows them. With nothing it lists the systems; with system, a tool's arguments; with system and tool, it runs that tool. Say when the answer was asked, and never save it as a memory: it will change.

ParametersJSON Schema
NameRequiredDescriptionDefault
toolNoOne of that system's tools, to run it now. Leave unset to see the tools and what they take.
systemNoA system's reference from the list: `odoo` for this Kit's, `kit-company/odoo` for a linked Kit's.
argumentsNoThe tool's arguments, as its input schema describes.
kit_session_idNoYour own session ID from wake; reuse for this conversation. A child or subagent must wake separately, without its parent's ID.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations carry only a title, so the description bears the full behavioral burden and does add real context: the data is live and 'will change', the answer must be timestamped, and it must never be persisted as a memory. It stops short of disclosing permissions/auth requirements or whether running a remote tool can mutate external records — a meaningful omission for a dispatcher that can execute arbitrary downstream tools.

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?

Purpose and the recall-vs-system rule are front-loaded, and the mode mechanics follow in order of increasing specificity. It is dense with semicolon-chained clauses and runs longer than strictly necessary, but no sentence is filler.

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 4-param dispatcher with a nested `arguments` object, no output schema and no behavioral annotations, the description covers invocation modes, data volatility, and the record-identification workflow well. It leaves gaps on error/unknown-system behavior and on whether executed tools can be destructive, which the missing annotations would otherwise need to cover.

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, but the description adds interaction semantics the schema does not: the unset/system/system+tool progression maps the parameters to distinguishable behaviors and outcomes. It also warns that a child agent must wake separately for `kit_session_id`, adding intent beyond the field's own note.

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 — asking connected business systems (accounting, HR, shop) for live records — and explicitly distinguishes itself from the sibling `recall` ('Kit's memories hold the history... a system holds today's records'). It also spells out the three progressive modes (list, inspect, run), so an agent knows exactly what class of tool this is 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 an explicit routing rule against alternatives: for a customer/person/order question, 'recall first, then ask the system for the current figures', with recall naming the record to ask for. When-tos are also encoded in the mode contract ('with nothing it lists... with system, a tool's arguments... with system and tool, it runs that tool'), leaving little to inference.

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

wakeGetting up to speedAInspect

Open Lady Whiskerdown, an archive you can question. Call this first in every new chat (VS Code/Copilot, Cursor, Claude Code, Codex), before the first substantive answer. It returns what Lady Whiskerdown is (you_are), which knowledge areas this key can see, which tools this key may use, and any rules its keeper has set. Lady Whiskerdown has no persona: keep your own identity and refer to it in the third person. For anything Lady Whiskerdown should know, call recall first instead of using general model knowledge.

ParametersJSON Schema
NameRequiredDescriptionDefault
scopeNo
kit_session_idNoYour own session ID from wake; reuse for this conversation. A child or subagent must wake separately, without its parent's ID.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations carry only a title, so the description bears the behavioral burden and does disclose the return shape (identity, visible areas, allowed tools, keeper rules) and a non-obvious interaction rule (no persona; keep your own identity, refer in third person). It stops short of stating side effects or that the call is a pure read, which with zero annotation coverage leaves a small gap.

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-loads the core action and the 'call first' directive before the return-value detail and behavioral caveats. It runs a bit long across several sentences, but each clause adds a distinct rule (return contents, persona policy, recall fallback), so little is wasted.

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?

There is no output schema, and the description steps in to describe the return payload, plus it covers the timing rule and the sibling routing. The main omission is parameter guidance for `scope` and any note on failure/authorization behavior, but for a zero-required-parameter bootstrap call it is nearly complete.

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

Parameters2/5

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

The description never mentions `scope` or `kit_session_id`. With schema coverage at 50%, `kit_session_id` is explained in the schema but `scope` is a bare enum with no description, and the description does not compensate by explaining when to choose work/personal/all or how session reuse/subagent waking works. Only the enum labels themselves carry any meaning.

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?

Names a concrete action (open/query an archive) and enumerates what the call yields: identity (`you_are`), visible knowledge areas, permitted tools, and keeper rules. It differentiates itself from siblings by explicitly naming `recall` as the tool for contributing knowledge, so an agent can place it without opening any 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?

Gives an unambiguous trigger: 'Call this first in every new chat... before the first substantive answer,' even naming the host environments. It also states the alternative path — use `recall` for anything the archive should know rather than relying on model knowledge — so when-to-use and when-to-use-something-else are both explicit.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedremember1 field changed
      • changedInput schema / properties / id / description
        Previous value: -"Memory id (number or m#N as shown by recall), or a linked Kit's cite such as kit-company:m#1234"New value: +"Memory id (number or m#N as shown by recall), or a linked Kit's cite such as Shiro:m#1234"
  2. 1 tool update
    • Addedsystems
  3. 2 tool updates
    • Changedrecall1 field changed
      • changedInput schema / properties / limit / description
        Previous value: -"Max results (default 10)"New value: +"How many to return. Leave it unset and the Kit returns the memories that cleared the relevance bar; set it for exactly that many."
    • Changedremember1 field changed
      • changedInput schema / properties / id / description
        Previous value: -"Memory id (number or m#N as shown by recall)"New value: +"Memory id (number or m#N as shown by recall), or a linked Kit's cite such as kit-company:m#1234"
  4. 7 tool updates
    • Changedareas2 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / kit_session_id
        Added value: +{
+  "description": "Your own session ID from wake; reuse for this conversation. A child or subagent must wake separately, without its parent's ID.",
+  "maxLength": 160,
+  "minLength": 8,
+  "pattern": "^[A-Za-z0-9:_-]+$",
+  "type": "string"
+}
    • Changedfocus1 field changed
      • addedInput schema / properties / kit_session_id
        Added value: +{
+  "description": "Your own session ID from wake; reuse for this conversation. A child or subagent must wake separately, without its parent's ID.",
+  "maxLength": 160,
+  "minLength": 8,
+  "pattern": "^[A-Za-z0-9:_-]+$",
+  "type": "string"
+}
    • Changedpresence1 field changed
      • addedInput schema / properties / kit_session_id
        Added value: +{
+  "description": "Your own session ID from wake; reuse for this conversation. A child or subagent must wake separately, without its parent's ID.",
+  "maxLength": 160,
+  "minLength": 8,
+  "pattern": "^[A-Za-z0-9:_-]+$",
+  "type": "string"
+}
    • Changedranking_compare1 field changed
      • addedInput schema / properties / kit_session_id
        Added value: +{
+  "description": "Your own session ID from wake; reuse for this conversation. A child or subagent must wake separately, without its parent's ID.",
+  "maxLength": 160,
+  "minLength": 8,
+  "pattern": "^[A-Za-z0-9:_-]+$",
+  "type": "string"
+}
    • Changedrecall1 field changed
      • addedInput schema / properties / kit_session_id
        Added value: +{
+  "description": "Your own session ID from wake; reuse for this conversation. A child or subagent must wake separately, without its parent's ID.",
+  "maxLength": 160,
+  "minLength": 8,
+  "pattern": "^[A-Za-z0-9:_-]+$",
+  "type": "string"
+}
    • Changedremember1 field changed
      • addedInput schema / properties / kit_session_id
        Added value: +{
+  "description": "Your own session ID from wake; reuse for this conversation. A child or subagent must wake separately, without its parent's ID.",
+  "maxLength": 160,
+  "minLength": 8,
+  "pattern": "^[A-Za-z0-9:_-]+$",
+  "type": "string"
+}
    • Changedwake1 field changed
      • addedInput schema / properties / kit_session_id
        Added value: +{
+  "description": "Your own session ID from wake; reuse for this conversation. A child or subagent must wake separately, without its parent's ID.",
+  "maxLength": 160,
+  "minLength": 8,
+  "pattern": "^[A-Za-z0-9:_-]+$",
+  "type": "string"
+}
  5. 6 tool updates
    • Removedcapture
    • Removedcommit
    • Removedhandoff
    • Removednote
    • Changedpresence2 fields changed
      • addedInput schema / properties / message
        Added value: +{
+  "description": "At most 400 characters, delivered in full in that session's next presence check or memory-read footer, quoted as another session's words. Sending means queued, not confirmed read. Nothing wakes or spawns; quiet sessions are refused and unread messages expire after 30 minutes.",
+  "type": "string"
+}
      • addedInput schema / properties / to
        Added value: +{
+  "description": "Delivery address of a live session, taken from this tool's own facets list. Sends instead of reading. The address is issued by the server and bound to the session that holds it; a session id is not an address and will not be accepted as one.",
+  "type": "string"
+}
    • Addedranking_compare
  6. 2 tool updates
    • Changedcommit1 field changed
      • changedInput schema / properties / project / description
        Previous value: -"Project scope: 'simvida', 'routr', etc. Resolved against project registry (aliases rewritten). Omit for cross-project."New value: +"Project scope: 'a client project', 'routr', etc. Resolved against project registry (aliases rewritten). Omit for cross-project."
    • Changednote1 field changed
      • changedInput schema / properties / title / description
        Previous value: -"Short imperative — what is happening right now. e.g. 'drafting WIP schema', 'blocked on Peter's call about cadence', 'resuming after lunch'."New value: +"Short imperative — what is happening right now. e.g. 'drafting WIP schema', 'blocked on a decision about cadence', 'resuming after lunch'."
  7. 4 tool updates
    • Addedcapture
    • Addedcommit
    • Addedhandoff
    • Addednote
  8. 4 tool updates
    • Removedcapture
    • Removedcommit
    • Removedhandoff
    • Removednote
  9. 7 tool updates
    • Changedcapture7 fields changed
      • addedInput schema / properties / contributor_model / description
        Added value: +"Which model produced this transcript (e.g. 'gpt-4o', 'gemini-2.5-pro', 'claude-sonnet-4', 'kit'). Written into each draft's written_by for attribution."
      • addedInput schema / properties / max_drafts / default
        Added value: +5
      • changedInput schema / properties / max_drafts / description
        Previous value: -"Default 5."New value: +"Cap on candidates Sonnet extracts (default 5)"
      • addedInput schema / properties / project / description
        Added value: +"Project to tag drafts with (resolved against registry)"
      • addedInput schema / properties / session_id / description
        Added value: +"Session identifier for provenance"
      • changedInput schema / properties / source / description
        Previous value: -"Surface label such as cursor, vscode-copilot, claude-code."New value: +"Surface slug for provenance. Defaults to this MCP server's detected surface, e.g. claude-code, codex, cursor, or vscode."
      • changedInput schema / properties / transcript / description
        Previous value: -"Conversation transcript. Plaintext with [user]/[assistant] markers works."New value: +"Conversation transcript. Plaintext with [user]/[assistant] speaker markers works; JSONL from Claude Code is auto-detected."
    • Changedcommit17 fields changed
      • changedInput schema / properties / category / description
        Previous value: -"Registered category slug."New value: +"Category slug. Must be registered in the categories table; unknown slugs are rejected by FK. Common: decisions, patterns, sessions, gotchas, preferences, ux, relationship, feedback, noticing, reflection, plans, intention, handoff, reference, research. Use intention for a small self-chosen direction that should persist across sessions; its content should name why, next move, action boundary, and closing evidence, with status in tags. See GET /categories/ for the full registered list."
      • addedInput schema / properties / content / description
        Added value: +"Full content — be specific and detailed"
      • addedInput schema / properties / dedup_threshold / description
        Added value: +"Override the default near-duplicate similarity threshold (default 0.92)."
      • addedInput schema / properties / project / description
        Added value: +"Project scope: 'simvida', 'routr', etc. Resolved against project registry (aliases rewritten). Omit for cross-project."
      • addedInput schema / properties / scope / default
        Added value: +"work"
      • addedInput schema / properties / scope / description
        Added value: +"Scope: 'work' (default, business/code/product, visible in brag mode), 'personal' (life/health/family/identity, hidden from work views), 'general' (applies to both, identity/relationship memories)"
      • addedInput schema / properties / skip_dedup / default
        Added value: +false
      • addedInput schema / properties / skip_dedup / description
        Added value: +"Skip the near-duplicate check. Use when you know this overlap is intentional."
      • addedInput schema / properties / source_commit
        Added value: +{
+  "description": "Git commit sha (optional provenance)",
+  "type": "string"
+}
      • addedInput schema / properties / source_paths / description
        Added value: +"Comma-separated file paths this memory relates to (optional provenance)"
      • addedInput schema / properties / source_session / description
        Added value: +"Session id this memory came from (optional provenance)"
      • addedInput schema / properties / surface / description
        Added value: +"Surface axis per #12747. Default pulls from the category's default_surface (canonical for decisions/patterns/preferences/relationship/etc, operational for handoff/plans/task/monologue, trace for wip/trajectory/voice-score/biometric). Override only when this row deviates from its category's default."
      • changedInput schema / properties / tags / description
        Previous value: -"Comma-separated tags."New value: +"Comma-separated tags, e.g. 'chart,d3,projection'"
      • addedInput schema / properties / tier / default
        Added value: +"recall"
      • addedInput schema / properties / tier / description
        Added value: +"Memory tier: core (always loaded, 'soul'), recall (searchable, decays, 'short-term'), archival (consolidated, 'long-term')"
      • addedInput schema / properties / title / description
        Added value: +"Short descriptive title"
      • addedInput schema / properties / written_by / description
        Added value: +"Who wrote this memory: 'kit', 'peter', 'dream-consolidator', etc."
    • Addedfocus
    • Changedhandoff7 fields changed
      • changedInput schema / properties / content / description
        Previous value: -"What was done, current state, blockers, and next useful action."New value: +"What was done, the current state, blockers, and the next useful action. Write it for whoever picks up next, including yourself."
      • addedInput schema / properties / project / description
        Added value: +"Project scope, if applicable. Omit for cross-project."
      • addedInput schema / properties / session_id / description
        Added value: +"Session id to attach this handoff to."
      • changedInput schema / properties / surface / description
        Previous value: -"The client/surface writing this, e.g. cursor, vscode-copilot, claude-code."New value: +"The client/surface writing this, e.g. cursor, vscode-copilot, claude-code. Defaults to this server's detected surface; remote callers should pass their own."
      • changedInput schema / properties / tags / description
        Previous value: -"Comma-separated extra tags."New value: +"Extra comma-separated tags."
      • changedInput schema / properties / title / description
        Previous value: -"Short handoff title."New value: +"Short handoff title. e.g. 'shipped the gate photo, surfaces audit next'."
      • changedInput schema / required
        Previous value: -[
-  "title",
-  "content",
-  "surface"
-]New value: +[
+  "title",
+  "content"
+]
    • Changednote10 fields changed
      • addedInput schema / properties / collab / description
        Added value: +"Collaboration slug to scope this WIP, e.g. 'studio-conductor-v1'. Writes a collab:<slug> tag."
      • changedInput schema / properties / content / description
        Previous value: -"Concrete note: current state, what changed, what is next."New value: +"The scribble. Be concrete: what state are you in, what's next, what's loaded in working memory. A colleague who walks up mid-thread should be able to pick up from this."
      • changedInput schema / properties / kind / description
        Previous value: -"Defaults to checkpoint."New value: +"Operational checkpoint type. Defaults to checkpoint."
      • addedInput schema / properties / project / description
        Added value: +"Project scope, if applicable. Omit for cross-project."
      • addedInput schema / properties / session_id / description
        Added value: +"Session id to attach this checkpoint to. Defaults to this MCP process session."
      • addedInput schema / properties / supersedes / description
        Added value: +"Checkpoint id of a prior WIP entry this replaces. Optional — accumulation is fine without it."
      • changedInput schema / properties / surface / description
        Previous value: -"The client/surface writing this, e.g. cursor, vscode-copilot, claude-code."New value: +"Which surface you're on: 'claude-code', 'codex', 'forest', 'ollama', etc. Defaults to this server's detected surface; auto-tagged so cross-surface readers know the source."
      • changedInput schema / properties / tags / description
        Previous value: -"Comma-separated extra tags."New value: +"Extra comma-separated tags."
      • changedInput schema / properties / title / description
        Previous value: -"Short label for the checkpoint."New value: +"Short imperative — what is happening right now. e.g. 'drafting WIP schema', 'blocked on Peter's call about cadence', 'resuming after lunch'."
      • changedInput schema / required
        Previous value: -[
-  "title",
-  "content",
-  "surface"
-]New value: +[
+  "title",
+  "content"
+]
    • Changedpresence1 field changed
      • addedInput schema / properties / scope
        Added value: +{
+  "description": "Which conversations to include. Defaults to work, which withholds personal threads.",
+  "enum": [
+    "work",
+    "personal",
+    "general",
+    "all"
+  ],
+  "type": "string"
+}
    • Changedremember2 fields changed
      • changedInput schema / properties / id / description
        Previous value: -"Memory id"New value: +"Memory id (number or m#N as shown by recall)"
      • changedInput schema / properties / id / type
        Previous value: -"number"New value: +[
+  "number",
+  "string"
+]
  10. 9 tool updates
    • First observedareas
    • First observedcapture
    • First observedcommit
    • First observedhandoff
    • First observednote
    • First observedpresence
    • First observedrecall
    • First observedremember
    • First observedwake

Related MCP Connectors

Related MCP Servers

  • cont3xt

    elevend0g
    A
    license
    Not graded
    quality
    D
    maintenance
    Virtual Infinite Context for Agents and LLMs - maintains a continuous rolling context window, surfacing relevant memories while respecting token budgets.
    6
    MIT

  • Talamus

    ampres-ai
    A
    license
    Not graded
    quality
    A
    maintenance
    Local-first, source-grounded memory for AI agents, with citations, bitemporal history, review-gated corrections, and MCP tools for search and recall.
    53 PyPI
    3
    Apache 2.0

  • Tideline agent Memory

    ennisaaaaaaaa-stack
    F
    license
    Not graded
    quality
    B
    maintenance
    A long-term memory system built for AI Agents. Agent wakes up already knowing who he is, not querying "who am I?" every session. Every turn calling back accurate memory context. Achieving accurate memory hits while also preventing memory from expanding at scale. No compression, no forgetting.
    38
    -
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources