synapsen-mcp

by Xarksus

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
Disambiguation4/5
Each tool has a distinct role: reading, formatting as prompt, event-driven updates, fine-grained injection, settling, explaining causes, and history. The only mild overlap is between state_read and state_prompt, but the descriptions clarify that one is raw state and the other is a ready-to-use prompt fragment.
Naming Consistency4/5
All tools consistently use the state_ prefix and lowercase naming. Some entries use nouns or adverbs instead of verbs, but the pattern is predictable and easy to navigate.
Tool Count5/5
Seven tools is a well-scoped size for this state-management domain. Each tool provides a meaningful capability without unnecessary bloat or missing core functionality.
Completeness4/5
The set covers reading state, using it in prompts, updating via events, fine-grained adjustment, settling, causal tracing, and viewing history. A hard reset or history-clearing operation is absent, but the deliberate design avoids it and the core lifecycle is well covered.
Average 3.1/5 across 7 of 7 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 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 Apache 2.0.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden for behavioral disclosure. It only says 'the most recently logged events', without stating whether the operation is read-only, what the response contains, or whether days affects the result.
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 phrase is short and contains no fluff. However, it is a fragment-like noun phrase that under-specifies behavior, so the brevity is more a sign of missing information than effective concision.
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?
For a tool with one optional parameter, no annotations, and no output schema, the description should clarify the time window, return type, and how it relates to sibling tools. The current text only restates the subject and is not enough for reliable autonomous invocation.
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?
The schema defines a 'days' parameter with default 7 and 0% description coverage. The description does not mention 'days' at all, so an agent cannot infer its effect on the returned events.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the content ('die zuletzt protokollierten Ereignisse') and implies a history/read view, but it lacks a verb that states what the tool does. It also does not distinguish state_history from siblings like state_read or state_event.
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?
There is no guidance about when to use this tool instead of state_read, state_event, or state_inject, and no indication of scope or exclusions. The word 'history' is the only cue, which is not enough.
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 carries the full burden for behavioral disclosure. It reveals the output form (a ready-made system-prompt addition) and its intended placement, but it does not state whether the tool is read-only, whether it has side effects, what data is included in the state, or how the output is generated. This is a meaningful gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two short sentences with no filler. The core concept is front-loaded, and the usage instruction follows. The main weakness is vagueness, not structural waste or unnecessary length.
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 the tool being simple, the description leaves important context missing: what 'derselbe Zustand' refers to, how the two parameters shape the resulting prompt, and how this tool relates to siblings like state_read. Without an output schema or annotations, the description should provide more behavior and relationship context to be fully actionable.
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?
Schema coverage is 50%, and the description adds no information about the parameters. It does not explain how 'partner' affects the prompt or how the 'language' option changes the output. The schema itself provides some clarity, but the description fails to compensate for the uncovered half or clarify parameter impact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description indicates that the tool provides the current state as a ready-made system-prompt addition and instructs the agent to read and prepend it before answering. However, 'Derselbe Zustand' has no antecedent within the description, and the tool's core action is only implied rather than stated with a clear verb. It also does not differentiate itself from siblings like state_read or state_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Vor einer Antwort lesen und voranstellen' gives explicit when-to-use guidance: before answering, read and prepend the output. But it does not explain when not to use this tool or mention alternatives such as state_read or state_inject. The usage context is clear but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does disclose two traits: the operation is gentle and it is not a hard reset. It leaves undefined what 'Ruhewert' means, what side effects occur, and how the tool affects the state, so the disclosure is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences, each carrying useful information: the gentle regulation behavior and the explicit negative that it is not a hard reset. There is no filler or redundant restatement of the tool name.
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?
Although the tool is simple with one optional parameter, the description still leaves key facts unspecified: what 'Ruhewert' is, how fraction changes behavior, and what the expected result or side effects are. With no annotations or output schema, the agent has too little context to confidently select and invoke this tool.
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?
Schema description coverage is 0% and the description never mentions the 'fraction' parameter or its meaning. The word 'Sanft' hints that fraction may control gentleness, but the agent cannot tell whether fraction is a target, a step size, or a weight. Since the description does not compensate for the missing schema description, this is a weak area.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—'Sanft Richtung Ruhewert regulieren'—which tells the reader the tool adjusts something gently toward a resting value. It also adds 'Kein harter Reset' to clarify the operation is not a hard reset, which prevents confusing it with a reset operation. However, it does not explicitly contrast it with the sibling state tools, so it is clear but not fully differentiated.
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 provides no when-to-use guidance, prerequisites, or alternative tool suggestions. 'Kein harter Reset' only implies that the tool should not be used when a hard reset is intended, without specifying when it should be chosen over the listed siblings like state_inject or state_prompt.
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 carries the full burden of behavioral disclosure. It names the state categories returned or represented, but does not explicitly state that this is a read-only operation, what the output format is, or any side effects or access constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that leads with the core subject and then provides a concise list of state components. Every word earns its place; there is no redundancy or filler.
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?
For a parameterless tool the description is mostly sufficient, but with no output schema it would benefit from clarifying what the returned state looks like or how the listed categories are represented. The current description gives the topic areas but not enough detail to fully predict the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter documentation burden. The description appropriately explains what the state contains, which is the relevant semantic context for a parameterless read call.
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 'Aktueller innerer Zustand' clearly identifies the resource as the current internal state and enumerates its content areas (Botenstoffe, Gefühlslagen, Bindung, Ermüdung). 'Aktueller' helps distinguish it from state_history, though it does not explicitly differentiate it from all siblings.
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 given about when to use this tool versus the sibling tools such as state_history, state_why, or state_event. The intended usage is implied by the name and description, but there is no explicit context, exclusions, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It does disclose a key side effect: the state changes automatically after reporting the event. Yet it does not say whether the change is reversible, what happens on invalid input, whether there are additional side effects, or what kind of response the caller can expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two short sentences with no filler. The first sentence states the core operation immediately, and the second adds the essential behavioral consequence. It is concise and front-loaded, though slightly too sparse to be considered excellent.
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?
For a simple event-reporting tool with a self-describing enum, this description is near-adequate: it explains the purpose and the automatic state effect. Still, there is no output schema and no annotation safety profile, and the description does not cover return behavior, failure modes, or when to choose this over sibling state tools.
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?
The schema already documents 'context' and 'intensity' with useful descriptions. The tool description adds that 'event' is a named trigger that causes automatic state change, which gives the enum some semantic weight. However, it does not explain the meaning of the individual enum values or how 'intensity' and 'context' influence the resulting state change.
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 clearly states the action: 'Ein benanntes Ereignis melden' (report a named event), and adds the key consequence that the state changes automatically. This distinguishes it at least implicitly from sibling tools like state_inject or state_settle, which likely manipulate state directly, though no sibling is explicitly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Der Zustand verändert sich daraufhin von selbst' implies this tool is for triggering an automatic state transition rather than setting state directly. However, it gives no explicit when-to-use guidance, no exclusions, and names no alternative tool, so the agent must infer the selection logic from the sibling names.
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 carries the full burden of behavioral disclosure. It merely says 'change' a substance but does not explain side effects, reversibility, whether this is destructive, or what state mutation consequences occur. The description adds very little beyond the name for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and containing no filler. It earns its place by giving the operative concept and a routing hint to the sibling, all with maximum economy.
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 3 parameters, 2 required, no output schema, and no annotations, the description should provide much more context. It tells the agent when to use it but leaves the meaning of amount/context and the behavioral effects completely open, so an agent cannot reliably call it correctly without additional reasoning.
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?
Schema description coverage is 0%, so the description must compensate for all parameter meanings. It vaguely implies hormone and amount are related to changing a messenger substance, but it does not clarify the meaning of 'amount' (absolute value, delta, units), the role of the optional 'context', or how the list of hormones maps to the operation. This gap is significant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description, though German, gives a specific verb 'verändern' (change) and a specific resource 'einzelnen Botenstoff' (single messenger substance), and distinguishes itself from the sibling state_event by framing itself as 'Feinsteuerung' (fine control). This is enough for an agent to know what the tool does and roughly how it differs from the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that in normal cases state_event should be preferred, giving an alternative and a clear sense of when this tool is for special fine-grained adjustments. It could be more explicit about exact triggering conditions, but it does provide an exclusions and a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It conveys that the tool performs causal analysis and indicates the content of the explanation (events, daily rhythm, coupling), but it does not state side effects, output format, or whether invocation is non-mutating.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences carry all essential information: the first states the tool's core function and examples, the second states its intended use cases. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool, the description is largely complete: it explains what the tool does and what kind of causal dimensions it reports. The main gap is the lack of explicit return format or side-effect behavior, but the low complexity makes that a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema needs no semantic enrichment and the baseline is 4. The description adds conceptual context by naming the analyzed causal dimensions, which helps an agent understand what the tool considers even though no inputs are accepted.
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 uses a specific verb and resource: it traces the current state back to its causes (Ereignisse, Tagesrhythmus, Kopplung). It clearly identifies the tool as a causal dagnostic operation, which differentiates it from state_read or state_history, though it does not name alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Für Fehlersuche und Nachvollziehbarkeit' explicitly states when to use the tool: for debugging and traceability. It provides clear usage context, though it does not give exclusions or explicitly point to sibling alternatives.
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:

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

Score Badge

Copy to your README.md:

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

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/Xarksus/synapsen'

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