Skip to main content
Glama
Sign In
UnClick MCP Server

UnClick MCP Server

by malamutemayhem
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Save this session

save_session

Saves a structured session summary so the next session can resume without re-asking, capturing accomplishments, key decisions, open loops, and durable facts.

Instructions

Saves a structured summary of the current session so the next session can resume without re-asking. Use at the end of every meaningful session -- even if the user doesn't ask: 'summary', 'wrap-up', 'end of session', 'recap', 'we're done', 'see you next time', 'close out', or whenever significant work was completed, decisions were made, or open loops exist that need carrying forward. Also trigger at natural checkpoints mid-session when a major phase completes. Include: what was accomplished, key decisions made, open loops or next steps. Do NOT trigger after trivial exchanges (single Q&A, quick lookups) with nothing worth carrying forward. Do NOT trigger if the session has already been saved with no new work done since. ALSO extract durable facts here: pass facts:[{text, kind}] with the atomic facts this session surfaced (preferences, decisions, corrections, durable project details) so memory forms in the same call even when no save_fact calls were made along the way.

Input Schema

NameRequiredDescriptionDefault
factsNoAtomic durable facts learned this session (max 20). One clause each; skip transient status. Each lands as a normal memory fact via the write gate, linked to this session.
topicsNoTopic tags for searchability
summaryYesNarrative of what happened: decisions, work completed, problems solved
platformNoPlatform this session ran onclaude-code
decisionsNoKey decisions made during the session
open_loopsNoUnfinished tasks or questions to carry forward
session_idYesUnique session identifier (timestamp or UUID)
duration_minutesNoApproximate session duration

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.11
    • addedInput schema / properties / facts
      Added value: +{
+  "description": "Atomic durable facts learned this session (max 20). One clause each; skip transient status. Each lands as a normal memory fact via the write gate, linked to this session.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "kind": {
+        "description": "Temporal bucket for the fact",
+        "enum": [
+          "current",
+          "historical",
+          "future",
+          "preference",
+          "timeless"
+        ],
+        "type": "string"
+      },
+      "text": {
+        "description": "One atomic, durable fact",
+        "type": "string"
+      }
+    },
+    "required": [
+      "text"
+    ],
+    "type": "object"
+  },
+  "maxItems": 20,
+  "type": "array"
+}
  2. Addedv0.1.5

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag write (readOnlyHint=false) and non-idempotent behavior; the description adds the meaningful fact that facts submitted here land as normal memory facts 'via the write gate' linked to the session — a non-obvious side effect. The 'do not re-save with no new work' line also usefully signals the non-idempotent cost. Missing is what the call returns (e.g., which facts were accepted or rejected by the gate).

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 core action is front-loaded in the first sentence and the trigger list is functional rather than filler. It is dense and fairly long, and the long enumerated phrase list plus the trailing 'ALSO extract durable facts' clause push it past what most readers need in one pass, but no sentence is purely redundant.

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 an 8-parameter write tool with no output schema, the description covers the critical decisions (when to call, what to put in the summary, whether to attach facts). It leaves the secondary parameters (topics, platform, duration_minutes) and the return behavior undescribed, which is a real but minor gap given 100% schema coverage.

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?

Schema coverage is 100%, so 3 is the floor. The description still adds value by explaining the facts payload semantics — atomic facts, the {text, kind} shape, and why to include them (so memory forms in the same call even without prior save_fact calls) — and by enumerating the content that belongs in summary/decisions/open_loops. Topics, platform, and duration_minutes go unmentioned, keeping it from a 5.

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?

States a specific verb and resource — 'Saves a structured summary of the current session' — plus the outcome it enables ('so the next session can resume without re-asking'). That distinguishes it cleanly from save_fact (single fact), save_conversation_turn (raw turn capture), and save_identity (profile data).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly enumerates trigger phrases ('summary', 'wrap-up', 'recap', 'we're done'), a mid-session checkpoint case, and two negative conditions: no trivial exchanges, no re-save when nothing new happened. This is the full when/when-not pattern, not an inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools