synapsis

by teamolimpo

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct area (admin, consolidation, hash ops, handoff, search, session, task) with no overlapping purposes, ensuring agents can easily differentiate.
Naming Consistency3/5
Tool names mix full words (admin, consolidate), underscores (d_get, d_set), and abbreviations (hf). While readable, the inconsistent pattern may reduce predictability.
Tool Count5/5
Eight tools is well within the ideal range, each serving a clear and necessary function in the server's memory/agent domain.
Completeness4/5
The tool set covers core lifecycle operations for sessions and tasks, plus search and admin utilities. Minor potential gaps (e.g., explicit deletion) are acceptable given the scope.
Average 2.1/5 across 8 of 8 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 3 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but fails to disclose any behavioral traits such as side effects, permissions, or what happens during a handoff. Compact parameters like 'tk' (default 300) and 'q' are left unexplained, leaving the agent uninformed about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but not appropriately sized; it sacrifices necessary detail for brevity. Every sentence should earn its place, but here the minimal text leaves critical gaps. It is under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 15 parameters, 0% schema coverage, and no annotations, the description is severely incomplete. It does not explain the tool's output (though output schema exists), nor does it provide enough context for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only lists 'act, st, prio, tk, q' as compact params without explaining their purpose, format, or constraints. For 15 parameters, the description adds no meaningful semantics beyond what the parameter names provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Handoff: act=new (create) | act=get (read)' which suggests two modes but does not clarify what a handoff is or what resource it operates on. The term 'handoff' is ambiguous without further context, and the description provides no elaboration beyond the act values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'task' or 'session'. There is no mention of prerequisites, use cases, or conditions that would help an agent decide between sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only lists lifecycle steps without mentioning side effects, safety, or mutability. A score of 1 is justified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but fails to convey essential information. It is under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 22 parameters, no annotations, and a complex schema, the description is severely incomplete. It does not cover return values or parameter behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no meaning to 22 cryptic parameters (e.g., tk, tkdc). Parameter semantics are completely opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Session lifecycle: init | observe | context | summarize | compress | tasks' lists possible actions but does not specify a clear verb-resource combination. It fails to distinguish from siblings like admin or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 provides no context for appropriate usage or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides no information about side effects, required permissions, or what actions are performed. It merely lists operation names without any 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly brief—a single line listing operations—but for a tool with 8 parameters, this under-specification harms usability. It is concise at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no param docs, no annotations, output schema exists but unmentioned), the description is woefully incomplete. It fails to explain inputs, outputs, or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It does not mention any of the 8 parameters (act, cmd, domain, etc.) or their semantics, leaving the agent completely in the dark.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists actions like 'health', 'domain', 'orphan', etc., but does not clearly state an overall purpose or verb-resource pair. It is vague and resembles a menu rather than a coherent tool function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over siblings (e.g., consolidate, search). There is no context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only hints at different result sizes per level but does not state whether the tool is read-only, destructive, or requires authentication. Behavioral traits remain unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (10 words), front-loading the main action. However, the cryptic abbreviations ('meta', '+500ch') sacrifice clarity for conciseness. It is structured but under-informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown) and only 2 parameters, the description fails to give context about what the different levels return, how the hash is used, or how this tool fits among 7 siblings. Completeness is poor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description minimally explains the 'l' parameter (levels 1-3) and implies 'h' is a hash. It adds some meaning for 'l' but not for 'h', leaving the hash format unspecified. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Resolve hash' which is a verb+resource, but the level explanations are cryptic ('meta', '+500ch', 'full') without defining what hash refers to. It does not distinguish from sibling tools like 'd_set' or 'search', leaving purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 like 'search' or 'hf'. No context about prerequisites, when not to use it, or what the levels imply for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral aspects such as side effects, authentication requirements, rate limits, or whether actions are destructive. The agent cannot infer safety or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and front-loaded with the action list. It wastes no words, but the brevity sacrifices necessary detail. It is minimally concise for a simple tool, but here the tool is complex.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (22 parameters, multiple actions, output schema), the description is severely incomplete. It does not explain the semantics of each action or parameter, nor the expected output beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 22 parameters and 0% schema description coverage, the description only explains 'sts' vs 'status' for the update action. All other parameters (act, desc, prio, etc.) lack any explanation, leaving the agent to guess their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists the actions (create, query, update, log, summary, export, compress) clearly, indicating the tool covers the task lifecycle. It differentiates from sibling tools like 'search' or 'admin' by focusing on task management, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only provides guidance for the update action, suggesting 'sts' over 'status'. No general guidance on when to use this tool compared to siblings, nor when to use specific actions like create vs. log.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only lists searchable domains but omits any behavioral traits such as whether the operation is read-only, harmful side effects, authentication requirements, rate limits, or result format. The agent has no insight into safety or behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one line) and front-loads the action 'Search', which is good. However, it is essentially a list of items separated by commas, which is clunky. No structural elements like bullet points or sections. Every word earns its place, but the format is suboptimal for rapid scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters (1 required) and no output schema details in the description, the tool is inadequately documented. The description fails to explain how queries work, what results look like, or how parameters affect search. An output schema exists but is not referenced; the agent must infer semantics from names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information. Required parameter 'query' is unexplained (type, expected content). Optional parameters like 'scope', 'l', 'n', 'ref', 'since', 'tk' are not mentioned at all. The agent must rely solely on parameter names and types, which are minimal (e.g., 'scope' is a string with no enum, 'l' integer default 1 without explanation).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search knowledge, tasks, observations, entities, memory_layers, session, timeline, hf.' which clearly identifies the tool as a search across multiple resources. However, it does not explicitly contrast with sibling tools like 'task' or 'hf', leaving some ambiguity about when to use this unified search vs. specific domain tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines provided. The description does not mention when to use this tool versus alternatives (e.g., sibling tools like 'task' for task-specific ops or 'hf' for HF-related queries). No context on prerequisites or situations where search is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits such as side effects, authentication requirements, or error conditions. For a registration operation, it is unclear whether the action is idempotent or what happens if the path already exists. Since no annotations are provided, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it sacrifices necessary detail for brevity. It is concise but insufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, return values do not need further explanation. However, the description lacks essential context about the registration process, such as persistence, uniqueness, or potential side effects, making it incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description should compensate, but it only generically mentions 'file path'. The parameter 'p' is not explained beyond the schema, leaving users uncertain about format, valid values, or semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Register file path. Returns hash.' which clearly indicates the action (register) and the resource (file path) and hints at a return value (hash). However, it does not differentiate from sibling tools like d_get, which might also deal with file paths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any context about prerequisites or conditions under which it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses auto-check conditions and difference between auto=True (lightweight) and auto=False (full explicit). No annotations exist, so description carries full burden. Could mention side effects (e.g., deletion of original observations).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences; first sentence states core purpose, subsequent sentences detail auto flag behavior. Efficiently front-loaded, though could tighten wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers auto mechanism and thresholds, but omits parameter details (sid, days, dry). Has output schema, so return values may be defined there, but parameter lack reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0% and description only mentions 'auto' parameter (default=True). No explanation for sid, days, or dry parameters, leaving agent guessing their meaning and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb-resource pairing: 'Distil unconsolidated observations into structured memory layers.' Distinguishes from sibling tools (admin, search, session, etc.) which are unrelated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes two modes (auto=True/False) with explicit conditions for auto-trigger (e.g., >20 unconsolidated obs, obs older than 7 days). No explicit 'when not to use', but conditions clarify appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![synapsis MCP server](https://glama.ai/mcp/servers/teamolimpo/synapsis/badges/card.svg)](https://glama.ai/mcp/servers/teamolimpo/synapsis)

Score Badge

Copy to your README.md:

[![synapsis MCP server](https://glama.ai/mcp/servers/teamolimpo/synapsis/badges/score.svg)](https://glama.ai/mcp/servers/teamolimpo/synapsis)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/teamolimpo/synapsis'

If you have feedback or need assistance with the MCP directory API, please join our Discord server