Palim

palim_save_context

Idempotent

Lightweight checkpoint: self-contained handoff, no transcript. Reuse session_id in this chat. Proactive after results and decisions, not only once.

Input Schema

TableJSON Schema

Name	Required	Description
`tags`	No	Optional search tags.
`title`	No	Chat title when visible.
`origin`	No	human (default) or automation (hooks/cron).
`status`	No	Optional status, e.g. laufend or abgeschlossen.
`context`	Yes	Handoff another AI can continue from: goal, state, constraints, next steps.
`project`	No	Optional project name.
`created_at`	No	Optional ISO 8601 chat date from the client.
`key_topics`	No	Main topics.
`open_items`	No	Open tasks.
`session_id`	No	Stable chat ID. Reuse it so checkpoints update one row. Claude Code/Codex: claude-code-<client session id>.
`source_urls`	No	Optional URLs.
`tool_source`	Yes	Client: cursor, claude, chatgpt, …
`continues_from`	No	Optional session_id from palim_resume that this chat continues.
`decisions_made`	No	Decisions in this chat.
`referenced_files`	No	Relevant files.
`resolved_open_items`	No	Previously open items that are now done; quote a leading fragment.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`message`	Yes	Human-readable tool result text.

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedAug 26, 2026

changedInput schema / properties / context / description

Previous value: -"Concise but self-contained handoff: goal, relevant background, work completed, current state, constraints, and next steps. Write it so another AI can continue without the transcript."New value: +"Handoff another AI can continue from: goal, state, constraints, next steps."

changedInput schema / properties / continues_from / description

Previous value: -"Optional. session_id of the thread this chat continues, as reported by palim_resume. Keep your own new session_id; this only records the link."New value: +"Optional session_id from palim_resume that this chat continues."

changedInput schema / properties / created_at / description

Previous value: -"Optional chat creation date from the AI client (ISO 8601)."New value: +"Optional ISO 8601 chat date from the client."

changedInput schema / properties / decisions_made / description

Previous value: -"Decisions reached in this chat."New value: +"Decisions in this chat."

changedInput schema / properties / key_topics / description

Previous value: -"Main topics covered."New value: +"Main topics."

changedInput schema / properties / open_items / description

Previous value: -"Remaining tasks or unresolved questions."New value: +"Open tasks."

changedInput schema / properties / origin / description

Previous value: -"Who produced this checkpoint. Use \"automation\" for scheduled routines, cron jobs and capture hooks — anything saved without a human in the loop. Defaults to \"human\". Automated saves are counted separately in palim_get_stats so they cannot be mistaken for real usage."New value: +"human (default) or automation (hooks/cron)."

changedInput schema / properties / referenced_files / description

Previous value: -"Relevant files or resources."New value: +"Relevant files."

changedInput schema / properties / resolved_open_items / description

Previous value: -"Open items from earlier sessions on this topic that are now DONE. Quote the wording of the item (a leading fragment is enough); it is moved out of Open Items into a dated Resolved section. Use this whenever a chat finishes something previously listed as open, otherwise the worklist keeps showing completed work."New value: +"Previously open items that are now done; quote a leading fragment."

changedInput schema / properties / session_id / description

Previous value: -"Stable chat ID, reused for every checkpoint in this chat so the record is updated instead of duplicated. In Claude Code / Codex use `claude-code-<the client session id>` — the Stop hook keeps that same row's live tail current, and sharing the ID keeps your handoff and that tail on one row. Otherwise reuse the ID returned by your first checkpoint in this chat."New value: +"Stable chat ID. Reuse it so checkpoints update one row. Claude Code/Codex: claude-code-<client session id>."

changedInput schema / properties / source_urls / description

Previous value: -"Optional chat URL and referenced URLs."New value: +"Optional URLs."

changedInput schema / properties / status / description

Previous value: -"Optional lifecycle status such as laufend or abgeschlossen."New value: +"Optional status, e.g. laufend or abgeschlossen."

changedInput schema / properties / title / description

Previous value: -"Exact chat title when visible. Omit if unavailable; Palim derives a short title from context."New value: +"Chat title when visible."

changedInput schema / properties / tool_source / description

Previous value: -"AI platform this chat originates from, for example codex, cursor, claude, chatgpt, gemini, perplexity, granola, or web."New value: +"Client: cursor, claude, chatgpt, …"

Changed1 schema field changedAug 6, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "message": {
+      "description": "Human-readable tool result text.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "message"
+  ],
+  "type": "object"
+}

First observedAug 6, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already provide idempotentHint=true and destructiveHint=false, and the description adds a useful behavioral boundary: this is a lightweight, no-transcript handoff rather than a full session snapshot. That adds context beyond the structured annotations, with no contradiction.

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 short sentences, each earning its place: what the tool is, how to key it, and when to run it. There is no filler, repetition, or schema echo.

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?

Given rich annotations, complete parameter schemas, and an output schema, the description provides enough operational guidance for a correct call. It could more explicitly distinguish this tool from palim_save_session or palim_checkpoint, but the essential checkpoint/handoff behavior and invocation cadence are present.

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%, so all 16 parameters are already documented. The description reinforces the session_id reuse concept and the handoff nature of context, but it does not add material format or composition detail beyond what the schema provides, so baseline 3 is appropriate.

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 identifies the tool as a lightweight checkpoint and self-contained handoff with no transcript, so an agent can infer it saves context for later continuation. It is clear but lacks an explicit verb phrase and does not differentiate it from the similarly named siblings like palim_checkpoint or palim_save_session, so it does not earn a 5.

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?

'Proactive after results and decisions, not only once' gives explicit timing guidance and tells the agent to call this repeatedly rather than only at the end. It says nothing about when not to use it or which sibling to prefer, but the stated cadence is a clear usage signal.

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

All Palim tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.