Synapse Layer — Trust Infrastructure for AI Agents
Server Details
MCP-native Trust Infrastructure for AI Agents. Persistent encrypted memory with Trust Quotient.
- Status
- Healthy
- Uptime
- 100.0% over 38 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- SynapseLayer/synapse-layer
- GitHub Stars
- 13
- Server Listing
- synapse-layer
TDQS
Scored across 13 tools
Several tools are explicit aliases or near-duplicates: recall_memory is an alias of recall, and save_memory/save_to_synapse/store_memory all appear to perform persistence with overlapping semantics. This creates real ambiguity during tool selection even though other tools like health_check and neural_handover are clearly distinct.
Most tool names use snake_case and are readable, but the pattern is inconsistent: some are verb_noun (list_memories, save_memory), some are bare verbs (recall, search), and some are noun_noun phrases (memory_feedback, slo_report). The presence of aliases with different naming styles (recall vs recall_memory, save_to_synapse vs store_memory) further weakens consistency.
Thirteen tools is within the reasonable range for a memory/trust infrastructure server, but the count is slightly padded by alias tools that do not add functional surface area. The set could be trimmed to roughly ten distinct tools without losing capability.
The core memory lifecycle is well covered: initialization, saving, listing, recalling, searching, feedback, and extraction from text are all present. Minor gaps include no explicit delete/update memory operation and no context teardown, but these are likely workable via other governance controls.
Available Tools
13 toolshealth_checkARead-onlyInspect
Check service availability, engine version, and storage health. Public method.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| version | Yes | |
| dbLatencyMs | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and no destructiveness, so the safety profile is clear. The description adds value by specifying what is checked (availability, engine version, storage health), which is beyond the annotations. It does not contradict 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?
The description is two concise sentences, front-loading the key purpose and ending with a helpful qualifier ('Public method'). Every word earns its place with no redundancy.
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?
Given zero parameters and the presence of an output schema, the description is complete for its simplicity. It covers the key checks performed, though it doesn't elaborate on return values (covered by output schema) or error cases. Adequate given the low complexity.
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 input schema has no parameters, so the description has nothing to add beyond specifying the general purpose. Baseline 3 is appropriate because the schema coverage is 100% and no parameter details are needed.
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 clearly states the tool checks 'service availability, engine version, and storage health'. It uses a specific verb ('check') and resource ('service', 'engine', 'storage'), and the 'Public method' addition distinguishes it from tools that might require authentication or have restricted access.
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 provides clear context that this is a health check tool, but there is no explicit guidance on when to use it versus other tools (e.g., when to use health_check vs. slo_report). However, the context is sufficient for most scenarios given its broad nature and zero parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
initialize_contextARead-onlyInspect
Initialize a persistent memory context for a conversation or agent session. Returns REDACTED metadata by default (detail="summary"). Use detail="full" with a reason (10–200 chars) to retrieve plaintext content under MEMORY_EXPORT_GOVERNANCE_V1.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Detail level. "summary" (default) = redacted metadata only, no plaintext. "full" = plaintext content; REQUIRES the reason parameter and is audit-logged. | |
| reason | No | REQUIRED only when detail="full" (10–200 chars). Audit policy: MEMORY_EXPORT_GOVERNANCE_V1. Human-readable justification for retrieving PLAINTEXT context. Without it, detail="full" WILL fail with code -32602. |
Output Schema
| Name | Required | Description |
|---|---|---|
| scope | Yes | |
| agent_id | No | |
| memories | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, openWorldHint=false), the description adds significant context about the audit-logging behavior of 'full' mode, the requirement for a human-readable justification, and the failure code without it. This provides essential behavioral detail that the annotations alone do not convey, especially regarding governance compliance.
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?
The description is concise, with two sentences that efficiently convey purpose, behavior, and parameter nuances. It is well-structured with a clear front-loading of purpose followed by critical usage details for different detail levels, and every sentence is informative without waste.
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 tool with an output schema (implied by 'returns REDACTED metadata') and comprehensive parameter documentation, the description is largely complete. It explains the two modes, the dependency between parameters, and governance context. However, it could be slightly improved by briefly noting what happens if context is already initialized (e.g., whether it resets or updates) or if there are any side effects, given the 'initialize' verb suggests a starting state.
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 coverage is 100%, and the description reinforces parameter usage by explaining that 'summary' returns redacted metadata while 'full' requires a reason and returns plaintext. It adds value beyond the schema by clarifying that 'reason' is strictly required for 'full' detail and mentioning the audit policy and error code, which aids selection.
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 clearly states the tool initializes a persistent memory context for conversations or agent sessions, using specific verbs and resources. It distinguishes itself from sibling tools like 'list_memories' and 'recall' by focusing on initialization rather than retrieval, and it provides a clear distinction between the 'summary' and 'full' detail levels.
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 explicitly guides when to use each detail level, specifying that 'summary' is the default and 'full' requires a reason parameter under audit policy. However, it doesn't explicitly clarify when NOT to use this tool versus initializing memory via other means or when initialization is unnecessary, such as if context already exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_memoriesBRead-onlyInspect
List memory metadata with pagination and governance limits.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum memory metadata rows to return. Hard-capped: default 5, max 10. Values above 10 are silently reduced to 10. | |
| scope | No | Explicit memory scope. "agent" (default, fail-closed) = lists memories for the given agent_id (or the token agent). "tenant" = lists memories across all agents of the authenticated tenant. | |
| subject | No | ESCOPO1 (optional): opaque 8-128 char token ([A-Za-z0-9._:-]) that isolates memory to a single person within a shared connect-token. Omit for token-scoped behavior. Never include PII/email. | |
| agent_id | No | Agent identifier (canonical or alias). Used only when scope="agent" or scope is inferred. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| total | No | |
| memories | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered without description credit. The description adds 'pagination and governance limits,' which hints at bounded output and scope-based restrictions beyond the annotation. However, the concrete behaviors (hard cap of 10, silent reduction, fail-closed scope default) live in the schema, not the description.
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 seven-word sentence with zero waste. The core action and resource are front-loaded, followed by the two governing concepts (pagination, governance limits). Every word earns its place.
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?
The presence of an output schema means return values need no description, and the fully detailed schema plus readOnly annotation carry most of the burden. The notable gap is routing: with 12 memory-flavored siblings, the description doesn't help an agent decide when listing metadata is the right operation versus retrieving content via recall or search.
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 even with no param info in the description. The terms 'pagination' and 'governance limits' loosely map to the limit and scope parameters but add little meaning beyond what the schema already states in greater detail (hard caps, silent reduction, fail-closed behavior, PII warning).
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 pairs a specific verb (List) with a specific resource (memory metadata), and the 'metadata' qualifier implies enumeration of records rather than content retrieval, which loosely distinguishes it from content-returning siblings like recall and search. However, it doesn't explicitly differentiate from the several memory-related siblings (recall_memory, search, store_memory), leaving some inference required.
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 provides no guidance on when to use this tool versus alternatives. With 12 siblings — including recall, recall_memory, search, save_memory, and store_memory — there is real routing risk and nothing in the description mitigates it. The schema's scope parameter details are functional semantics, not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_feedbackAInspect
Submit feedback to adjust trust scoring for stored memories.
| Name | Required | Description | Default |
|---|---|---|---|
| signal | Yes | Feedback signal: used (auto), helpful (positive), irrelevant (negative), ignored. | |
| memoryId | No | Deprecated camelCase alias of memory_id — still accepted for backward compatibility. | |
| memory_id | No | ID of the memory to provide feedback on (canonical snake_case name). | |
| sessionId | No | Deprecated camelCase alias of session_id — still accepted for backward compatibility. | |
| session_id | No | Optional session identifier for tracking (canonical snake_case name). |
Output Schema
| Name | Required | Description |
|---|---|---|
| signal | No | |
| success | Yes | |
| memoryId | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating operation (readOnlyHint=false). The description adds that the mutation affects trust scoring rather than memory content, which is useful context beyond the schema. It discloses the core side effect honestly and does not contradict the 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?
The description is a single, front-loaded sentence with no filler. It earns its place, stating the action and its effect. There is no structural improvement needed.
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?
The schema is rich with aliases and enums, but the description leaves gaps: it does not explain why memory_id is optional despite referring to 'stored memories,' nor the distinction between session_id and memory_id contexts. The presence of an output schema and full parameter docs reduces the severity, but the ambiguous optionality is a meaningful 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?
All five parameters are fully documented in the schema, so the description carries no additional parameter information. The baseline for 100% schema coverage is 3. No enhancement or clarification of parameter meaning is attempted in the description.
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 clear verb ('Submit') and resource ('stored memories') with a concrete outcome ('adjust trust scoring'). It is not a tautology and is distinct from sibling memory operations. However, it does not explicitly name or contrast with sibling tools, so it earns a 4 rather than a 5.
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 implies this tool is for providing feedback after memory use or storage, but it does not state when to choose it over alternatives like save_memory or recall. No exclusions or prerequisites are given. The usage context must be inferred from the tool name and sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
neural_handoverAInspect
Transfer contextual state between agents with continuity controls.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The handover token (64 hex chars). Generated by the source agent/user in Forge UI. | |
| reason | Yes | REQUIRED (10–200 chars). Human-readable justification for consuming this handover. Example: "Receiving project context from Claude session." | |
| consuming_agent | No | Agent identifier consuming the handover (defaults to token agent). |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| handoverId | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, openWorldHint=false), so the description carries the behavioral burden. It signals mutation ('transfer') and 'continuity controls' but does not detail side effects (e.g., token invalidation, auth requirements beyond the token parameter, idempotency). The parameter descriptions in the schema add some transparency (token generation source, reason constraints), which prevents a lower score.
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?
The description is a single, front-loaded sentence with no wasted words. Every term ('Transfer', 'contextual state', 'between agents', 'continuity controls') contributes to conveying the core function. Appropriate for a tool with a clear, narrow purpose.
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?
Given the tool has 3 parameters, an output schema, and sibling tools, the description is minimally adequate. It explains the primary action but omits context like prerequisites (e.g., need an existing handover token) or what 'continuity controls' entail. Not incomplete enough for a 2, but leaves key behavioral questions unanswered.
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% with each parameter already well-documented (token as 64 hex chars from Forge UI, reason with length and example, consuming_agent with default). The tool description adds no additional meaning beyond the schema; thus the baseline score of 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 'Transfer contextual state between agents with continuity controls' uses a specific verb ('transfer') and resource ('contextual state') and clearly distinguishes this tool from sibling tools (health_check, memory operations, etc.) by focusing on cross-agent state transfer. No tautology or vagueness.
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 provides no guidance on when to use this tool vs. alternatives. Sibling tools include many memory-related operations (save_to_synapse, list_memories, recall, etc.), but no explicit context, exclusions, or alternative recommendations are given. The agent is left to infer usage without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
process_textAInspect
Extract candidate memories from free-form text with governance filters and sanitization.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Free-form text to scan for auto-save triggers. | |
| source | No | Source identifier (default: mcp). | |
| project | No | Force a specific project (e.g., SYNAPSE_LAYER, OFFLY). Auto-detected if omitted. | |
| agent_id | No | Agent identifier. Defaults to "default". |
Output Schema
| Name | Required | Description |
|---|---|---|
| extracted | Yes | |
| storedCount | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions governance filters and sanitization, which adds context beyond the annotations (readOnlyHint=false, openWorldHint=false). The description does not contradict annotations. However, it does not detail what the governance filters do, how sanitization works, or what side effects occur (e.g., does it actually save anything or just extract?). The return value details are covered by the output schema.
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?
The description is a single clear sentence that conveys the core purpose and key features. It could potentially mention the output schema or provide a brief example, but it's well-structured and front-loaded.
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?
Given the output schema exists (covering return values), the description appropriately addresses the tool's operation. The four parameters are well-documented in the schema. The description could mention that the tool has auto-detection of projects, but that's covered in the schema description. Overall, quite complete for this complexity.
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 input schema has 100% coverage, describing each parameter. The description adds value by contextualizing the 'text' parameter as being scanned for 'auto-save triggers', and 'project' as having auto-detection with specific examples (SYNAPSE_LAYER, OFFLY). Baseline 3 is appropriate since the schema already covers details.
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 uses a specific verb-resource pair ('Extract candidate memories') and mentions governance filters and sanitization, which distinguishes it from sibling tools like save_memory or store_memory. However, it could more explicitly differentiate itself from search or recall tools that also deal with text.
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 implies the tool is for processing free-form text in an auto-save context, but provides no explicit guidance on when to use this vs. related tools like save_memory or store_memory. No alternatives or when-not-to-use instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallARead-onlyInspect
Retrieve relevant persisted memory using semantic, temporal, priority, or hybrid routing. Governance: requires reason (10–200 chars). Rate limit: 20/min.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Recall routing mode. "temporal" = pure chronological, "semantic" = FTS + TQ ranking, "priority" = critical/high-TQ first, "hybrid" = weighted blend, "auto" = detect from query (default). | |
| limit | No | Maximum memories to return (1–50, default: 10). | |
| query | Yes | What to recall — natural language query for memory retrieval. | |
| scope | No | Explicit memory scope. "agent" (default, fail-closed) = limits recall to the given agent_id (or the token agent). "tenant" = cross-agent recall within the authenticated tenant. If omitted with agent_id present, "agent" is inferred; if both omitted, the token agent is used (verified-token scope). | |
| reason | Yes | REQUIRED (10–200 chars). Audit policy: MEMORY_EXPORT_GOVERNANCE_V1. Human-readable justification for retrieving PLAINTEXT memory. Without this parameter the call WILL fail with code -32602. Example: "User asked me to summarize last week decisions." | |
| subject | No | ESCOPO1 (optional): opaque 8-128 char token ([A-Za-z0-9._:-]) that isolates memory to a single person within a shared connect-token. Omit for token-scoped behavior. Never include PII/email. | |
| agent_id | No | Agent identifier (canonical or alias). Used only when scope="agent" or scope is inferred. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| scope | Yes | |
| memories | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds valuable behavioral context beyond this: the mandatory 'reason' parameter with character range, the governance/audit policy implication, and the 20/min rate limit. This is meaningful additional disclosure of operational constraints.
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 concise sentences with no filler. The core action is front-loaded, followed immediately by the critical governance constraint and rate limit. Every phrase earns its place and the structure is easily scannable.
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 and 100% schema coverage, the return format and parameter semantics are already documented. However, the description lacks context about the fail-closed scope behavior and, more importantly, does not disambiguate from the 'recall_memory' sibling, leaving a notable completeness gap for an AI agent selecting between tools.
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%, and the schema already provides rich semantics for each parameter, including enums and examples. The description's mention of 'reason (10–200 chars)' reinforces the schema but does not add significant new meaning beyond what the parameter descriptions already state. Baseline 3 is appropriate.
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 ('Retrieve') and resource ('persisted memory') along with routing modes, which clearly identifies the tool's function. However, the sibling tool 'recall_memory' exists with a nearly identical name, and the description does not differentiate this tool from it, so it is not a 5.
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 explains governance and rate limits but gives no guidance on when to use 'recall' versus the closely related 'recall_memory', 'search', or 'list_memories' siblings. There is no mention of conditions, exclusions, or alternative routing, leaving the agent to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recall_memoryARead-onlyInspect
Recall persisted memory by query. Alias of recall.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Recall routing mode. | |
| limit | No | Maximum memories to return (1–50, default: 10). | |
| query | Yes | What to recall — natural language query for memory retrieval. | |
| scope | No | Explicit memory scope. "agent" (default, fail-closed) = limits recall to the given agent_id (or the token agent). "tenant" = cross-agent recall within the authenticated tenant. If omitted with agent_id present, "agent" is inferred; if both omitted, the token agent is used (verified-token scope). | |
| reason | Yes | REQUIRED (10–200 chars). Audit policy: MEMORY_EXPORT_GOVERNANCE_V1. Without this the call WILL fail with code -32602. Example: "Checking user project status." | |
| subject | No | ESCOPO1 (optional): opaque 8-128 char token ([A-Za-z0-9._:-]) that isolates memory to a single person within a shared connect-token. Omit for token-scoped behavior. Never include PII/email. | |
| agent_id | No | Agent identifier (canonical or alias). Used only when scope="agent" or scope is inferred. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| scope | Yes | |
| memories | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safe read-only nature. The description adds only the alias relationship, which is minor behavioral context. It does not mention fail-closed scoping or the required audit reason, though those are documented in the parameter schema rather than the description.
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?
The description is extremely concise: two short sentences, each adding some value. The core purpose is front-loaded, and the alias note is a useful routing hint without unnecessary elaboration.
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?
Given the rich input schema, annotations, and presence of an output schema, the minimal description is mostly sufficient. The alias identification helps avoid confusion with the recall sibling. It could add a sentence on when to prefer this over search, but that gap is minor given the structured metadata already present.
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%, and parameter descriptions are already detailed, including enums, defaults, scope behavior, and failure conditions. The description itself adds no parameter information, but with complete schema coverage the baseline of 3 is appropriate.
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 the action clearly: 'Recall persisted memory by query,' identifying the resource (persisted memory) and the operation. The 'Alias of recall' note further clarifies that it is equivalent to the recall sibling. It does not explicitly distinguish itself from search or list_memories, but the core purpose is unambiguous.
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?
'Recall persisted memory by query' implies the tool is for natural-language memory retrieval, which gives the agent a basic sense of when to use it. The alias note signals interchangeability with recall, but there is no explicit guidance on when to choose this over search or list_memories, and no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_memoryBIdempotentInspect
Save a memory entry to the persistent store. Alias of save_to_synapse.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Tags for categorization. | |
| content | Yes | The memory content to store securely. | |
| subject | No | ESCOPO1 (optional): opaque 8-128 char token ([A-Za-z0-9._:-]) that isolates memory to a single person within a shared connect-token. Omit for token-scoped behavior. Never include PII/email. | |
| agent_id | No | Agent identifier for memory isolation. | |
| force_intent | No | MANUAL OVERRIDE ONLY — use apenas quando você (humano) quer forçar explicitamente a classificação de intenção. Valores reconhecidos: preference | fact | procedural | bio | critical | operational | strategic | compliance | security | system_directive | clinical | general | ephemeral. Se não tiver certeza, NÃO preencha este campo — o sistema classifica automaticamente. Valores não reconhecidos são ignorados silenciosamente e retornados em warnings. | |
| intent_reason | No | Auditable reason for forcing intent classification. Max 500 characters. Ignored if force_intent is absent. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| scope | Yes | |
| stored | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and idempotentHint=true, so the safety profile is covered. The description adds that the save goes to a 'persistent store', which is mildly useful, but it does not disclose other behaviors like whether existing memories are overwritten, how duplicates are handled, or any security implications.
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?
The description is two short sentences with no filler. The main action is front-loaded, and the alias note is useful for routing agents to the equivalent save_to_synapse tool.
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?
The schema and output schema are rich, so the agent has enough to call the tool. However, the description omits guidance on when this tool is preferable to the very similar sibling store_memory, and the alias note is the only contextual link to the broader toolset.
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 fully documents all six parameters, including the nuanced force_intent and subject fields. The description itself adds no parameter-level detail, so the baseline score of 3 is appropriate.
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 clearly states the tool's action ('Save a memory entry') and destination ('persistent store'), so an agent can tell it saves memory. It also names save_to_synapse as an alias, but it does not distinguish save_memory from the sibling store_memory, so sibling differentiation is incomplete.
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 only usage-related information is 'Alias of save_to_synapse', which tells the agent these two tools are equivalent but gives no guidance on when to prefer this tool over store_memory or other memory tools. No exclusions, conditions, or alternative-selection criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_to_synapseBIdempotentInspect
Persist memory with encryption at rest, sanitization, and deduplication controls.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Tags for categorization. | |
| type | No | Event type: [MILESTONE], [DECISION], [ALERT], [AUTO-STRAT], [AUTO-OP], [AUTO-INSIGHT], [AUTO-DECISION], [AUTO-CONTEXT], [MANUAL]. | |
| content | Yes | The memory content to store securely. | |
| project | No | Project identifier (e.g., SYNAPSE_LAYER). | |
| subject | No | ESCOPO1 (optional): opaque 8-128 char token ([A-Za-z0-9._:-]) that isolates memory to a single person within a shared connect-token. Omit for token-scoped behavior. Never include PII/email. | |
| agent_id | No | Agent identifier for memory isolation. Defaults to "default". | |
| importance | No | Accepted for compatibility; not enforced by the API. | |
| force_intent | No | MANUAL OVERRIDE ONLY — use apenas quando você (humano) quer forçar explicitamente a classificação de intenção. Valores reconhecidos: preference | fact | procedural | bio | critical | operational | strategic | compliance | security | system_directive | clinical | general | ephemeral. Se não tiver certeza, NÃO preencha este campo — o sistema classifica automaticamente. Valores não reconhecidos são ignorados silenciosamente e retornados em warnings. | |
| intent_reason | No | Auditable reason for forcing intent classification. Max 500 characters. Ignored if force_intent is absent. |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| memory_id | Yes | |
| trust_quotient | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (mutation) and idempotentHint=true (safe to call multiple times). The description adds 'encryption at rest, sanitization, and deduplication controls' which are behavioral traits not in annotations. However, it does not disclose that force_intent and intent_reason are used for manual override and ignored otherwise, which is only in the parameter descriptions. No contradiction found.
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?
The description is a single sentence, succinct and front-loaded with the core purpose. It includes secondary features without verbosity. It is concise, but could be slightly more structured to list the controls, though it is acceptable.
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?
Given the tool's complexity (9 params, manual override logic, multiple intent types) and the high schema coverage, the description does not fully explain when to use force_intent or the implications of the 'subject' field for isolation. The annotations cover idempotency and mutation, but the description lacks guidance on error handling or warnings. An output schema exists but no return format is mentioned, so it is partially complete.
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 each parameter. The description adds some context about encryption and controls but does not explain parameter syntax beyond that. The subject parameter has detailed semantics in the schema, and the description does not add more. Baseline 3 is appropriate.
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 the verb 'persist' and the resource 'memory' with secondary controls (encryption, sanitization, deduplication). It does not differentiate from siblings like save_memory/store_mory, but it is clear enough. A higher score would require mentioning that this is the primary persistence tool while siblings are aliases or variations.
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?
No explicit guidance on when to use this tool versus save_memory, store_memory, or other siblings. The description implies general use for persisting memory but does not mention exclusions, such as when to use recall or process_text. It also lacks context about the manual override scenario, which is only partially addressed in the parameter description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchARead-onlyInspect
Search persisted memory across agent scopes using full-text matching. Governance: requires reason (10–200 chars) because results contain plaintext content.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return (1–50, default: 20). | |
| query | Yes | Search query — natural language or keywords. | |
| scope | No | Explicit search scope. "agent" (default, fail-closed) = limits search to the given agent_id (or the token agent). "tenant" = cross-agent search within the authenticated tenant. If omitted with agent_id present, "agent" is inferred; if both omitted, the token agent is used (verified-token scope). | |
| reason | Yes | REQUIRED (10–200 chars). Audit policy: MEMORY_EXPORT_GOVERNANCE_V1. Human-readable justification for retrieving PLAINTEXT memory. Without this parameter the call WILL fail with code -32602. Example: "Checking prior migration decisions for the user." | |
| subject | No | ESCOPO1 (optional): opaque 8-128 char token ([A-Za-z0-9._:-]) that isolates memory to a single person within a shared connect-token. Omit for token-scoped behavior. Never include PII/email. | |
| agent_id | No | Agent identifier (canonical or alias). Used only when scope="agent" or scope is inferred. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| scope | Yes | |
| results | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that results contain plaintext content and are governed by a reason requirement, adding meaningful behavior beyond the readOnlyHint annotation. It also signals that search operates across agent scopes, which is relevant behavioral context.
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 tight sentences with no filler: the first states the core action and method, and the second front-loads the critical governance constraint. Every element earns its place.
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?
Given the rich schema, output schema, and readOnlyHint annotation, the description covers what an agent needs to call the tool safely. The only meaningful gap is guidance on when to use search versus sibling memory tools, but the rest of the context is well supplied.
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 all parameters thoroughly. The description adds no parameter-level detail beyond restating the reason requirement, so it meets the baseline but does not go further.
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 clear verb-resource pair ('Search persisted memory') and adds method detail ('full-text matching') and scope ('across agent scopes'). It is distinguishable in function, though it does not explicitly differentiate itself from siblings like recall or list_memories.
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 gives clear governance context for when the reason parameter is required, which is useful operational guidance. However, it does not state when to choose this tool over sibling recollection tools, leaving usage selection implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
slo_reportBRead-onlyInspect
Return uptime and SLO metrics for the MCP service.
| Name | Required | Description | Default |
|---|---|---|---|
| admin_token | Yes | Admin authentication token. Must match ADMIN_TOKEN environment variable. | |
| window_hours | No | Time windows in hours for the report. Default: [24, 168] (24h + 7d). |
Output Schema
| Name | Required | Description |
|---|---|---|
| p50 | No | |
| p95 | No | |
| uptime | Yes | |
| window | No | |
| errorRate | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds no further behavioral disclosure. It does not mention auth requirements beyond the schema, rate limits, or potential side effects. The description is purely a restatement of the tool's purpose.
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?
The description is a single sentence with no filler words. It is appropriately concise for a simple tool, though it could be slightly more informative without sacrificing conciseness.
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?
Despite having an output schema and simple parameters, the description omits important context such as the requirement for admin authentication, the default time windows, and the relationship to health_check. The agent is left with insufficient guidance for correct invocation beyond the schema.
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 description adds no parameter information beyond what the schema already provides; it does not mention either admin_token or window_hours. The agent must rely entirely on the schema for parameter semantics.
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 clearly states the tool returns 'uptime and SLO metrics for the MCP service,' using a specific verb and resource. It distinguishes itself from sibling tools like health_check, which likely returns a simpler health status, and other tools focused on memory or text processing.
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 provides no guidance on when to use this tool versus alternatives such as health_check, nor does it mention prerequisites (e.g., the need for an admin token) or when not to use it. The agent must infer usage from the parameter schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
store_memoryBIdempotentInspect
Store structured memory with metadata and trust scoring.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Tags for categorization. | |
| content | Yes | The memory content to store securely. | |
| subject | No | ESCOPO1 (optional): opaque 8-128 char token ([A-Za-z0-9._:-]) that isolates memory to a single person within a shared connect-token. Omit for token-scoped behavior. Never include PII/email. | |
| agent_id | No | Agent identifier for memory isolation. Defaults to "default". | |
| force_intent | No | MANUAL OVERRIDE ONLY — use apenas quando você (humano) quer forçar explicitamente a classificação de intenção. Valores reconhecidos: preference | fact | procedural | bio | critical | operational | strategic | compliance | security | system_directive | clinical | general | ephemeral. Se não tiver certeza, NÃO preencha este campo — o sistema classifica automaticamente. Valores não reconhecidos são ignorados silenciosamente e retornados em warnings. | |
| intent_reason | No | Auditable reason for forcing intent classification. Max 500 characters. Ignored if force_intent is absent. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| scope | Yes | |
| stored | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and idempotentHint=true, so the description does not need to restate safety. It adds the context of 'metadata and trust scoring' as behavioral features, but does not disclose how trust scoring works, whether existing memories are overwritten, or what side effects occur beyond storing.
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?
The description is one clean sentence with no filler, and the core action is front-loaded. It is efficient, though it is so terse that some important context is left to the schema and annotations.
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?
The rich input schema and output schema carry much of the burden, but the description alone does not explain trust scoring semantics or how this tool differs from the similarly named 'save_memory'. Given the number of memory-related siblings, the description is minimally adequate but not complete for confident tool selection.
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 all six parameters thoroughly. The description's phrase 'metadata' loosely maps to tags, subject, and agent_id, but it adds no concrete parameter semantics beyond what the schema provides. Baseline 3 is appropriate.
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 ('Store') and a specific resource ('structured memory') with a distinguishing feature ('metadata and trust scoring'). However, it does not differentiate from the sibling 'save_memory', which appears to be a near-synonym, so the agent cannot reliably pick between them from the description alone.
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?
There is no guidance about when to use this tool versus alternatives such as 'save_memory', 'recall_memory', or 'list_memories'. The one-sentence description gives no use-case context, preconditions, or exclusions, leaving tool selection to inference.
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 tool update
- Changed
save_to_synapse1 field changed- changed
Input schema / properties / importance / descriptionPrevious value: -"Importance level 1–5 (default: 3)."New value: +"Accepted for compatibility; not enforced by the API."
7 tool updates
- Changed
list_memories1 field changed- added
Input schema / properties / subjectAdded value: +{ + "description": "ESCOPO1 (optional): opaque 8-128 char token ([A-Za-z0-9._:-]) that isolates memory to a single person within a shared connect-token. Omit for token-scoped behavior. Never include PII/email.", + "type": "string" +}
- Changed
recall1 field changed- added
Input schema / properties / subjectAdded value: +{ + "description": "ESCOPO1 (optional): opaque 8-128 char token ([A-Za-z0-9._:-]) that isolates memory to a single person within a shared connect-token. Omit for token-scoped behavior. Never include PII/email.", + "type": "string" +}
- Changed
recall_memory1 field changed- added
Input schema / properties / subjectAdded value: +{ + "description": "ESCOPO1 (optional): opaque 8-128 char token ([A-Za-z0-9._:-]) that isolates memory to a single person within a shared connect-token. Omit for token-scoped behavior. Never include PII/email.", + "type": "string" +}
- Changed
save_memory1 field changed- added
Input schema / properties / subjectAdded value: +{ + "description": "ESCOPO1 (optional): opaque 8-128 char token ([A-Za-z0-9._:-]) that isolates memory to a single person within a shared connect-token. Omit for token-scoped behavior. Never include PII/email.", + "type": "string" +}
- Changed
save_to_synapse1 field changed- added
Input schema / properties / subjectAdded value: +{ + "description": "ESCOPO1 (optional): opaque 8-128 char token ([A-Za-z0-9._:-]) that isolates memory to a single person within a shared connect-token. Omit for token-scoped behavior. Never include PII/email.", + "type": "string" +}
- Changed
search1 field changed- added
Input schema / properties / subjectAdded value: +{ + "description": "ESCOPO1 (optional): opaque 8-128 char token ([A-Za-z0-9._:-]) that isolates memory to a single person within a shared connect-token. Omit for token-scoped behavior. Never include PII/email.", + "type": "string" +}
- Changed
store_memory1 field changed- added
Input schema / properties / subjectAdded value: +{ + "description": "ESCOPO1 (optional): opaque 8-128 char token ([A-Za-z0-9._:-]) that isolates memory to a single person within a shared connect-token. Omit for token-scoped behavior. Never include PII/email.", + "type": "string" +}
2 tool updates
- Changed
memory_feedback5 fields changed- removed
Output schema / properties / appliedRemoved value: -{ - "type": "boolean" -} - added
Output schema / properties / signalAdded value: +{ + "type": "string" +} - added
Output schema / properties / successAdded value: +{ + "type": "boolean" +} - removed
Output schema / properties / trustRemoved value: -{ - "type": "number" -} - changed
Output schema / requiredPrevious value: -[ - "memoryId", - "applied" -]New value: +[ + "memoryId", + "success" +]
- Changed
save_to_synapse7 fields changed- removed
Output schema / properties / idRemoved value: -{ - "type": "string" -} - added
Output schema / properties / memory_idAdded value: +{ + "type": "string" +} - removed
Output schema / properties / scopeRemoved value: -{ - "enum": [ - "agent", - "tenant" - ], - "type": "string" -} - added
Output schema / properties / statusAdded value: +{ + "type": "string" +} - removed
Output schema / properties / storedRemoved value: -{ - "type": "boolean" -} - added
Output schema / properties / trust_quotientAdded value: +{ + "type": "number" +} - changed
Output schema / requiredPrevious value: -[ - "id", - "stored", - "scope" -]New value: +[ + "memory_id", + "status" +]
3 tool updates
- Changed
save_memory2 fields changed- changed
Input schema / properties / force_intent / descriptionPrevious value: -"Override automatic intent classification. When set, the system skips auto-classification and uses this value directly. Accepted values: preference, fact, procedural, bio, critical, operational, strategic, compliance, security, system_directive, clinical, general, ephemeral."New value: +"MANUAL OVERRIDE ONLY — use apenas quando você (humano) quer forçar explicitamente a classificação de intenção. Valores reconhecidos: preference | fact | procedural | bio | critical | operational | strategic | compliance | security | system_directive | clinical | general | ephemeral. Se não tiver certeza, NÃO preencha este campo — o sistema classifica automaticamente. Valores não reconhecidos são ignorados silenciosamente e retornados em warnings." - removed
Input schema / properties / force_intent / enumRemoved value: -[ - "preference", - "fact", - "procedural", - "bio", - "critical", - "operational", - "strategic", - "compliance", - "security", - "system_directive", - "clinical", - "general", - "ephemeral" -]
- Changed
save_to_synapse2 fields changed- changed
Input schema / properties / force_intent / descriptionPrevious value: -"Override automatic intent classification. When set, the system skips auto-classification and uses this value directly. Accepted values: preference, fact, procedural, bio, critical, operational, strategic, compliance, security, system_directive, clinical, general, ephemeral."New value: +"MANUAL OVERRIDE ONLY — use apenas quando você (humano) quer forçar explicitamente a classificação de intenção. Valores reconhecidos: preference | fact | procedural | bio | critical | operational | strategic | compliance | security | system_directive | clinical | general | ephemeral. Se não tiver certeza, NÃO preencha este campo — o sistema classifica automaticamente. Valores não reconhecidos são ignorados silenciosamente e retornados em warnings." - removed
Input schema / properties / force_intent / enumRemoved value: -[ - "preference", - "fact", - "procedural", - "bio", - "critical", - "operational", - "strategic", - "compliance", - "security", - "system_directive", - "clinical", - "general", - "ephemeral" -]
- Changed
store_memory2 fields changed- changed
Input schema / properties / force_intent / descriptionPrevious value: -"Override automatic intent classification. When set, the system skips auto-classification and uses this value directly. Accepted values: preference, fact, procedural, bio, critical, operational, strategic, compliance, security, system_directive, clinical, general, ephemeral."New value: +"MANUAL OVERRIDE ONLY — use apenas quando você (humano) quer forçar explicitamente a classificação de intenção. Valores reconhecidos: preference | fact | procedural | bio | critical | operational | strategic | compliance | security | system_directive | clinical | general | ephemeral. Se não tiver certeza, NÃO preencha este campo — o sistema classifica automaticamente. Valores não reconhecidos são ignorados silenciosamente e retornados em warnings." - removed
Input schema / properties / force_intent / enumRemoved value: -[ - "preference", - "fact", - "procedural", - "bio", - "critical", - "operational", - "strategic", - "compliance", - "security", - "system_directive", - "clinical", - "general", - "ephemeral" -]
3 tool updates
- Changed
save_memory2 fields changed- added
Input schema / properties / force_intentAdded value: +{ + "description": "Override automatic intent classification. When set, the system skips auto-classification and uses this value directly. Accepted values: preference, fact, procedural, bio, critical, operational, strategic, compliance, security, system_directive, clinical, general, ephemeral.", + "enum": [ + "preference", + "fact", + "procedural", + "bio", + "critical", + "operational", + "strategic", + "compliance", + "security", + "system_directive", + "clinical", + "general", + "ephemeral" + ], + "type": "string" +} - added
Input schema / properties / intent_reasonAdded value: +{ + "description": "Auditable reason for forcing intent classification. Max 500 characters. Ignored if force_intent is absent.", + "maxLength": 500, + "type": "string" +}
- Changed
save_to_synapse2 fields changed- added
Input schema / properties / force_intentAdded value: +{ + "description": "Override automatic intent classification. When set, the system skips auto-classification and uses this value directly. Accepted values: preference, fact, procedural, bio, critical, operational, strategic, compliance, security, system_directive, clinical, general, ephemeral.", + "enum": [ + "preference", + "fact", + "procedural", + "bio", + "critical", + "operational", + "strategic", + "compliance", + "security", + "system_directive", + "clinical", + "general", + "ephemeral" + ], + "type": "string" +} - added
Input schema / properties / intent_reasonAdded value: +{ + "description": "Auditable reason for forcing intent classification. Max 500 characters. Ignored if force_intent is absent.", + "maxLength": 500, + "type": "string" +}
- Changed
store_memory2 fields changed- added
Input schema / properties / force_intentAdded value: +{ + "description": "Override automatic intent classification. When set, the system skips auto-classification and uses this value directly. Accepted values: preference, fact, procedural, bio, critical, operational, strategic, compliance, security, system_directive, clinical, general, ephemeral.", + "enum": [ + "preference", + "fact", + "procedural", + "bio", + "critical", + "operational", + "strategic", + "compliance", + "security", + "system_directive", + "clinical", + "general", + "ephemeral" + ], + "type": "string" +} - added
Input schema / properties / intent_reasonAdded value: +{ + "description": "Auditable reason for forcing intent classification. Max 500 characters. Ignored if force_intent is absent.", + "maxLength": 500, + "type": "string" +}
13 tool updates
- Changed
health_check1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "dbLatencyMs": { + "type": "number" + }, + "status": { + "type": "string" + }, + "version": { + "type": "string" + } + }, + "required": [ + "status", + "version" + ], + "type": "object" +}
- Changed
initialize_context1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "agent_id": { + "type": "string" + }, + "memories": { + "items": { + "type": "object" + }, + "type": "array" + }, + "scope": { + "enum": [ + "agent", + "tenant" + ], + "type": "string" + } + }, + "required": [ + "scope" + ], + "type": "object" +}
- Changed
list_memories1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "count": { + "type": "number" + }, + "memories": { + "items": { + "type": "object" + }, + "type": "array" + }, + "total": { + "type": "number" + } + }, + "required": [ + "memories", + "count" + ], + "type": "object" +}
- Changed
memory_feedback6 fields changed- changed
Input schema / properties / memoryId / descriptionPrevious value: -"ID of the memory to provide feedback on."New value: +"Deprecated camelCase alias of memory_id — still accepted for backward compatibility." - added
Input schema / properties / memory_idAdded value: +{ + "description": "ID of the memory to provide feedback on (canonical snake_case name).", + "type": "string" +} - changed
Input schema / properties / sessionId / descriptionPrevious value: -"Optional session identifier for tracking."New value: +"Deprecated camelCase alias of session_id — still accepted for backward compatibility." - added
Input schema / properties / session_idAdded value: +{ + "description": "Optional session identifier for tracking (canonical snake_case name).", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "memoryId", - "signal" -]New value: +[ + "signal" +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "applied": { + "type": "boolean" + }, + "memoryId": { + "type": "string" + }, + "trust": { + "type": "number" + } + }, + "required": [ + "memoryId", + "applied" + ], + "type": "object" +}
- Changed
neural_handover1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "handoverId": { + "type": "string" + }, + "status": { + "type": "string" + } + }, + "required": [ + "status" + ], + "type": "object" +}
- Changed
process_text1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "extracted": { + "items": { + "type": "object" + }, + "type": "array" + }, + "storedCount": { + "type": "number" + } + }, + "required": [ + "extracted", + "storedCount" + ], + "type": "object" +}
- Changed
recall1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "count": { + "type": "number" + }, + "memories": { + "items": { + "properties": { + "content": { + "type": "string" + }, + "createdAt": { + "format": "date-time", + "type": "string" + }, + "id": { + "type": "string" + }, + "similarity": { + "type": "number" + } + }, + "type": "object" + }, + "type": "array" + }, + "scope": { + "enum": [ + "agent", + "tenant" + ], + "type": "string" + } + }, + "required": [ + "memories", + "count", + "scope" + ], + "type": "object" +}
- Changed
recall_memory1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "count": { + "type": "number" + }, + "memories": { + "items": { + "properties": { + "content": { + "type": "string" + }, + "createdAt": { + "format": "date-time", + "type": "string" + }, + "id": { + "type": "string" + }, + "similarity": { + "type": "number" + } + }, + "type": "object" + }, + "type": "array" + }, + "scope": { + "enum": [ + "agent", + "tenant" + ], + "type": "string" + } + }, + "required": [ + "memories", + "count", + "scope" + ], + "type": "object" +}
- Changed
save_memory1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "id": { + "type": "string" + }, + "scope": { + "enum": [ + "agent", + "tenant" + ], + "type": "string" + }, + "stored": { + "type": "boolean" + } + }, + "required": [ + "id", + "stored", + "scope" + ], + "type": "object" +}
- Changed
save_to_synapse1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "id": { + "type": "string" + }, + "scope": { + "enum": [ + "agent", + "tenant" + ], + "type": "string" + }, + "stored": { + "type": "boolean" + } + }, + "required": [ + "id", + "stored", + "scope" + ], + "type": "object" +}
- Changed
search1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "count": { + "type": "number" + }, + "results": { + "items": { + "type": "object" + }, + "type": "array" + }, + "scope": { + "enum": [ + "agent", + "tenant" + ], + "type": "string" + } + }, + "required": [ + "results", + "count", + "scope" + ], + "type": "object" +}
- Changed
slo_report1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "errorRate": { + "type": "number" + }, + "p50": { + "type": "number" + }, + "p95": { + "type": "number" + }, + "uptime": { + "type": "number" + }, + "window": { + "type": "string" + } + }, + "required": [ + "uptime" + ], + "type": "object" +}
- Changed
store_memory1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "id": { + "type": "string" + }, + "scope": { + "enum": [ + "agent", + "tenant" + ], + "type": "string" + }, + "stored": { + "type": "boolean" + } + }, + "required": [ + "id", + "stored", + "scope" + ], + "type": "object" +}
2 tool updates
- Changed
initialize_context2 fields changed- added
Input schema / properties / detailAdded value: +{ + "description": "Detail level. \"summary\" (default) = redacted metadata only, no plaintext. \"full\" = plaintext content; REQUIRES the reason parameter and is audit-logged.", + "enum": [ + "summary", + "full" + ], + "type": "string" +} - added
Input schema / properties / reasonAdded value: +{ + "description": "REQUIRED only when detail=\"full\" (10–200 chars). Audit policy: MEMORY_EXPORT_GOVERNANCE_V1. Human-readable justification for retrieving PLAINTEXT context. Without it, detail=\"full\" WILL fail with code -32602.", + "type": "string" +}
- Changed
search2 fields changed- added
Input schema / properties / reasonAdded value: +{ + "description": "REQUIRED (10–200 chars). Audit policy: MEMORY_EXPORT_GOVERNANCE_V1. Human-readable justification for retrieving PLAINTEXT memory. Without this parameter the call WILL fail with code -32602. Example: \"Checking prior migration decisions for the user.\"", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "query" -]New value: +[ + "query", + "reason" +]
2 tool updates
- Changed
initialize_context2 fields changed- removed
Input schema / properties / detailRemoved value: -{ - "description": "Detail level. \"summary\" (default) = redacted metadata only, no plaintext. \"full\" = plaintext content; REQUIRES the reason parameter and is audit-logged.", - "enum": [ - "summary", - "full" - ], - "type": "string" -} - removed
Input schema / properties / reasonRemoved value: -{ - "description": "REQUIRED only when detail=\"full\" (10–200 chars). Audit policy: MEMORY_EXPORT_GOVERNANCE_V1. Human-readable justification for retrieving PLAINTEXT context. Without it, detail=\"full\" WILL fail with code -32602.", - "type": "string" -}
- Changed
search2 fields changed- removed
Input schema / properties / reasonRemoved value: -{ - "description": "REQUIRED (10–200 chars). Audit policy: MEMORY_EXPORT_GOVERNANCE_V1. Human-readable justification for retrieving PLAINTEXT memory. Without this parameter the call WILL fail with code -32602. Example: \"Checking prior migration decisions for the user.\"", - "type": "string" -} - changed
Input schema / requiredPrevious value: -[ - "query", - "reason" -]New value: +[ + "query" +]
13 tool updates
- Changed
health_check1 field changed- changed
Output schema / (root)Previous value: -{ - "additionalProperties": true, - "properties": { - "cacheAgeMs": { - "type": "number" - }, - "cacheHit": { - "type": "boolean" - }, - "capabilities": { - "additionalProperties": true, - "type": "object" - }, - "database": { - "type": "string" - }, - "dbRealLatencyMs": { - "type": "number" - }, - "engine": { - "type": "string" - }, - "latencyMs": { - "type": "number" - }, - "probeThresholds": { - "additionalProperties": true, - "type": "object" - }, - "status": { - "enum": [ - "healthy", - "degraded", - "unhealthy" - ], - "type": "string" - }, - "timestamp": { - "type": "string" - }, - "version": { - "type": "string" - } - }, - "required": [ - "status", - "version" - ], - "type": "object" -}New value: +null
- Changed
initialize_context3 fields changed- added
Input schema / properties / detailAdded value: +{ + "description": "Detail level. \"summary\" (default) = redacted metadata only, no plaintext. \"full\" = plaintext content; REQUIRES the reason parameter and is audit-logged.", + "enum": [ + "summary", + "full" + ], + "type": "string" +} - added
Input schema / properties / reasonAdded value: +{ + "description": "REQUIRED only when detail=\"full\" (10–200 chars). Audit policy: MEMORY_EXPORT_GOVERNANCE_V1. Human-readable justification for retrieving PLAINTEXT context. Without it, detail=\"full\" WILL fail with code -32602.", + "type": "string" +} - changed
Output schema / (root)Previous value: -{ - "additionalProperties": true, - "properties": { - "agent_id": { - "type": "string" - }, - "count": { - "type": "number" - }, - "error": { - "description": "Present only on fail-closed path.", - "type": "string" - }, - "initialized": { - "type": "boolean" - }, - "memories": { - "items": { - "additionalProperties": true, - "type": "object" - }, - "type": "array" - }, - "query": { - "type": "string" - }, - "scope": { - "type": "string" - } - }, - "required": [ - "initialized", - "count", - "memories" - ], - "type": "object" -}New value: +null
- Changed
list_memories1 field changed- changed
Output schema / (root)Previous value: -{ - "additionalProperties": true, - "properties": { - "agent_id": { - "type": "string" - }, - "count": { - "type": "number" - }, - "limit_applied": { - "type": "number" - }, - "memories": { - "items": { - "additionalProperties": true, - "properties": { - "createdAt": { - "description": "ISO-8601 timestamp.", - "type": "string" - }, - "id": { - "type": "string" - }, - "summary": { - "description": "Abstract summary — never plaintext content.", - "type": "string" - }, - "tags": { - "items": { - "type": "string" - }, - "type": "array" - } - }, - "type": "object" - }, - "type": "array" - }, - "redacted": { - "type": "boolean" - }, - "scope": { - "type": "string" - }, - "scope_source": { - "type": "string" - } - }, - "required": [ - "memories", - "count" - ], - "type": "object" -}New value: +null
- Changed
memory_feedback1 field changed- changed
Output schema / (root)Previous value: -{ - "additionalProperties": true, - "properties": { - "memoryId": { - "type": "string" - }, - "signal": { - "enum": [ - "used", - "ignored", - "helpful", - "irrelevant" - ], - "type": "string" - }, - "success": { - "type": "boolean" - } - }, - "required": [ - "success" - ], - "type": "object" -}New value: +null
- Changed
neural_handover1 field changed- changed
Output schema / (root)Previous value: -{ - "additionalProperties": true, - "properties": { - "fromAgent": { - "type": "string" - }, - "handoverId": { - "type": "string" - }, - "memories": { - "items": { - "additionalProperties": true, - "properties": { - "agent": { - "type": "string" - }, - "category": { - "type": "string" - }, - "content": { - "type": "string" - }, - "trust_quotient": { - "type": "number" - } - }, - "type": "object" - }, - "type": "array" - }, - "memoryCount": { - "type": "number" - }, - "success": { - "type": "boolean" - } - }, - "required": [ - "success" - ], - "type": "object" -}New value: +null
- Changed
process_text1 field changed- changed
Output schema / (root)Previous value: -{ - "additionalProperties": true, - "properties": { - "events_detected": { - "type": "number" - }, - "message": { - "type": "string" - }, - "pipeline": { - "additionalProperties": true, - "type": "object" - }, - "results": { - "items": { - "additionalProperties": true, - "properties": { - "intent": { - "type": "string" - }, - "memory_id": { - "type": "string" - }, - "trust_quotient": { - "type": "number" - } - }, - "type": "object" - }, - "type": "array" - }, - "status": { - "description": "'processed' on success; 'error' with a message on rejected input.", - "type": "string" - }, - "timestamp": { - "type": "string" - } - }, - "required": [ - "status" - ], - "type": "object" -}New value: +null
- Changed
recall1 field changed- changed
Output schema / (root)Previous value: -{ - "additionalProperties": true, - "properties": { - "agent_id": { - "type": "string" - }, - "count": { - "type": "number" - }, - "fallback": { - "type": "boolean" - }, - "memories": { - "items": { - "additionalProperties": true, - "properties": { - "agent": { - "type": "string" - }, - "confidence": { - "enum": [ - "high", - "medium_fts", - "low" - ], - "type": "string" - }, - "content": { - "description": "Memory content (truncated to 300 chars in recall).", - "type": "string" - }, - "hybridScore": { - "type": "number" - }, - "id": { - "type": "string" - }, - "intent": { - "type": "string" - }, - "is_critical": { - "type": "boolean" - }, - "memory_type": { - "type": "string" - }, - "timestamp": { - "description": "ISO-8601 timestamp.", - "type": "string" - }, - "trust_quotient": { - "type": "number" - } - }, - "type": "object" - }, - "type": "array" - }, - "query": { - "type": "string" - }, - "queryCacheHit": { - "type": "boolean" - }, - "recallLatencyMs": { - "type": "number" - }, - "recall_mode": { - "type": "string" - }, - "redacted": { - "type": "boolean" - }, - "scope": { - "type": "string" - }, - "scope_source": { - "type": "string" - }, - "sessionCacheHit": { - "type": "boolean" - } - }, - "required": [ - "memories", - "count" - ], - "type": "object" -}New value: +null
- Changed
recall_memory1 field changed- changed
Output schema / (root)Previous value: -{ - "additionalProperties": true, - "properties": { - "agent_id": { - "type": "string" - }, - "count": { - "type": "number" - }, - "fallback": { - "type": "boolean" - }, - "memories": { - "items": { - "additionalProperties": true, - "properties": { - "agent": { - "type": "string" - }, - "confidence": { - "enum": [ - "high", - "medium_fts", - "low" - ], - "type": "string" - }, - "content": { - "description": "Memory content (truncated to 300 chars in recall).", - "type": "string" - }, - "hybridScore": { - "type": "number" - }, - "id": { - "type": "string" - }, - "intent": { - "type": "string" - }, - "is_critical": { - "type": "boolean" - }, - "memory_type": { - "type": "string" - }, - "timestamp": { - "description": "ISO-8601 timestamp.", - "type": "string" - }, - "trust_quotient": { - "type": "number" - } - }, - "type": "object" - }, - "type": "array" - }, - "query": { - "type": "string" - }, - "queryCacheHit": { - "type": "boolean" - }, - "recallLatencyMs": { - "type": "number" - }, - "recall_mode": { - "type": "string" - }, - "redacted": { - "type": "boolean" - }, - "scope": { - "type": "string" - }, - "scope_source": { - "type": "string" - }, - "sessionCacheHit": { - "type": "boolean" - } - }, - "required": [ - "memories", - "count" - ], - "type": "object" -}New value: +null
- Changed
save_memory1 field changed- changed
Output schema / (root)Previous value: -{ - "additionalProperties": true, - "properties": { - "intent": { - "type": "string" - }, - "memory_id": { - "type": "string" - }, - "message": { - "type": "string" - }, - "pipeline": { - "additionalProperties": true, - "type": "object" - }, - "privacy_applied": { - "type": "boolean" - }, - "quota": { - "additionalProperties": true, - "type": "object" - }, - "sanitized": { - "type": "boolean" - }, - "status": { - "description": "'saved' on success; 'error' with a message on rejected input.", - "type": "string" - }, - "timestamp": { - "type": "string" - }, - "trust_quotient": { - "type": "number" - } - }, - "required": [ - "status" - ], - "type": "object" -}New value: +null
- Changed
save_to_synapse1 field changed- changed
Output schema / (root)Previous value: -{ - "additionalProperties": true, - "properties": { - "intent": { - "type": "string" - }, - "memory_id": { - "type": "string" - }, - "message": { - "type": "string" - }, - "pipeline": { - "additionalProperties": true, - "type": "object" - }, - "privacy_applied": { - "type": "boolean" - }, - "quota": { - "additionalProperties": true, - "type": "object" - }, - "sanitized": { - "type": "boolean" - }, - "status": { - "description": "'saved' on success; 'error' with a message on rejected input.", - "type": "string" - }, - "timestamp": { - "type": "string" - }, - "trust_quotient": { - "type": "number" - } - }, - "required": [ - "status" - ], - "type": "object" -}New value: +null
- Changed
search3 fields changed- added
Input schema / properties / reasonAdded value: +{ + "description": "REQUIRED (10–200 chars). Audit policy: MEMORY_EXPORT_GOVERNANCE_V1. Human-readable justification for retrieving PLAINTEXT memory. Without this parameter the call WILL fail with code -32602. Example: \"Checking prior migration decisions for the user.\"", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "query" -]New value: +[ + "query", + "reason" +] - changed
Output schema / (root)Previous value: -{ - "additionalProperties": true, - "properties": { - "agent_id": { - "type": "string" - }, - "count": { - "type": "number" - }, - "query": { - "type": "string" - }, - "results": { - "items": { - "additionalProperties": true, - "properties": { - "agent": { - "type": "string" - }, - "content": { - "type": "string" - }, - "intent": { - "type": "string" - }, - "is_critical": { - "type": "boolean" - }, - "memory_type": { - "type": "string" - }, - "timestamp": { - "type": "string" - }, - "trust_quotient": { - "type": "number" - } - }, - "type": "object" - }, - "type": "array" - }, - "scope": { - "type": "string" - }, - "scope_source": { - "type": "string" - } - }, - "required": [ - "results", - "count" - ], - "type": "object" -}New value: +null
- Changed
slo_report1 field changed- changed
Output schema / (root)Previous value: -{ - "additionalProperties": true, - "properties": { - "code": { - "description": "Error code on admin-auth failure.", - "type": "string" - }, - "error": { - "description": "Present only on admin-auth failure.", - "type": "string" - }, - "generatedAt": { - "type": "string" - }, - "status": { - "enum": [ - "nominal", - "degraded", - "insufficient_data" - ], - "type": "string" - }, - "version": { - "type": "string" - }, - "windows": { - "items": { - "additionalProperties": true, - "properties": { - "avgLatencyMs": { - "type": "number" - }, - "errorRate": { - "type": "number" - }, - "p50LatencyMs": { - "type": "number" - }, - "p95LatencyMs": { - "type": "number" - }, - "p99LatencyMs": { - "type": "number" - }, - "toolBreakdown": { - "additionalProperties": true, - "type": "object" - }, - "topErrors": { - "items": { - "additionalProperties": true, - "properties": { - "count": { - "type": "number" - }, - "errorCode": { - "type": "string" - } - }, - "type": "object" - }, - "type": "array" - }, - "totalRequests": { - "type": "number" - }, - "windowHours": { - "type": "number" - } - }, - "type": "object" - }, - "type": "array" - } - }, - "type": "object" -}New value: +null
- Changed
store_memory1 field changed- changed
Output schema / (root)Previous value: -{ - "additionalProperties": true, - "properties": { - "intent": { - "type": "string" - }, - "memory_id": { - "type": "string" - }, - "message": { - "type": "string" - }, - "pipeline": { - "additionalProperties": true, - "type": "object" - }, - "privacy_applied": { - "type": "boolean" - }, - "quota": { - "additionalProperties": true, - "type": "object" - }, - "sanitized": { - "type": "boolean" - }, - "status": { - "description": "'saved' on success; 'error' with a message on rejected input.", - "type": "string" - }, - "timestamp": { - "type": "string" - }, - "trust_quotient": { - "type": "number" - } - }, - "required": [ - "status" - ], - "type": "object" -}New value: +null
13 tool updates
- Changed
health_check1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "cacheAgeMs": { + "type": "number" + }, + "cacheHit": { + "type": "boolean" + }, + "capabilities": { + "additionalProperties": true, + "type": "object" + }, + "database": { + "type": "string" + }, + "dbRealLatencyMs": { + "type": "number" + }, + "engine": { + "type": "string" + }, + "latencyMs": { + "type": "number" + }, + "probeThresholds": { + "additionalProperties": true, + "type": "object" + }, + "status": { + "enum": [ + "healthy", + "degraded", + "unhealthy" + ], + "type": "string" + }, + "timestamp": { + "type": "string" + }, + "version": { + "type": "string" + } + }, + "required": [ + "status", + "version" + ], + "type": "object" +}
- Changed
initialize_context1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "agent_id": { + "type": "string" + }, + "count": { + "type": "number" + }, + "error": { + "description": "Present only on fail-closed path.", + "type": "string" + }, + "initialized": { + "type": "boolean" + }, + "memories": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + "query": { + "type": "string" + }, + "scope": { + "type": "string" + } + }, + "required": [ + "initialized", + "count", + "memories" + ], + "type": "object" +}
- Changed
list_memories1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "agent_id": { + "type": "string" + }, + "count": { + "type": "number" + }, + "limit_applied": { + "type": "number" + }, + "memories": { + "items": { + "additionalProperties": true, + "properties": { + "createdAt": { + "description": "ISO-8601 timestamp.", + "type": "string" + }, + "id": { + "type": "string" + }, + "summary": { + "description": "Abstract summary — never plaintext content.", + "type": "string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "type": "object" + }, + "type": "array" + }, + "redacted": { + "type": "boolean" + }, + "scope": { + "type": "string" + }, + "scope_source": { + "type": "string" + } + }, + "required": [ + "memories", + "count" + ], + "type": "object" +}
- Changed
memory_feedback1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "memoryId": { + "type": "string" + }, + "signal": { + "enum": [ + "used", + "ignored", + "helpful", + "irrelevant" + ], + "type": "string" + }, + "success": { + "type": "boolean" + } + }, + "required": [ + "success" + ], + "type": "object" +}
- Changed
neural_handover1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "fromAgent": { + "type": "string" + }, + "handoverId": { + "type": "string" + }, + "memories": { + "items": { + "additionalProperties": true, + "properties": { + "agent": { + "type": "string" + }, + "category": { + "type": "string" + }, + "content": { + "type": "string" + }, + "trust_quotient": { + "type": "number" + } + }, + "type": "object" + }, + "type": "array" + }, + "memoryCount": { + "type": "number" + }, + "success": { + "type": "boolean" + } + }, + "required": [ + "success" + ], + "type": "object" +}
- Changed
process_text1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "events_detected": { + "type": "number" + }, + "message": { + "type": "string" + }, + "pipeline": { + "additionalProperties": true, + "type": "object" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "intent": { + "type": "string" + }, + "memory_id": { + "type": "string" + }, + "trust_quotient": { + "type": "number" + } + }, + "type": "object" + }, + "type": "array" + }, + "status": { + "description": "'processed' on success; 'error' with a message on rejected input.", + "type": "string" + }, + "timestamp": { + "type": "string" + } + }, + "required": [ + "status" + ], + "type": "object" +}
- Changed
recall1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "agent_id": { + "type": "string" + }, + "count": { + "type": "number" + }, + "fallback": { + "type": "boolean" + }, + "memories": { + "items": { + "additionalProperties": true, + "properties": { + "agent": { + "type": "string" + }, + "confidence": { + "enum": [ + "high", + "medium_fts", + "low" + ], + "type": "string" + }, + "content": { + "description": "Memory content (truncated to 300 chars in recall).", + "type": "string" + }, + "hybridScore": { + "type": "number" + }, + "id": { + "type": "string" + }, + "intent": { + "type": "string" + }, + "is_critical": { + "type": "boolean" + }, + "memory_type": { + "type": "string" + }, + "timestamp": { + "description": "ISO-8601 timestamp.", + "type": "string" + }, + "trust_quotient": { + "type": "number" + } + }, + "type": "object" + }, + "type": "array" + }, + "query": { + "type": "string" + }, + "queryCacheHit": { + "type": "boolean" + }, + "recallLatencyMs": { + "type": "number" + }, + "recall_mode": { + "type": "string" + }, + "redacted": { + "type": "boolean" + }, + "scope": { + "type": "string" + }, + "scope_source": { + "type": "string" + }, + "sessionCacheHit": { + "type": "boolean" + } + }, + "required": [ + "memories", + "count" + ], + "type": "object" +}
- Changed
recall_memory1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "agent_id": { + "type": "string" + }, + "count": { + "type": "number" + }, + "fallback": { + "type": "boolean" + }, + "memories": { + "items": { + "additionalProperties": true, + "properties": { + "agent": { + "type": "string" + }, + "confidence": { + "enum": [ + "high", + "medium_fts", + "low" + ], + "type": "string" + }, + "content": { + "description": "Memory content (truncated to 300 chars in recall).", + "type": "string" + }, + "hybridScore": { + "type": "number" + }, + "id": { + "type": "string" + }, + "intent": { + "type": "string" + }, + "is_critical": { + "type": "boolean" + }, + "memory_type": { + "type": "string" + }, + "timestamp": { + "description": "ISO-8601 timestamp.", + "type": "string" + }, + "trust_quotient": { + "type": "number" + } + }, + "type": "object" + }, + "type": "array" + }, + "query": { + "type": "string" + }, + "queryCacheHit": { + "type": "boolean" + }, + "recallLatencyMs": { + "type": "number" + }, + "recall_mode": { + "type": "string" + }, + "redacted": { + "type": "boolean" + }, + "scope": { + "type": "string" + }, + "scope_source": { + "type": "string" + }, + "sessionCacheHit": { + "type": "boolean" + } + }, + "required": [ + "memories", + "count" + ], + "type": "object" +}
- Changed
save_memory1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "intent": { + "type": "string" + }, + "memory_id": { + "type": "string" + }, + "message": { + "type": "string" + }, + "pipeline": { + "additionalProperties": true, + "type": "object" + }, + "privacy_applied": { + "type": "boolean" + }, + "quota": { + "additionalProperties": true, + "type": "object" + }, + "sanitized": { + "type": "boolean" + }, + "status": { + "description": "'saved' on success; 'error' with a message on rejected input.", + "type": "string" + }, + "timestamp": { + "type": "string" + }, + "trust_quotient": { + "type": "number" + } + }, + "required": [ + "status" + ], + "type": "object" +}
- Changed
save_to_synapse1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "intent": { + "type": "string" + }, + "memory_id": { + "type": "string" + }, + "message": { + "type": "string" + }, + "pipeline": { + "additionalProperties": true, + "type": "object" + }, + "privacy_applied": { + "type": "boolean" + }, + "quota": { + "additionalProperties": true, + "type": "object" + }, + "sanitized": { + "type": "boolean" + }, + "status": { + "description": "'saved' on success; 'error' with a message on rejected input.", + "type": "string" + }, + "timestamp": { + "type": "string" + }, + "trust_quotient": { + "type": "number" + } + }, + "required": [ + "status" + ], + "type": "object" +}
- Changed
search1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "agent_id": { + "type": "string" + }, + "count": { + "type": "number" + }, + "query": { + "type": "string" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "agent": { + "type": "string" + }, + "content": { + "type": "string" + }, + "intent": { + "type": "string" + }, + "is_critical": { + "type": "boolean" + }, + "memory_type": { + "type": "string" + }, + "timestamp": { + "type": "string" + }, + "trust_quotient": { + "type": "number" + } + }, + "type": "object" + }, + "type": "array" + }, + "scope": { + "type": "string" + }, + "scope_source": { + "type": "string" + } + }, + "required": [ + "results", + "count" + ], + "type": "object" +}
- Changed
slo_report1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "code": { + "description": "Error code on admin-auth failure.", + "type": "string" + }, + "error": { + "description": "Present only on admin-auth failure.", + "type": "string" + }, + "generatedAt": { + "type": "string" + }, + "status": { + "enum": [ + "nominal", + "degraded", + "insufficient_data" + ], + "type": "string" + }, + "version": { + "type": "string" + }, + "windows": { + "items": { + "additionalProperties": true, + "properties": { + "avgLatencyMs": { + "type": "number" + }, + "errorRate": { + "type": "number" + }, + "p50LatencyMs": { + "type": "number" + }, + "p95LatencyMs": { + "type": "number" + }, + "p99LatencyMs": { + "type": "number" + }, + "toolBreakdown": { + "additionalProperties": true, + "type": "object" + }, + "topErrors": { + "items": { + "additionalProperties": true, + "properties": { + "count": { + "type": "number" + }, + "errorCode": { + "type": "string" + } + }, + "type": "object" + }, + "type": "array" + }, + "totalRequests": { + "type": "number" + }, + "windowHours": { + "type": "number" + } + }, + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
store_memory1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "intent": { + "type": "string" + }, + "memory_id": { + "type": "string" + }, + "message": { + "type": "string" + }, + "pipeline": { + "additionalProperties": true, + "type": "object" + }, + "privacy_applied": { + "type": "boolean" + }, + "quota": { + "additionalProperties": true, + "type": "object" + }, + "sanitized": { + "type": "boolean" + }, + "status": { + "description": "'saved' on success; 'error' with a message on rejected input.", + "type": "string" + }, + "timestamp": { + "type": "string" + }, + "trust_quotient": { + "type": "number" + } + }, + "required": [ + "status" + ], + "type": "object" +}
Related MCP Connectors
Give AI agents identity, permissions, and reusable proof through one MCP.
Persistent memory for AI agents to retain, retrieve, and recall conversation context through MCP.
- memnodeOAuthdev.memnode
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Verified memory for AI agents. Signed assertions, billing attestation, session continuity.
Related MCP Servers
- AlicenseAqualityAmaintenanceSovereign, encrypted, persistent memory for AI agents. Eight MCP tools — remember, recall, forget (GDPR Art. 17 erasure), share, governance. Anchored on COTI V2 mainnet. Apache-2.0.8288 npm1Apache 2.0
- FlicenseNot gradedqualityDmaintenanceTrust infrastructure for AI agents enabling directory browsing, agent submission/verification, job applications, and peer feedback exchange via MCP.-
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to maintain a persistent identity and structured memory—including reasoning patterns, episodic history, and knowledge—while exposing procedures for managing that memory over MCP.Apache 2.0
- AlicenseNot gradedqualityDmaintenanceProvides encrypted, portable memory for AI agents via MCP, allowing fact storage, conversation recall, and cross-machine sync using Arweave.16 npm50MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.