Synapse Layer — Continuous Consciousness Infrastructure
Server Details
Persistent zero-knowledge memory for AI agents. AES-256-GCM encryption, PII redaction.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- SynapseLayer/synapse-layer
- GitHub Stars
- 2
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.3/5 across 13 of 13 tools scored.
There are multiple aliases for similar operations: save_memory, save_to_synapse, store_memory all persist memory; recall and recall_memory are identical. This creates ambiguity for an agent trying to select the correct tool.
Naming is inconsistent: uses both snake_case and underscores, and mixes synonyms like save/store, recall/retrieve. Patterns like 'recall_memory' vs 'recall' and 'save_memory' vs 'save_to_synapse' are confusing.
13 tools is a reasonable number for a memory and context management server. There is some redundancy, but overall the count aligns with the stated purpose.
The tool surface covers create, read, and some feedback but lacks explicit update and delete operations. Missing essential lifecycle management for memories.
Available Tools
13 toolshealth_checkAInspect
Check service availability, engine version, and storage health. Public method.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description states the tool checks availability, version, and storage health, but does not disclose potential side effects, rate limits, or authentication requirements. It is likely a safe read operation, but this is not explicit.
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 with no wasted words. The key information is front-loaded: 'Check service availability, engine version, and storage health.'
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 simple health check with no parameters and no output schema, the description covers the essential purpose. However, it could optionally describe the format of the response to improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage. The description adds context about what the tool does without needing to explain parameters, meeting the baseline expectation for no-parameter tools.
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?
Description clearly states the tool checks service availability, engine version, and storage health. It uses a specific verb ('check') and distinguishes from sibling tools focused on memories and 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 labels it as a 'Public method' but provides no guidance on when to use this tool versus others, or any prerequisites. It implies general availability checking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
initialize_contextAInspect
Initialize a persistent memory context for a conversation or agent session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral details like idempotency, side effects, or authentication needs.
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?
Single sentence with no extraneous words, efficient 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?
Adequate for a parameterless tool but lacks return value details and fails to clarify its role relative to sibling memory 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?
Despite zero parameters and 100% schema coverage, the description adds meaning by indicating the tool's purpose beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Initialize' and resource 'persistent memory context', clearly distinguishing it from siblings like save_memory or store_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as whether it is a prerequisite for other memory operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_memoriesAInspect
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. | |
| agent_id | No | Agent identifier (canonical or alias). Used only when scope="agent" or scope is inferred. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds behavioral context by mentioning 'pagination and governance limits,' which implies read-only behavior and controlled output size. However, it does not disclose potential side effects, authorization requirements, or rate limits, so transparency is moderate.
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 concise sentence that conveys the core purpose and key features. It is front-loaded with the verb and resource, and every word is necessary. No redundancy or fluff.
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 three parameters with well-described schemas and no output schema, the description provides a high-level summary but fails to explain when to choose this tool over siblings like search or recall. It also omits the format of returned metadata, which would help an agent understand the output. Completeness is adequate but not comprehensive.
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 each parameter already has detailed descriptions (e.g., limit's default and cap, scope's enum and default). The description's phrase 'with pagination and governance limits' reinforces the limit parameter's behavior but does not add new meaning beyond what the schema provides. Thus a 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 function: 'List memory metadata with pagination and governance limits.' The verb 'list' and resource 'memory metadata' are specific, and the mention of pagination and limits distinguishes it from sibling tools like save_memory (write) and recall_memory (content retrieval).
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 explicit guidance on when to use this tool versus alternatives such as search or recall. It does not mention prerequisites, scope considerations, or exclusion criteria, leaving the agent to infer from context and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_feedbackCInspect
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 | Yes | ID of the memory to provide feedback on. | |
| sessionId | No | Optional session identifier for tracking. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states the action ('adjust trust scoring') but does not explain side effects, reversibility, or whether the feedback triggers immediate updates or batch processing. This is insufficient for a mutation tool.
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, concise sentence with no wasted words. It is front-loaded with the verb and objective. However, it sacrifices valuable detail for brevity, which could be restructured to include more context without harming 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?
Given the tool's relative complexity (3 parameters, enum, mutation behavior) and the absence of an output schema, the description is incomplete. It does not explain the outcome of submitting feedback, whether the trust score changes immediately, or if there is confirmation. More context is needed.
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%, so the parameter descriptions are already provided. The tool description adds no extra semantics beyond what the schema offers. For example, it does not clarify how 'ignored' differs from 'irrelevant' or if 'sessionId' is ever required. 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 clearly states the verb 'Submit feedback' and the resource 'adjust trust scoring for stored memories'. It is specific and leaves no ambiguity about the tool's core function. However, it does not differentiate from sibling tools like 'save_memory' or 'process_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 provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when to avoid using it, or comparison to sibling tools like 'store_memory' or 'recall'. The agent is left without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
neural_handoverBInspect
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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states 'transfer contextual state', implying mutation, but omits details about side effects, reversibility, authorization, rate limits, or whether the source state is consumed/destroyed. This is insufficient for a state-transfer operation.
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 efficiently conveys the core purpose. It is front-loaded and contains no redundant words. However, it could be slightly more descriptive without losing 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?
With no output schema and a complex operation (state transfer), the description is too brief. It does not explain what happens on success/failure, return values, error conditions, or what 'continuity controls' entail. Given the tool's importance among siblings, more detail is warranted.
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%, so the description does not need to add much. However, the phrase 'with continuity controls' is vague and does not clarify parameter meanings beyond what the schema already provides. The baseline of 3 is appropriate as the schema does the heavy lifting.
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 explicitly states the verb 'transfer', the resource 'contextual state', and scope 'between agents with continuity controls'. It clearly distinguishes from sibling tools like search, save_memory, and list_memories, which have different purposes.
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 guidance on when to use this tool versus alternatives. The description doesn't mention when not to use it, prerequisites, or contrast with related tools like initialize_context or save_to_synapse. The agent must infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
process_textBInspect
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". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions governance filters and sanitization but fails to specify what these do, whether the tool modifies state, returns extracted memories, or has side effects.
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 of 12 words with no redundant information, conveying the essential purpose efficiently.
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 no output schema and no annotations, the description lacks critical context about return values, side effects, and the destiny of extracted memories, leaving the agent uncertain about the tool's full behavior.
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 parameter descriptions are already clear. The tool description adds minimal value beyond identifying 'text' as free-form input with auto-save triggers; overall baseline score 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 clearly states the tool extracts candidate memories from free-form text, mentioning governance filters and sanitization, which distinguishes it from sibling tools like save_memory or recall.
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 use for parsing text to find potential memories but does not explicitly state when not to use it or name alternatives such as save_memory for direct saving.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallAInspect
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." | |
| agent_id | No | Agent identifier (canonical or alias). Used only when scope="agent" or scope is inferred. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses governance, rate limits, and fail-closed behavior for scope. It does not describe return format or error conditions beyond the reason requirement, but it adequately informs the agent of key behavioral traits.
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 sentences, front-loads the core purpose, and includes critical constraints concisely without unnecessary detail.
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 6 well-documented parameters and no output schema, the description covers the high-level operation, routing modes, and governance. It is sufficiently complete for an agent to understand the tool's function and constraints.
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%, so the baseline is 3. The description does not add significant meaning beyond the schema descriptions, though it provides context on governance and fail-closed behavior that augments the schema slightly.
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 verb 'Retrieve' and resource 'persisted memory', and it specifies routing modes (semantic, temporal, priority, hybrid) that distinguish it from sibling tools like list_memories or search.
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 governance requirements (reason parameter, length constraints) and a rate limit. It implies when to use this tool (memory retrieval) but does not explicitly differentiate from the sibling tool recall_memory or specify when each routing mode is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recall_memoryCInspect
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." | |
| agent_id | No | Agent identifier (canonical or alias). Used only when scope="agent" or scope is inferred. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states 'Recall persisted memory by query' but fails to mention whether the operation is read-only, side effects, or any constraints (e.g., authorization, rate limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (one sentence) but under-specified given the tool's complexity (6 parameters, 2 enums). It conveys purpose but lacks sufficient detail for a well-rounded definition.
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 description does not cover return values (no output schema) or behavioral nuances. For a tool with multiple parameters and routing modes, the description feels incomplete.
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%, so the baseline is 3. The description adds no additional meaning beyond what the schema provides, but since all parameters are documented in the schema, no deduction is warranted.
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 performs memory recall by query and identifies itself as an alias of 'recall'. However, it does not differentiate itself from the sibling tool 'recall', which shares identical functionality.
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 guidance is provided on when to use this tool versus alternatives like 'recall' or other sibling tools. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_memoryBInspect
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. | |
| agent_id | No | Agent identifier for memory isolation. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only says 'save to persistent store' without detailing side effects, return values, or whether overwriting occurs. This is insufficient for a write operation.
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 sentences) and front-loaded, with no wasted words. The first sentence conveys the core action, and the second clarifies the alias.
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 no output schema and minimal description, the tool lacks important context such as return type, error handling, and behavior on duplicate entries. The description is incomplete for a tool that persists data.
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 baseline is 3. The description does not add any extra meaning beyond the parameter descriptions in the schema. It merely restates the action.
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 saves a memory entry to persistent store and identifies it as an alias of save_to_synapse, which distinguishes it from siblings. The verb 'save' and resource 'memory entry' are specific.
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 only mentions it is an alias of save_to_synapse, providing minimal guidance. It does not specify when to use this tool versus other memory tools like store_memory, nor does it give exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_to_synapseBInspect
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). | |
| agent_id | No | Agent identifier for memory isolation. Defaults to "default". | |
| importance | No | Importance level 1–5 (default: 3). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses encryption at rest, sanitization, and deduplication controls, but does not mention other behavioral traits like auth requirements, side effects, or what happens on failure. This is moderate transparency.
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?
Single sentence, no redundant words. It efficiently mentions three distinct features, though the word 'persist' is slightly vague. Well-structured for a tool with moderate complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and many sibling tools, the description should provide more context about return values, side effects, or when to use. It only covers encryption and deduplication, leaving gaps for effective selection and invocation.
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%, so the schema already describes each parameter. The description adds overall context about encryption, sanitization, and deduplication, but does not enhance understanding of individual parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Persist memory with encryption at rest, sanitization, and deduplication controls.' It identifies the resource (memory) and adds specific security features, which distinguishes it from sibling tools like save_memory or store_memory. However, 'persist' is a less direct verb than 'save' or 'store', slightly reducing clarity.
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 guidance on when to use this tool vs alternatives. Given multiple sibling tools for memory (save_memory, store_memory, recall_memory, etc.), the absence of usage context is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchCInspect
Search persisted memory across agent scopes using full-text matching.
| 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). | |
| agent_id | No | Agent identifier (canonical or alias). Used only when scope="agent" or scope is inferred. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions full-text matching and cross-scope search but does not disclose whether it is a read-only operation, performance implications, or what gets returned. The schema adds some context (e.g., default limit, scope fail-closed), but the description lacks critical behavioral traits.
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 that efficiently conveys the core purpose. It avoids unnecessary words while remaining understandable. Slightly more detail could be added without losing 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?
Given no output schema and 4 parameters, the description is insufficient. It does not explain the output format (e.g., list of memories vs. snippets with scores), how full-text matching works (e.g., case sensitivity, stemming), or any limitations. The rich parameter descriptions in the schema partially compensate, but overall completeness is lacking.
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% with detailed parameter descriptions (including defaults, enums, and conditional behavior). The tool description adds no additional semantic meaning beyond the schema, so a 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 it searches persisted memory using full-text matching across agent scopes. The verb 'search' and resource 'persisted memory' are specific, and it distinguishes from siblings like list_memories or recall. However, it could be more explicit about what 'persisted memory' entails.
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 guidance is provided on when to use this tool versus alternatives such as recall, list_memories, or memory_feedback. The description only explains the scope parameter behavior but does not help the agent decide which tool to use in different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
slo_reportBInspect
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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the tool returns metrics but does not mention that it is read-only, what happens with invalid tokens, rate limits, or data freshness. This leaves the agent uninformed about important behavioral aspects.
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, efficient sentence with no wasted words. It is front-loaded with the 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 no output schema, the description should explain the return value. It does not describe the format, error conditions, or what specific SLO metrics are included. The tool has 2 parameters but the description lacks completeness for an agent to understand the output.
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%, so the schema already describes both parameters (admin_token and window_hours). The description adds no additional meaning or format details beyond what is in the schema. 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 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 provides a different health status, and other memory/text tools.
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 does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for obtaining SLO metrics but lacks when-not or comparison with sibling tools like 'health_check'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
store_memoryCInspect
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. | |
| agent_id | No | Agent identifier for memory isolation. Defaults to "default". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions 'trust scoring' and 'metadata' but does not explain what those entail (e.g., idempotency, side effects, storage behavior). The description is too vague to inform agent decisions.
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 concise sentence that captures the core purpose. It is front-loaded and efficient, though slightly more structure (e.g., listing metadata fields) would improve clarity without adding much length.
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 no output schema and the presence of sibling memory tools, the description lacks essential context: what the return value is (e.g., confirmation, memory ID), how trust scoring works, and how this tool differs from others. Incomplete for a storage operation.
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 with all parameters described. The description adds a high-level phrase about metadata and trust scoring but does not elaborate on how parameters like 'tags' or 'agent_id' relate to those concepts. 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 uses a specific verb ('Store') and resource ('structured memory') with added details about metadata and trust scoring. This helps differentiate from generic memory tools, but it does not explicitly distinguish from the sibling tool 'save_memory', which sounds similar.
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 guidance is provided on when to use this tool versus the many sibling tools, particularly 'save_memory'. The description does not mention any context or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!