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 with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.9% over 41 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.5/5.0

Scored across 7 tools

Disambiguation3/5

Most tools have clearly distinct roles (search vs. get-by-id vs. list vs. set-focus), but 'remember' is a read operation with a write-like name, causing potential confusion with 'recall'. 'presence' and 'ranking_compare' are also opaque from their names alone, though descriptions help.

Naming Consistency2/5

Names mix verbs and nouns arbitrarily (areas, wake, ranking_compare, focus) with no consistent verb_noun pattern. 'remember' misleadingly implies writing, and 'ranking_compare' inverts the typical verb-last order, making the set feel inconsistent.

Tool Count4/5

Seven tools is a reasonable size for a memory/knowledge server Bobby—not too thin, not bloated. However, 'presence' and 'ranking_compare' are somewhat peripheral to the core memory workflow, which keeps this from being a perfectly scoped set.

Completeness2/5

The major gap is that there is no write/store tool: 'focus' sets where new memories would be stored, but commit/note/handoff operations are mentioned yet absent from the tool surface. Agents also cannot create or manage knowledge areas, leaving the memory lifecycle seriously incomplete.

Available Tools

7 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 thingsAInspect

Recall this Lady Whiskerdown's knowledge by semantic search. Use before answering any user question about this Lady Whiskerdown, the customer/product, project facts, onboarding, architecture, policies, product decisions, or imported documents. Returns the most relevant memories you have access to, scoped to your knowledge area.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax results (default 10)
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.

TDQS

A3.6/5.0
Behavior3/5

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

Annotations carry only a title (no readOnlyHint or destructiveHint), so the description must bear the behavioral burden. It discloses scoping ('scoped to your knowledge area') and the return nature ('Returns the most relevant memories you have access to'), which implies a read-only operation. However, it doesn't disclose failure behavior, result limits, authentication needs, or the relationship of kit_session_id to the wake flow. Adequate but not rich for a tool with minimal annotation support.

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?

Three sentences each do distinct work: purpose, usage trigger list, and return behavior. The purpose is front-loaded in the first clause. The middle sentence is long but necessary for conveying the query scope. No filler or redundant restatement of the name or title. Reasonably tight for the information it carries.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must convey return behavior, which it does ('Returns the most relevant memories you have access to'). All parameters are documented in the schema. For a simple retrieval tool this is mostly sufficient, but it omits details like result ordering, pagination, or the count/limit semantics that an agent might want before invoking. Functional but with visible gaps.

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 (query, limit, kit_session_id) with their own descriptions. The baseline of 3 applies. The tool description adds no parameter-specific detail beyond what the schema provides, notably not clarifying the kit_session_id reuse semantics that the schema does mention. No additional value, but no harm either.

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 opens with a specific verb+resource: 'Recall this Lady Whiskerdown's knowledge by semantic search.' It clearly states the operation (semantic retrieval) and the target resource (memories/knowledge scoped to the agent's area). It distinguishes itself from the write sibling `remember` by framing itself as a retrieval tool, though it doesn't explicitly name that sibling. Clear and unambiguous.

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?

The description gives explicit when-to-use guidance: 'Use before answering any user question about this Lady Whiskerdown, the customer/product, project facts, onboarding, architecture, policies, product decisions, or imported documents.' This is a strong list of triggering contexts. It stops short of naming alternatives or explicit when-not-to-use conditions relative to siblings like `wake` and `areas`, so it doesn't reach 5.

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

rememberReading a memoryAInspect

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)
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.1/5.0
Behavior4/5

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

Annotations provide only a title, so the description carries the behavioral burden. It discloses that this is a read-only retrieval, that the response is the raw memory rather than an enriched graph result, and that the result is key-scoped—valuable beyond the schema. It could add auth or error behavior, but for a simple fetch these are minor gaps.

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?

Two sentences convey purpose and behavioral caveat with little waste. The first sentence is front-loaded with the verb and resource; the second adds the disambiguating 'no enrichment' detail. Slight jargon like 'receiver endpoint' and 'scoped to this key' keeps it from being a flawless 5.

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 low-complexity single-id getter with one required parameter and no output schema, the description gives enough context: what it returns, how it is scoped, and how to obtain a valid id. It does not describe return shape or error cases, but those are not substantial omissions for this tool.

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 coverage is 100%, and both parameters already have detailed descriptions, including the m#N id format and kit_session_id constraints. The description reinforces id-based lookup but adds no parameter details beyond the schema, so 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?

Description opens with a specific verb and object: 'Read a single Lady Whiskerdown memory by id,' and immediately disambiguates from recall by noting ids come from recall and that no graph/entity enrichment occurs. This clearly identifies the operation and differentiates it from sibling tools.

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?

The phrase 'as returned by recall' gives a clear precondition and implies that recall is the tool for producing candidate ids, making the choice between remember and recall reasonably explicit. It stops short of stating a when-not-to-use rule or naming alternatives directly, but the context is sufficient for a simple getter.

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

Meet Lady Whiskerdown. Call this FIRST in every new chat (VS Code/Copilot, Cursor, Claude Code, Codex), before the first substantive answer. It returns who this Lady Whiskerdown is (you_are), which knowledge areas this key can see, which tools it may use, and the working contract. The identity in you_are is offered, not imposed: adopt it for the session only if your operator chose that; otherwise answer as yourself, reading Lady Whiskerdown's archive. For anything this Lady Whiskerdown/customer/project/product 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.1/5.0
Behavior4/5

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

The annotations contain only a title, so the description carries the burden. It discloses non-obvious behavior: the `you_are` identity is offered, not imposed, and the agent may answer as itself while reading Lady Whiskerdown's archive. It does not explicitly state read-only/side-effect status, but the 'returns/reading archive' language implies a read-only initialization.

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 front-loaded with the most important instruction, 'Call this FIRST,' followed by what it returns and how to handle identity. It is slightly wordy with client names and flavor text, but every sentence contributes to the agent's decision-making.

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?

Given no output schema and minimal annotations, the description covers when to call, what it returns, identity handling, and the relationship to recall. It does not explain the exact output structure or the `scope` behavior, but the session-ID parameter is documented in the schema and the core context is present.

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 50%, and the description adds no explanation of `scope` or `kit_session_id`. The `kit_session_id` parameter is already well documented in the schema, while `scope` relies on its enum. The description's reference to return fields does not clarify parameter usage, so it stays at baseline.

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 the operation explicitly: call this first in every new chat and it returns Lady Whiskerdown's identity, visible knowledge areas, permitted tools, and the working contract. This is a specific initialization/context-loading purpose, clearly distinct from sibling tools like recall or remember.

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 timing: 'Call this FIRST in every new chat' and 'before the first substantive answer.' It also routes knowledge lookups toward recall instead of general model knowledge. It does not enumerate exclusions or differentiate from every sibling, so it stops short of a 5.

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. 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"
+}
  2. 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
  3. 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'."
  4. 4 tool updates
    • Addedcapture
    • Addedcommit
    • Addedhandoff
    • Addednote
  5. 4 tool updates
    • Removedcapture
    • Removedcommit
    • Removedhandoff
    • Removednote
  6. 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"
+]
  7. 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.
    51 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.
    36
    -
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources