Ultra-fast (<2ms) persistent memory workspace with strict tenant isolation, cryptographic provenance, and cross-session synchronization for AI agents in Claude, Cursor, and custom agent fleets.
Scored across 8 tools
The memory tools (remember, forget, search, validate_memory) each have a clearly distinct purpose. The only soft overlap is gateway_call versus the github_readonly.* tools, since gateway_call can route to GitHub integrations, potentially confusing an agent about which path to use for a GitHub action.
Two conventions coexist: bare verb names (forget, remember, search, validate_memory) and dotted namespace names (github_readonly.get_file_contents, github_readonly.get_me, github_readonly.pull_request_read). The namespacing is a defensible integration pattern and remains readable, but it is a mixed scheme rather than a uniform verb_noun pattern.
Eight tools is well-scoped for a memory-plus-integration server, with each tool earning its place across memory lifecycle and GitHub read access rather than redundant variants.
Memory coverage is strong (save, search, soft-delete, validate), and GitHub reads are covered, but there is no memory update/edit operation and no way to list or discover available integrations before calling gateway_call, which an agent may need.
Soft-delete a memory by memory_id or cascade-delete all memories from a source_id, cleaning up graph edges.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | No | Specific unique memory ID to soft-delete | |
| source_id | No | Source ID to cascade-delete all associated memories from | |
| workspace | No | Workspace containing the target memory | default |
| Name | Required | Description |
|---|---|---|
| at | Yes | ISO 8601 deletion timestamp |
| id | No | Forgotten memory ID if deleted by ID |
| forgotten | No | True if the memory was found and deleted |
| source_id | No | Forgotten source ID if cascade deleted by source |
| tenant_id | No | Tenant identifier |
| workspace | Yes | Workspace name |
| api_version | No | API version of the memory server |
| forgotten_count | No | Number of cascade-deleted memories |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and idempotentHint=false, so the safety profile is partly covered. The description adds genuinely non-structured context beyond that: deletion is 'soft', the source_id path cascades to ALL associated memories, and it 'cleans up graph edges' -- a side effect not visible in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the destructive action and its side effect front-loaded. Zero filler and every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, and annotations carry the safety profile; the description covers both deletion modes and the edge-cleanup side effect. Minor gap: no mention of whether a soft-delete is recoverable/undoable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 memory_id, source_id, and workspace. The description reinforces the memory_id/source_id duality but adds no syntax or constraint detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verbs (soft-delete, cascade-delete) on a specific resource (memory) and names both operating modes keyed to memory_id vs source_id. An agent immediately knows this is destructive removal, distinct from remember/search/validate_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The two modes ('by memory_id' vs 'from a source_id') imply when each parameter applies, giving some routing guidance. However, it never states when to prefer this over siblings like validate_memory, nor any prerequisites or exclusions, leaving usage largely inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call a tool on an external integration the user has connected to their workspace (for example GitHub or Jira). Only integrations explicitly enabled by the user in their MMW workspace are accessible. The user's credentials are never shared with the AI model.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Name of the specific action to perform on the integration (e.g. 'get_file_contents'). | |
| server | Yes | Name of the integration to call (e.g. 'github_readonly'). Must be an integration the user has enabled. | |
| arguments | Yes | Parameters to pass to the integration action. | |
| project_id | No | Optional project ID to scope this call. Defaults to the user's default project. |
| Name | Required | Description |
|---|---|---|
| result | No | Downstream tool execution result payload |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare openWorldHint=true, readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is partly covered. The description usefully adds that only explicitly enabled integrations are reachable and that credentials are never exposed to the model. It omits, however, that the real effect depends entirely on the target tool, and gives no hint about auth failures or rate limits on external services.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action and followed by the two real constraints. No filler or repetition of the title/annotations, though nothing is used to route the agent toward the right integration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because an output schema exists, return values need not be explained, and the schema documents all four parameters. What is missing for a generic proxy with nested arguments is any mention of how the agent discovers available servers/tools or how this relates to the concrete sibling integration tools, leaving an important operational gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so server, tool, arguments and project_id are already documented in the schema, which sets the baseline at 3. The description reinforces the 'must be enabled' constraint on server but adds no format or naming detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: call a tool on an external integration, with GitHub/Jira as concrete examples. However, it does not distinguish itself from the concrete sibling tools (github_readonly.get_file_contents, github_readonly.get_me), leaving it ambiguous whether an agent should route through the gateway or call the direct tool when both appear available.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contains no when-to-use or when-not-to-use guidance and never names an alternative. The statement that only user-enabled integrations are accessible is a constraint, not routing advice, so the agent must infer when the gateway is the right path versus a direct sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a file, or list a directory, from a GitHub repository at a branch, tag or commit.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git commit SHA, branch name, or tag (defaults to repository default branch). | |
| sha | No | Accepts optional commit SHA. If specified, it will be used instead of ref | |
| path | No | Relative path to file or directory in the repository (e.g. 'src/main.py'). | / |
| repo | Yes | Target repository name. | |
| owner | Yes | Repository owner or organization name. | |
| fields | No | Subset of fields to return for each entry when the path is a directory. If omitted, all fields are returned. Ignored when the path is a single file. Use this to reduce response size when listing directories and you only need specific fields, e.g. just 'name' and 'type'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered by structured data. The description adds only the branch/tag/commit framing, and omits genuinely useful behavioral context such as authentication needs, rate limits, and how file content is returned (e.g. encoding or size limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the dual file/directory behavior is stated up front. It is efficient, though the terseness leaves no room for the routing or behavior context an agent would benefit from.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter tool with no output schema, the description is thin: it does not explain that files come back encoded, that directories return entry objects controlled by the fields parameter, or any size/error caveats. Annotations and the 100% schema coverage carry the rest, making this adequate but with real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters are already documented, including the ref/sha precedence and the fields filter for directory listings. The description adds no syntax, format, or precedence detail beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb pair (read/list) and resource (file or directory in a GitHub repository), with the ref dimension (branch, tag or commit) named explicitly. It is clearly distinguishable from siblings like get_me or pull_request_read by resource, though it never names those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the agent can infer this is the tool for fetching repository content. There is no explicit when-to-use guidance, no mention of when this is preferable to pull_request_read, and no note on choosing between ref and sha or on path semantics ('/' vs a file).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the GitHub account, granted scopes and rate limits of the connected GitHub integration.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds genuine context beyond that: it discloses the return content (account, granted scopes, rate limits) and the fact that it reports on the already-connected integration, implying no arguments or setup are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, and the most decision-relevant element (which account/integration) is front-loaded. Nothing in the sentence is redundant with the title or name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries some burden to sketch the return, and it names the three categories of data returned. It does not describe the response shape or format in detail, but for a trivial zero-parameter read that omission is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate. Per the baseline for zero-parameter tools, a 4 is appropriate; the description correctly signals that no input is needed by scoping the operation to "the connected GitHub integration".
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("Show") and three concrete resources (GitHub account, granted scopes, rate limits) tied to the connected integration. This is clearly distinguishable from siblings like get_file_contents and pull_request_read, which operate on repository content rather than integration identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: an agent can infer this is a diagnostic/identity check to run when it needs to know which account is connected or what scopes are available. There is no explicit when-to-use guidance, no exclusions, and no named alternatives among the siblings (e.g., gateway_call or search).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read information from a GitHub pull request that the user has access to, such as its description, changed files, review comments, or status. Requires a GitHub integration connected by the user.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for paginated results (default: 1). | |
| repo | Yes | Repository name to query. | |
| after | No | Cursor for pagination, used only by the get_review_comments method. Pass the endCursor from the previous page's PageInfo to fetch the next page. | |
| owner | Yes | Repository owner (organization or GitHub username). | |
| method | Yes | Retrieval mode: 'get' (metadata), 'commits', 'files', 'reviews', 'comments', 'diff', 'status', 'check_runs'. | |
| perPage | No | Results per page for pagination (min 1, max 100) | |
| pullNumber | Yes | Pull request number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds genuine context beyond that: the operation is scoped to pull requests 'the user has access to' and requires a connected GitHub integration, which tells the agent about auth prerequisites and permission scoping.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences: the capability and its scope come first, the prerequisite second. No filler, no restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A 7-parameter tool with a 9-value enum mode selector and no output schema needs more than this. The description never explains the relationship between the 'method' values and the returned content, nor mentions pagination handling, so an agent must fall back entirely on the schema to choose a mode.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (including the method enum with its retrieval modes and the pagination cursors) is already documented in the schema. The description's list of retrievable content loosely echoes a few method values but adds no syntax, defaults, or constraints beyond what the schema provides — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (read) and resource (GitHub pull request) and enumerates the kinds of content available (description, changed files, review comments, status). It is clearly distinguishable from its actual siblings (get_file_contents, get_me, search), though it does not name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a prerequisite ('Requires a GitHub integration connected by the user'), which is real usage guidance, but offers no when-to-use/when-not guidance and no hint about which of the nine 'method' modes to pick. With 'method' being the primary routing parameter, the absence of mode selection advice is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a note, fact, or decision to the user's personal memory store so it can be recalled in future conversations. Saving never deletes or overwrites existing memories. When saving a summary of existing memories, pass their IDs in derived_from so their unresolved conflicts stay visible.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Access level for this memory: 'shared' (default) or 'private'. | shared |
| source | No | Who is saving this memory (default: 'owner'). | owner |
| content | Yes | Text content of the memory or fact to store | |
| fact_key | No | Optional topic key. Saving again with the same key adds a newer version; earlier versions are kept and marked, nothing is deleted. | |
| source_id | No | Optional label linking this memory to a source document or file. | |
| workspace | No | Named collection to organise memories (default: 'default'). Use to group related memories together. | default |
| confidence | No | Confidence score between 0.0 and 1.0 | |
| source_hash | No | Optional hash of the source content, used to detect when the source has changed. | |
| derived_from | No | When this memory summarizes or condenses existing memories, their IDs. Unresolved conflicts and staleness of those memories stay visible on the summary. | |
| source_revision | No | Optional version tag of the source document. |
| Name | Required | Description |
|---|---|---|
| id | Yes | Unique identifier of the stored memory |
| scope | Yes | Visibility scope (shared, private, or restricted) |
| status | Yes | Freshness and trust status: unverified, stale or conflict. A new memory is always unverified |
| source_id | No | Identifier of the origin document, file, or session |
| tenant_id | No | Tenant identifier |
| workspace | Yes | Target workspace containing the memory |
| created_at | Yes | ISO 8601 creation timestamp |
| project_id | No | Project identifier |
| api_version | No | API version of the memory server |
| source_hash | No | Cryptographic content hash of the source |
| derived_from | No | IDs of the memories this one summarizes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=false and destructiveHint=false already declared, the description goes further by promising 'Saving never deletes or overwrites existing memories' and explaining that re-saving a fact_key keeps earlier versions marked, not removed. That append-only semantics detail is genuine value beyond the annotations, though idempotency behavior is left unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all front-loaded with the core purpose and behavioral guarantees first, and no filler or repetition. The derived_from sentence is the weakest in added value but still relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be described, and the description covers the store target, the non-destructive guarantee, and the summary-derivation case. Only the scope/source/workspace semantics and idempotency behavior are left entirely to the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 only parameter named in the description is derived_from, and the explanation ('their unresolved conflicts stay visible') largely restates what the schema property already documents, so it adds little beyond the structured field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Save a note, fact, or decision to the user's personal memory store,' and adds the goal ('so it can be recalled in future conversations'). This distinguishes it well from forget and search, though it does not name those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied — the intent (persist something for later recall) is clear, but there is no explicit when-to-use vs forget/search/validate_memory guidance. The one conditional rule given ('When saving a summary of existing memories, pass their IDs in derived_from') is about a parameter, not about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search memories and annotate provenance, stale and conflict status. Each result is a saved record with its source and date; when one is superseded, the newer version is the one in force. Explain decisions only from what the records say: if no record gives the reason, say the reason is not recorded instead of guessing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of memory results to return (1-50) | |
| query | Yes | Semantic or keyword query text to search across memories | |
| scope | No | Optional scope filter (e.g. shared, private) | |
| workspace | No | Workspace to search memories within | default |
| exclude_stale | No | Whether to filter out stale memories from results | |
| current_source_hash | No | Optional current source hash to detect stale memories |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Search the user's earlier AI sessions (Claude Code, Codex) that were uploaded to MMW with their consent, on any of their computers. Use it when the user refers to earlier work («как мы решили», «вчера обсуждали», «продолжим с того места») or when you need context that is not in memories. Returns short snippets with date, program and session; it never returns other people's sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of snippets to return (1-20) | |
| query | Yes | Words to look for in past conversations |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Validate one source manifest hash and report stale/conflicting memories.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Optional scope filter | |
| source_id | No | Identifier of the source entity being validated | |
| workspace | No | Workspace to inspect memories within | default |
| current_source_hash | No | Fresh cryptographic hash of the current source content |
| Name | Required | Description |
|---|---|---|
| checked | Yes | Number of memories evaluated |
| source_id | Yes | Source identifier that was validated |
| stale_ids | No | List of memory IDs whose hash differs from current |
| tenant_id | No | Tenant identifier |
| workspace | Yes | Target workspace name |
| api_version | No | API version of the memory server |
| stale_count | Yes | Total count of stale memories |
| conflict_ids | No | List of memory IDs with fact conflicts |
| conflict_count | Yes | Total count of conflicting memories |
| current_source_hash | Yes | Current expected content hash |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that it operates on exactly one source hash and reports stale/conflicting results, but says nothing about failure modes or what a stale/conflicting verdict implies for follow-up actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler: the action, its scope, and its output are stated immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the annotations carry the safety profile. The remaining gap is guidance on when this tool should be chosen over its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented in the schema; baseline is 3. The phrase 'one source manifest hash' hints at a single-source pairing of source_id with current_source_hash but adds no format or pairing detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (validate) and resource (source manifest hash) and states the outcome (report stale/conflicting memories). It does not, however, distinguish this from siblings like search or remember, which an agent could plausibly confuse it with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: validating a source hash after content changes to detect stale memories. There is no explicit when-to-use, when-not-to-use, or named alternative among the siblings (search, remember, forget).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search_historyremember1 field changedOutput schema / properties / status / descriptionPrevious value: -"Trust and verification status (verified, unverified)"New value: +"Freshness and trust status: unverified, stale or conflict. A new memory is always unverified"search1 field changedOutput schema / $defs / SearchItem / properties / superseded_byAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ID of the newer version saved under the same fact_key; when set, prefer that version. Newest versions are ranked first",
+ "title": "Superseded By"
+}remember2 fields changedInput schema / properties / derived_fromAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "When this memory summarizes or condenses existing memories, their IDs. Unresolved conflicts and staleness of those memories stay visible on the summary.",
+ "title": "Derived From"
+}Output schema / properties / derived_fromAdded value: +{
+ "description": "IDs of the memories this one summarizes",
+ "items": {
+ "type": "string"
+ },
+ "title": "Derived From",
+ "type": "array"
+}search2 fields changedOutput schema / $defs / SearchItem / properties / derived_fromAdded value: +{
+ "description": "IDs of the memories this one summarizes (lineage)",
+ "items": {
+ "type": "string"
+ },
+ "title": "Derived From",
+ "type": "array"
+}Output schema / $defs / SearchItem / properties / status / descriptionPrevious value: -"Freshness and trust status: verified, unverified, stale, conflict"New value: +"Freshness and trust status: unverified, stale or conflict. A hash supplied by the client does not verify a memory; a summary inherits the conflict or staleness of the memories it was derived from"forget7 fields changedOutput schema / properties / api_version / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / api_version / defaultAdded value: +nullOutput schema / properties / api_version / typeRemoved value: -"string"Output schema / properties / tenant_id / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / tenant_id / defaultAdded value: +nullOutput schema / properties / tenant_id / typeRemoved value: -"string"Output schema / requiredPrevious value: -[
- "api_version",
- "tenant_id",
- "workspace",
- "at"
-]New value: +[
+ "workspace",
+ "at"
+]remember7 fields changedOutput schema / properties / api_version / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / api_version / defaultAdded value: +nullOutput schema / properties / api_version / typeRemoved value: -"string"Output schema / properties / tenant_id / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / tenant_id / defaultAdded value: +nullOutput schema / properties / tenant_id / typeRemoved value: -"string"Output schema / requiredPrevious value: -[
- "id",
- "api_version",
- "workspace",
- "tenant_id",
- "scope",
- "status",
- "created_at"
-]New value: +[
+ "id",
+ "workspace",
+ "scope",
+ "status",
+ "created_at"
+]validate_memory7 fields changedOutput schema / properties / api_version / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / api_version / defaultAdded value: +nullOutput schema / properties / api_version / typeRemoved value: -"string"Output schema / properties / tenant_id / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / tenant_id / defaultAdded value: +nullOutput schema / properties / tenant_id / typeRemoved value: -"string"Output schema / requiredPrevious value: -[
- "api_version",
- "workspace",
- "tenant_id",
- "source_id",
- "current_source_hash",
- "checked",
- "stale_count",
- "conflict_count"
-]New value: +[
+ "workspace",
+ "source_id",
+ "current_source_hash",
+ "checked",
+ "stale_count",
+ "conflict_count"
+]remember1 field changedInput schema / properties / fact_key / descriptionPrevious value: -"Optional key to update an existing memory with the same topic instead of creating a duplicate."New value: +"Optional topic key. Saving again with the same key adds a newer version; earlier versions are kept and marked, nothing is deleted."gateway_call4 fields changedInput schema / properties / arguments / descriptionPrevious value: -"Key-value dictionary containing the input parameters expected by the downstream tool. Must conform to that tool's input schema."New value: +"Parameters to pass to the integration action."Input schema / properties / project_id / descriptionPrevious value: -"Optional isolated project context ID. When omitted, automatically resolves to the default project for the authenticated tenant."New value: +"Optional project ID to scope this call. Defaults to the user's default project."Input schema / properties / server / descriptionPrevious value: -"Unique identifier of the downstream MCP service (e.g. 'github_readonly'). Must match an active registered gateway service."New value: +"Name of the integration to call (e.g. 'github_readonly'). Must be an integration the user has enabled."Input schema / properties / tool / descriptionPrevious value: -"Exact name of the tool to execute on the downstream server (e.g. 'pull_request_read' or 'get_file_contents')."New value: +"Name of the specific action to perform on the integration (e.g. 'get_file_contents')."remember7 fields changedInput schema / properties / fact_key / descriptionPrevious value: -"Canonical key to identify updates and detect conflicts on the same fact"New value: +"Optional key to update an existing memory with the same topic instead of creating a duplicate."Input schema / properties / scope / descriptionPrevious value: -"Visibility and access scope (shared, private, or restricted)"New value: +"Access level for this memory: 'shared' (default) or 'private'."Input schema / properties / source / descriptionPrevious value: -"Origin type or author of the memory (e.g. owner, agent, user)"New value: +"Who is saving this memory (default: 'owner')."Input schema / properties / source_hash / descriptionPrevious value: -"Cryptographic hash of the source content for freshness tracking"New value: +"Optional hash of the source content, used to detect when the source has changed."Input schema / properties / source_id / descriptionPrevious value: -"Identifier of the source document, file, or session"New value: +"Optional label linking this memory to a source document or file."Input schema / properties / source_revision / descriptionPrevious value: -"Version or revision tag of the source artifact"New value: +"Optional version tag of the source document."Input schema / properties / workspace / descriptionPrevious value: -"Target workspace partitioning the memories"New value: +"Named collection to organise memories (default: 'default'). Use to group related memories together."search1 field changedOutput schema / $defs / SearchItem / properties / confidence / descriptionPrevious value: -"Confidence score between 0.0 and 1.0"New value: +"How confident the user is in this fact, from 0.0 (uncertain) to 1.0 (certain). Default: 0.5."forgetgateway_callgithub_readonly.get_file_contentsgithub_readonly.get_megithub_readonly.pull_request_readremembersearchvalidate_memory
Add one secure layer between your agents and this server.