Skip to main content
Glama
Sign In
Spacepal MCP Server

Spacepal MCP Server

by TanKucukhas
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Save sessions

save_sessions
Idempotent

Save terminal windows with their folders and Chrome windows with their tabs on one Space or all Spaces, so restore_sessions can reopen them in the right place after a restart.

Instructions

Save the terminal windows (with their folders) and Chrome windows (with their tabs) on one Space, or on every Space with all=true, so restore_sessions can reopen them on the right Space after a restart. Replaces the earlier save for those Spaces and drops windows that were closed. Needs Spacepal's trial or a license; without one nothing is saved.

Input Schema

NameRequiredDescriptionDefault
allNotrue to save every Space; then space is ignored. Default false.
spaceNoWhich Space: desktop number or name from list_spaces. Leave it out for the Space the user is on now.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.2.3
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / space / anyOf
      Previous value: -[
-  {
-    "exclusiveMinimum": 0,
-    "type": "integer"
-  },
-  {
-    "minLength": 1,
-    "type": "string"
-  }
-]New value: +[
+  {
+    "exclusiveMinimum": 0,
+    "maximum": 9007199254740991,
+    "type": "integer"
+  },
+  {
+    "minLength": 1,
+    "type": "string"
+  }
+]
  2. Changed2 schema fields changedv0.2.2
    • changedInput schema / properties / all / description
      Previous value: -"Save every Space instead of one."New value: +"true to save every Space; then space is ignored. Default false."
    • changedInput schema / properties / space / description
      Previous value: -"Desktop number (1, 2, ...) or Space name, e.g. \"Mail\"."New value: +"Which Space: desktop number or name from list_spaces. Leave it out for the Space the user is on now."
  3. Addedv0.2.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), it discloses replace semantics — the prior save for those Spaces is overwritten — and that closed windows are dropped rather than persisted. It also surfaces a licensing gate (trial or license required, otherwise nothing is saved), which is a failure mode the annotations cannot express.

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?

Three sentences, each doing distinct work: what is saved and where, what it replaces and pairs with, and the licensing constraint. Scope and the all=true switch are front-loaded with no redundant phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter, non-required-argument tool with no output schema, the description covers scope, replacement behavior, the restore counterpart, and the licensing precondition. An agent has enough to call it correctly and to explain a no-op outcome.

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 description coverage is 100%, and the schema already explains that all=true makes space ignored and that space accepts a desktop number or name. The description restates the all=true case without adding format or edge-case detail beyond the schema, so the baseline of 3 applies.

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 names a specific verb (save) and the exact resources captured — terminal windows with folders and Chrome windows with tabs — plus the scoping options (one Space, or all Spaces with all=true). It also pairs the action with the sibling that consumes it (restore_sessions), so an agent can place it immediately.

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?

It states the condition for use (so restore_sessions can reopen windows on the right Space after a restart) and the condition that switches to every Space (all=true). It does not, however, distinguish this from the sibling save_window_layout, leaving the agent to infer which save tool to pick.

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