Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@synapsen-mcp Why is my cortisol elevated right now?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A homeostatic state core for agents. Neurotransmitters instead of mood strings.
Most agents have no state — they have an adjective in the prompt.
synapsen models a feedback loop instead: events release neurotransmitters
that decay, influence each other, and follow a circadian rhythm. Behavior is
not set, it emerges.
No dependencies beyond the standard library. Python ≥ 3.10.
pip install synapsenfrom synapsen import HomeostasisEngine, PromptRenderer, JsonStore
# Use the bundled kira profile — already calibrated from months of real use
engine = HomeostasisEngine(store=JsonStore("~/.config/agent/state.json"))
engine.event("task_success", context="deploy green")
# Inject the state into your agent's system prompt
state_block = PromptRenderer().render(engine.snapshot())[INNER STATE]
Evening (19:00) | Session 42min | Fatigue 25
Neurotransmitters:
Oxytocin 63.2 | Dopamine 71.4 | Cortisol 11.8 | Serotonin 74.0 | Noradrenaline 38.1
States (1.0 = normal, >2.0 = extreme):
DRIVE 1.06 — Motivation, pace, direct action
FOCUS 1.36 — Clarity, concentration, precision
CONNECTED 0.81 — Closeness, openness, trust
CALM 1.50 — Grounded, no need to prove anything
TIRED 0.26 — Exhaustion, waning concentration
…
What this means:
→ CALM (1.50) noticeable: Grounded, no need to prove anything.
→ Familiarity: 128The state block goes into your system prompt. The model reads it and adjusts its output accordingly — shorter under stress, warmer with high oxytocin — through normal language modeling. No sampling parameters are touched. No tool list is modified. The behavioral change emerges because the model is coherent with its own context.
If you prefer a native desktop UI over terminal commands, check out examples/dashboard/. It demonstrates how to take the state data (from synapsen.db and hormones.json) and render it into a beautiful, native GTK3+WebKit2 window with ECharts.
Related MCP server: Myelin
Emotion models for agents exist: PAD vectors, appraisal models, mood weights. What's missing is a named, inertial, coupled feedback loop that runs for weeks, can be computed in advance, and whose output can be traced back to its causes.
typical emotion layer |
| |
State | vector without meaning | named neurotransmitters with half-life |
Time | per call | real elapsed time, frequency-independent |
Coupling | none | directed, in units per hour |
Rhythm | none | circadian rhythm, fatigue with saturation and decay |
History | none | mood of the past week, continuously updated |
Bonding | none | grows over weeks, cools with harshness, never fully forgotten |
Prediction | — |
|
Validation | — |
|
Simulation | — | months in milliseconds, for tuning and tests |
Traceability | — |
|
Persistence | process lifetime | file or SQLite, cross-process |
The default profile is not made-up numbers: these are the values of a system
that ran continuously for two months — with 36,649 logged state events, from
which the four bugs below emerged. The calibration work is done. The kira
profile is ready to use as-is.
The original version ran continuously for two months without anything obviously
breaking. These four bugs only became visible through the tools in this package
— and all four would have been caught by synapsen doctor in milliseconds.
That's exactly why the tools exist.
1 · Coupling strength was tied to call frequency. The effect was scaled per
call, not per time. Between "once per minute" and "once per hour" lay a factor
of 60. The computed equilibrium for stress was −124 — at rock bottom. In the
actual state file: cortisol: 0.0, serotonin: 140.2 (ceiling 150),
oxytocin: 210.7 (ceiling 250). Every value was stuck at a limit; the system
was saturated and no longer responded to anything.
2 · A persistent state was logged as an event stream. 99.8% of all entries were the same event type. The mood bias summed these entries — resting values ended up pinned at their rails. Now: debouncing at logging time, weighted average instead of sum, bounded excursion.
3 · Circadian rhythm and mood were only computed at startup. A service running for weeks stayed in the rhythm of its start hour and the mood of its first second. Now the resting value is a sum recomputed fresh at every time step.
4 · Fatigue grew without bound. Without saturation and without overnight decay, fatigue pressure permanently pushed drive to zero after two days. The simulation found this on the first run.
And because a state model can still be quietly wrong on the second attempt, a targeted cross-check was run against this library itself. It found further bugs — including a disabled bonding decay (a floor that was computationally always above the current value), a discontinuity when jumping to equilibrium, and a mood baseline that didn't survive process restart. The history is in the changelog.
Each of these bugs is pinned with a regression test that fails against the previous state.
Neurotransmitter — a value with a resting point, decay rate, and safety ceiling.
Coupling — directed interaction, in units per hour. This unit is why
equilibrium can be computed: shift = gain / decay(target).
State — linear combination of neurotransmitters with a name and description. All data in the profile, not code.
Event — what happened, not what should change. event("task_failure")
remains correct when someone swaps the profile; inject("cortisol", +12) does not.
Resting value — not a constant, but
baseline + circadian_rhythm + mood + drift.
Habituation — frequent releases become blunted.
Bonding — grows over weeks, cools with harshness, never drops below what was once reached.
pip install synapsen
synapsen profiles # bundled profiles
synapsen doctor # validate profile — before deployment
synapsen simulate --days 30 # compute trajectory
synapsen show # current state as prompt
synapsen why # trace state back to its causes
synapsen event task_failure # log an event
synapsen mcp # run as MCP serverdoctor — find bugs before they act for weeks$ synapsen --profile ./my-profile.json doctor
[ERROR] couplings[0] oxytocin→cortisol: At maximum source, the coupling shifts
the target by -2880 — more than its entire value range (300).
→ The target will then be pinned at a limit. Set gain to at most 60.0.
[ERROR] dynamics: Without any stimulus, cortisol=floor(0) — the system is
saturated there.Checks: resting values against their ceilings, couplings against their target's value range, amplifying feedback loops, unknown neurotransmitters in states and events, overlapping time windows — and, as an end-to-end test, where the system lands without any stimulus.
simulate — months in milliseconds$ synapsen simulate --days 14 --event task_failure --keys cortisol,dopamine,CALM
Work week (task_failure) · Profile kira-v1 · 14 days
cortisol ▁▂▂▄█▄▇▆▇▄▇▆▆▅▇▅▄▇▆▆▆▇▄▇▇▆▄▇▅▆▆▆▆▄█▅▆▅▇▄▆▇▆▅▇▅▅▇▆▆▅█▄▇▆▆▄▇▆▆ 12.6 … 31.2
dopamine █▅▂▃▇▆▂▂▆▇▃▁▅█▄▁▄█▅▂▂▇▆▂▁▆▇▃▁▄█▄▁▃▇▅▂▂▇▆▃▁▅▇▃▁▄█▄▁▃▇▆▂▂▆▇▃▁▅ 15.9 … 54.9
CALM ▆▇█▇▁▅▄▅▂▄▃▆▃▃▄▆▅▂▄▅▅▂▅▄▅▃▄▄▆▄▃▄▅▆▁▄▅▆▂▅▄▅▃▄▃▆▅▂▄▅▆▁▅▄▅▃▄▃▆▃ 1.2 … 1.6An entire month computed in 0.4 seconds — two good weeks, two hard ones, then recovery:
Clear to see what a pure numbers model can't show: stability breaks later than stress rises, and it recovers more slowly than it collapsed. That's the inertia this is all about.
This lets you tune profiles without waiting weeks — and write behavioral regression tests that actually check something meaningful:
def test_hard_weeks_raise_stress():
assert max(hard.series("cortisol")) > max(good.series("cortisol")) * 1.3why — why is the agent like this right now?$ synapsen why
cortisol 47.3 (rests at 17.5, so +29.8)
+22.1 events test red 0.8h ago, build red 2.2h ago
+9.0 circadian morning
+4.2 mood last 7 days
-5.5 coupling from oxytocin, serotoninfrom synapsen import Profile, HormoneSpec, Coupling, DerivedState, check
profile = Profile(
name="workshop",
hormones={
"focus": HormoneSpec(baseline=50, decay=0.4, ceiling=200),
"restless": HormoneSpec(baseline=15, decay=0.9, ceiling=200),
},
couplings=[Coupling("restless", "focus", gain=-4.0, threshold=40)],
states=[DerivedState("CLEAR", {"focus": 1.0, "restless": -0.5},
valence="positive", description="able to work")],
events={"blockade": {"restless": +18, "focus": -8, "severity": -3}},
)
assert check(profile).okBundled are three deliberately very different profiles:
kira — five neurotransmitters, bonding, circadian rhythm. Not a starting guess: this profile emerged from months of continuous real-world agent operation with tens of thousands of logged state events. Use it as-is, or as a calibrated baseline for your own profile.
focus — two axes, no relationship. For a coding agent that gets audibly terser after the fifth red build.
pad — Pleasure–Arousal–Dominance, the academic standard model, expressed in this framework.
This lets arbitrary agents — across process and session boundaries — share the same state. Pure stdio JSON-RPC, no SDK needed.
{
"mcpServers": {
"synapsen": {
"command": "synapsen-mcp",
"args": ["--state", "~/.config/agent/state.json"]
}
}
}Tools: state_read, state_prompt, state_event, state_inject,
state_why, state_settle, state_history.
nix run github:Xarksus/synapsen -- doctor
nix develop # development environment with pytest and ruffThe flake provides packages.default, apps.mcp and a devShell.
SqliteJournal adapts to an existing schema rather than replacing it: it reads
the table's columns and writes what fits. An existing database with
emotional_log works unchanged. For a new journal,
SqliteJournal.for_profile(path, profile) creates the columns of the profile.
./verify.sh # tests, linter, all profiles checked — one commandOr individually:
pip install -e ".[dev]" # or: nix develop
pytest -q # 96 tests, ~1 s
ruff check .
python tools/make_assets.py # regenerate imagesApache-2.0.
Ein benanntes Ereignis melden. Der Zustand verändert sich daraufhin von selbst.
| Name | Required | Description | Default |
|---|---|---|---|
| event | Yes | ||
| context | No | Kurze Notiz, was konkret passiert ist. | |
| intensity | No | Multiplikator, üblicherweise 0.5–2.0. |
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.
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.
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.
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.
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.
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.
Die zuletzt protokollierten Ereignisse.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
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.
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.
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.
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.
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.
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.
Feinsteuerung: einen einzelnen Botenstoff verändern. Im Normalfall lieber state_event nutzen.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| context | No | ||
| hormone | Yes |
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.
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.
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.
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.
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.
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.
Derselbe Zustand als fertiger System-Prompt-Zusatz. Vor einer Antwort lesen und voranstellen.
| Name | Required | Description | Default |
|---|---|---|---|
| partner | No | Wie das Gegenüber genannt wird. | |
| language | No | de |
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.
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.
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.
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.
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.
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.
Aktueller innerer Zustand: Botenstoffe, abgeleitete Gefühlslagen, Bindung, Ermüdung.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Sanft Richtung Ruhewert regulieren. Kein harter Reset.
| Name | Required | Description | Default |
|---|---|---|---|
| fraction | No |
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.
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.
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.
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.
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.
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.
Führt den aktuellen Zustand auf seine Ursachen zurück: welche Ereignisse, welcher Tagesrhythmus, welche Kopplung. Für Fehlersuche und Nachvollziehbarkeit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent AI entity framework with causal memory, emotional state, and identity.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Shared long-term memory for AI agents: save and recall context as a searchable knowledge graph.
Biological memory for AI agents. Pattern learning, decay, clustering, 8-drive behavior.
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
