Palim
Server Details
Hosted MCP memory: save sessions/decisions once, search from Claude, Cursor, ChatGPT. EU-hosted FTS.
- Status
- Healthy
- Uptime
- 100.0% over 50 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- joleschmidt/palim-mcp-examples
- GitHub Stars
- 0
- Server Listing
- palim-mcp-examples
TDQS
Scored across 11 tools
Retrieval tools (get_brain, get_context, resume) are reasonably distinct, but palim_checkpoint, palim_save_context, and palim_save_session all revolve around persisting/checkpointing work, and the boundary between checkpoint and save_context is fuzzy despite descriptions. An agent could easily pick the wrong one when it just wants to record progress.
All names use a consistent palim_ snake_case prefix and are mostly verb_noun (add_memory, delete_session, save_session, get_brain). A few single-word exceptions (checkpoint, resume, help, search) deviate from the verb_noun pattern but remain readable and predictable.
11 tools sit comfortably in the well-scoped 3-15 range and map to a coherent memory/session lifecycle. Each tool appears to earn its place without obvious filler.
There is add/delete for memory and save/delete for session, plus search and retrieval, but no update/rename for memories and no list_memories. Notably, palim_save_session references palim_update_session_metadata and palim_update_session_references that are not in the tool set, creating dead-end references.
Available Tools
11 toolspalim_add_memoryCInspect
Store a memory, fact, decision, or preference for later retrieval.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Tags for categorization | |
| type | Yes | Type of memory | |
| content | Yes | Content of the memory | |
| metadata | No | Additional metadata | |
| source_session_id | No | Optional reference to source session |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | Human-readable tool result text. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, non-idempotent write operation. The description adds no extra behavior context such as duplicate creation risk, authentication needs, or that it creates a new memory each time. It neither contradicts annotations nor provides meaningful additional disclosure.
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?
A single, compact sentence with no wasted words. The key verb and object are front-loaded, making it appropriately concise for the stated purpose.
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 having an output schema and full parameter descriptions, the tool description is minimal. It omits mention of tags, metadata, idempotency, or when to use it relative to other memory tools. The phrase 'for later retrieval' gives some context, but the description relies heavily on the schema and annotations for essential detail.
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 100%, so baseline is 3. The description mentions 'fact, decision, or preference' which mirrors the enum values, but it does not add semantic meaning beyond the schema's property descriptions.
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 tool stores a memory, fact, decision, or preference with a specific verb and resource. It distinguishes from siblings like delete/update/search by implying creation, but it does not explicitly cite alternatives.
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 on when to use this tool versus alternatives like update_memory or search_memories. The description only states the action without prerequisites, exclusions, or context for choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
palim_checkpointBIdempotentInspect
Call after connecting AND again after each meaningful chunk of work. Claude Code: reuse claude-code-.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
| Name | Required | Description |
|---|---|---|
| message | Yes | Human-readable tool result text. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover idempotency (idempotentHint=true) and non-destructiveness (destructiveHint=false), so the bar is lower. The description adds that repeated calls are expected ('again after each meaningful chunk') and reinforces session-id reuse, which aligns with the session_id schema note about updating one row. It does not describe any additional side effects such as overwriting or storage behavior beyond what annotations and schema state.
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 short sentences, no filler, and the most important timing rule is front-loaded. However, the description is so terse that some purpose information is missing, which slightly lowers it from a perfect score.
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?
With 16 parameters and several sibling tools that likely handle saving/context, the description is too sparse to let an agent confidently choose this tool. It doesn't explain what a checkpoint is, how it relates to palim_save_session/palim_save_context, or what the output schema returns. The rich input schema compensates for parameters but not for the missing high-level semantics.
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 100%, so the baseline is 3. The description adds no parameter-level detail beyond the schema; the only specific hint, reusing claude-code-<client session id>, mirrors the session_id property description already present in the schema.
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 tells the agent when to call the tool ('after connecting AND again after each meaningful chunk of work') but never states what the tool does — e.g., that it saves or updates a checkpoint. 'Checkpoint' in the name and the schema imply persistence, but the description itself lacks an explicit verb+resource statement. It does not distinguish itself from siblings like palim_save_session or palim_save_context.
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 gives precise timing guidance: call after connecting and after each meaningful chunk of work. It also provides a client-specific rule for Claude Code: reuse claude-code-<client session id>. It does not mention alternatives or exclusions, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
palim_delete_memoryADestructiveIdempotentInspect
Permanently delete one stored memory by ID. Use for user-requested cleanup or deletion; this cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes | ID of the memory to permanently delete |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | Human-readable tool result text. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint and idempotentHint, so the description's main added value is the irreversibility warning: 'this cannot be undone.' This goes beyond the structured hints by clarifying the permanence of the deletion for the agent.
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 short sentences with no filler. The primary action and scope are front-loaded, followed by usage context and an important warning. Every sentence earns its place.
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 single-parameter destructive operation with output schema, annotations, and a clear irreversibility warning, the description is complete. An agent has everything it needs to invoke the tool correctly and understand the consequence.
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 100%, and the schema already explains 'ID of the memory to permanently delete.' The description adds no significant meaning beyond what the schema provides, so the baseline of 3 is appropriate.
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 a specific verb ('delete'), a specific resource ('one stored memory'), an identifier ('by ID'), and a distinguishing outcome ('Permanently'). It is easy to tell apart from the sibling delete_session because it names memory as the target.
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 says 'Use for user-requested cleanup or deletion', giving clear context for when the tool is appropriate. It does not explicitly exclude alternatives like palim_delete_session, but the memory-vs-session distinction is evident from the tool names and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
palim_delete_sessionADestructiveIdempotentInspect
Delete a chat session. Soft delete by default (reversible). Use hard_delete=true for permanent deletion.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session ID to delete | |
| hard_delete | No | If true, permanently deletes all data. Default: false (soft delete). |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | Human-readable tool result text. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds valuable context by explaining the soft delete default is reversible and hard delete is permanent, which goes beyond the annotation's simple destructive flag. This clarifies the reversibility of the 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 sentences, front-loaded with the core purpose, and every phrase adds value. It is concise and well-structured without unnecessary elaboration.
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 delete tool with two parameters, full schema coverage, and annotations, the description is complete. It explains the default behavior, the irreversible option, and implies the destructive nature. The output schema covers return values, so no further details are needed.
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 100%, so baseline is 3. The description mentions hard_delete=true for permanent deletion, which adds a bit of context but essentially mirrors the schema's parameter descriptions. No additional semantic depth is provided beyond what the schema already states.
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 tool deletes a chat session, using the specific verb 'delete' and resource 'chat session'. It also distinguishes between soft and hard deletion, which differentiates it from sibling delete tools like palim_delete_memory and palim_delete_user_rule by focusing on sessions.
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 clear guidance on when to use soft vs. hard delete ('Soft delete by default (reversible). Use hard_delete=true for permanent deletion.'). It does not explicitly name alternatives or exclusion criteria for other sibling tools, but the context is sufficient for a delete operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
palim_get_brainARead-onlyIdempotentInspect
Distilled knowledge profile. No args: recent topic index (capped). With topic: full document. Pass limit for a larger or full index.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max topics in the index (most recently updated first). Default 20 when omitted. Pass 0 for every topic. | |
| topic | No | Optional topic slug or name. When set, returns the full topic document instead of the index. |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | Human-readable tool result text. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so safety is covered. The description adds mode-dependent behavior (index vs full document and capped index), which is useful, but much of it is also reflected in the schema. No contradiction with annotations.
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?
Three short sentences with no redundant words. Each sentence conveys a distinct behavior: no args, with topic, and with limit, making the most important behavioral variation easy to scan.
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?
The tool has only two optional parameters and an output schema, and the description covers the core invocation patterns and result types. It is sufficiently complete for an agent to call the tool safely and interpret the output, even though error cases like unknown topics are not mentioned.
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 100%, so the baseline is 3. The description lightly reinforces how limit and topic change the result, but it does not add meaningful meaning beyond what the schema already provides.
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 explains the resource (distilled knowledge profile), the primary outputs (recent topic index vs full topic document), and the input mode that selects each. The behavior is clear enough to distinguish the tool from siblings like palim_search or palim_get_context, though no sibling is 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?
It gives operational guidance for no args, a topic, and a limit, but it does not explicitly state when to choose this tool over siblings such as palim_search or palim_get_context. The intended use is implied by 'distilled knowledge profile' rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
palim_get_contextARead-onlyIdempotentInspect
Get formatted context for a specific topic by searching and retrieving relevant sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Filter by metadata tags (match any). | |
| topic | Yes | Topic to get context for. | |
| status | No | Optional filter by metadata.status (e.g. "laufend", "abgeschlossen"). | |
| project | No | Optional filter by project | |
| max_sessions | No | Maximum number of sessions to include (default: 3) |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | Human-readable tool result text. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read operation. The description adds that it aggregates sessions via search and retrieval to produce formatted context, which is a useful behavioral trait. However, it does not disclose criteria for selecting sessions or what 'formatted' entails beyond what annotations already imply.
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 sentence that is front-loaded with the core action ('Get formatted context') and includes the key mechanism ('by searching and retrieving relevant sessions'). Every word contributes, with 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?
The presence of a detailed input schema and an output schema reduces the burden on the description. However, given the large set of sibling tools, the description does not clearly position when this tool should be preferred over similar retrieval tools like palim_find_similar or palim_get_sessions, leaving a completeness gap in tool selection guidance.
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 input schema provides descriptions for all 5 parameters, achieving 100% coverage, so the baseline is 3. The description 'specific topic' loosely maps to the required 'topic' parameter, but it adds no new semantic details about filtering, defaults, or interactions between parameters.
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 'Get' and identifies the resource as 'formatted context for a specific topic', while explaining the mechanism of searching and retrieving relevant sessions. It is clear and distinct from mere session listing, but it does not explicitly contrast with sibling tools like palim_search or palim_get_sessions.
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 intended use for retrieving topic-specific context is implied, but there is no explicit guidance on when to use this tool versus alternatives such as palim_search or palim_get_user_context. No exclusions or preference conditions are given, so the agent must infer the right context from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
palim_helpARead-onlyIdempotentInspect
Show an overview of all available Palim tools and usage instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category. Default: all. |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | Human-readable tool result text. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing this as a safe, read-only help operation. The description adds no extra behavioral context beyond restating the purpose, so it adds limited value beyond the annotations.
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, concise sentence that delivers the essential purpose without any filler or redundant phrasing. It is front-loaded and earns its place with no wasted words.
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 help tool with one optional parameter, a complete schema, and rich annotations, the description is sufficiently complete. It explains the tool's purpose and output (overview and instructions), and the output schema (present) can provide any return-value details.
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 covers 100% of the parameter (category) with a clear enum and description, so the description does not need to add parameter details. The description doesn't mention the category parameter, but the schema fully handles it, placing this at the baseline for high schema coverage.
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 ('Show') and resource ('all available Palim tools and usage instructions'), making the tool's purpose immediately clear. It is distinct from sibling tools, which perform operations on data rather than providing help.
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 clearly implies this tool is for getting an overview and usage instructions, which is the right context for a help command. It doesn't explicitly name alternatives or exclusions, but given its unique role among the sibling tools, the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
palim_resumeARead-onlyIdempotentInspect
Continue the user's most recent Palim thread. Call first in a new chat, no args. Ignore the result if it is unrelated. Project filter is case-insensitive and returns the most recently updated match.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Optional: only consider threads belonging to this project (case-insensitive; Logisoft ≡ logisoft). | |
| tool_source | No | Optional: only consider threads from one client (cursor, claude, codex, chatgpt, ...). | |
| within_hours | No | Optional: ignore threads older than this many hours. Omit to always return the latest thread. | |
| include_messages | No | Optional: append the tail of the transcript when the thread has stored messages. Default false. |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | Human-readable tool result text. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnly, idempotent, and non-destructive behavior, so the description does not need to restate them. It adds useful nuance: the result may be unrelated and should be ignored, and project matching is case-insensitive and returns the most recently updated match. This adds value but no deeper behavioral detail.
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?
Four short sentences carry distinct, useful guidance with no filler. The main purpose is front-loaded, followed by call timing and behavioral caveats. Every sentence earns its place.
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 output schema, annotations, and full parameter descriptions, the tool is well documented. The description covers invocation timing and result handling, while schema covers parameter details. It is complete enough for an agent to call correctly on first attempt.
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 100%, so all four parameters are individually documented. The description reinforces the project parameter's case-insensitive behavior and the default no-args call pattern, but adds little beyond what the schema already provides. Baseline 3 applies.
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?
Description states a specific verb ('Continue') and resource ('user's most recent Palim thread'), making the tool's role immediately clear. It also distinguishes this from sibling tools such as palim_search and palim_save_session, so agents can select it without opening schemas.
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?
Gives explicit invocation guidance: call first in a new chat with no args, and tells the agent to ignore unrelated results. It does not explicitly name alternatives or when-not-to-use, but the contextual cue is strong enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
palim_save_contextAIdempotentInspect
Lightweight checkpoint: self-contained handoff, no transcript. Reuse session_id in this chat. Proactive after results and decisions, not only once.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
| Name | Required | Description |
|---|---|---|
| message | Yes | Human-readable tool result text. |
TDQS
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.
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.
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.
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.
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.
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.
palim_save_sessionADestructiveInspect
Save or append a full chat transcript (messages + summary). Exclude children's personal data under 16/higher consent age, HIPAA PHI, PCI payment card data, and adult content; request redaction before saving. Prefer palim_save_context for compact handoffs. For metadata-only or URL updates use palim_update_session_metadata / palim_update_session_references. When appending: reuse session_id + title, fetch existing messages first, send only new ones. Always pass a complete summary and metadata.tool_source.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Session title. Reuse across saves; else the exact chat title from the client UI. | |
| summary | No | Full-conversation summary. Required arrays may be empty. | |
| messages | Yes | Messages to save (role + content). When appending, only unsaved messages. | |
| metadata | No | Session metadata. tool_source is required. | |
| overwrite | No | Replace all existing messages instead of appending. Default: false. | |
| created_at | No | Optional ISO 8601 creation date from the AI client (new sessions only). | |
| session_id | No | Session id. Reuse across saves in this chat; else from chat URL or a new UUID. |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | Human-readable tool result text. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, non-idempotent, non-read-only, so the safety profile is covered. The description still adds real value the annotations do not: data-handling exclusions (minors, PHI, PCI, adult content), the instruction to request redaction before saving, and the append-vs-replace workflow. It does not spell out the consequence of overwrite=true, but that is documented in the schema.
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?
Front-loaded with the core purpose, then routing, then compliance, then append mechanics. Every sentence carries actionable information with no filler; it is dense but not padded.
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 a 7-parameter nested schema with 100% coverage, annotations, and a declared output schema, this description supplies the remaining pieces an agent needs: compliance exclusions, the sibling it should prefer, and the exact append workflow. Nothing required to invoke it correctly is missing.
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 100% and nested objects are fully documented, so the baseline is 3. The description reinforces that summary and metadata.tool_source must always be complete and hints at session_id/title reuse, but adds little beyond what the schema already specifies for each field.
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 opening sentence states a specific verb and resource — save or append a full chat transcript (messages + summary) — and immediately distinguishes the operation from siblings by naming palim_save_context and the two update tools. An agent can tell exactly what this tool writes and what it does not.
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?
Explicit routing rules are given: prefer palim_save_context for compact handoffs, use palim_update_session_metadata / palim_update_session_references for metadata-only or URL updates. It also gives the concrete append procedure (reuse session_id + title, fetch existing messages first, send only new ones), which is unambiguous when-to-use/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
palim_searchARead-onlyIdempotentInspect
Search saved sessions and memories. Query matches session text or memory content/id. Supports metadata filtering via tags/project/status/tool_source. Omit query for tags-only or project-only session filtering. Project match is case-insensitive.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Filter by metadata tags (match any). | |
| limit | No | Maximum number of results (default: 5) | |
| query | No | Full-text search query. Omit for tags-only or project-only filtering. | |
| status | No | Optional filter by metadata.status (e.g. "laufend", "abgeschlossen", "referenz", "archiviert"). | |
| project | No | Optional case-insensitive project filter (Logisoft ≡ logisoft). Allowed without query or tags. | |
| tool_source | No | Optional explicit filter by tool source (cursor, claude, chatgpt, web, etc.). |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | Human-readable tool result text. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavior beyond that: what gets searched, that query matches both session text and memory content/id, that metadata filtering is supported, and that project matching is case-insensitive. This gives the agent useful behavioral context without contradicting annotations.
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?
Three sentences with no filler. The main purpose is front-loaded, followed by matching semantics and practical usage guidance. Every sentence earns its place.
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 read-only search tool with zero required parameters, an output schema, and full schema description coverage, this description is complete. It covers the search domain, matching behavior, filter options, and special usage cases. The agent has everything needed to invoke it correctly.
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 100%, so the baseline is 3. The description adds value beyond the schema by explaining the query's matching scope, the relationship between query omission and tag/project filtering, and the case-insensitivity of project matching. This clarifies parameter combinations that the schema alone does not convey.
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 opens with a specific verb and resource: 'Search saved sessions and memories.' It further clarifies what is matched ('session text or memory content/id') and enumerates filter dimensions, making the tool's purpose unmistakable and distinct from the sibling tools.
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 gives clear usage context: query for full-text search, omit query for tags-only or project-only filtering, and notes case-insensitive project matching. It does not explicitly name alternatives or state when not to use this tool, but the intended invocation patterns are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Added
palim_delete_memory
2 tool updates
- Changed
palim_resume1 field changed- changed
Input schema / properties / project / descriptionPrevious value: -"Optional: only consider threads belonging to this project."New value: +"Optional: only consider threads belonging to this project (case-insensitive; Logisoft ≡ logisoft)."
- Changed
palim_search2 fields changed- changed
Input schema / properties / project / descriptionPrevious value: -"Optional filter by project"New value: +"Optional case-insensitive project filter (Logisoft ≡ logisoft). Allowed without query or tags." - changed
Input schema / properties / query / descriptionPrevious value: -"Full-text search query. Omit for tags-only filtering."New value: +"Full-text search query. Omit for tags-only or project-only filtering."
1 tool update
- Added
palim_checkpoint
3 tool updates
- Added
palim_delete_session - Removed
palim_preview_session_tag_cleanup - Added
palim_save_session
1 tool update
- Changed
palim_get_brain1 field changed- added
Input schema / properties / limitAdded value: +{ + "description": "Max topics in the index (most recently updated first). Default 20 when omitted. Pass 0 for every topic.", + "type": "number" +}
2 tool updates
- Removed
palim_delete_session - Added
palim_preview_session_tag_cleanup
38 tool updates
- Removed
palim_add_user_rule - Removed
palim_backfill_blind_index - Removed
palim_backfill_brain - Removed
palim_browse_sessions - Removed
palim_clean_session_tags - Removed
palim_create_connection_url - Removed
palim_create_summary - Removed
palim_delete_memory - Removed
palim_delete_user_rule - Removed
palim_export_brain - Removed
palim_export_session - Removed
palim_find_similar - Removed
palim_get_session - Removed
palim_get_sessions - Removed
palim_get_stats - Removed
palim_get_summary - Removed
palim_get_user_context - Removed
palim_get_user_profile - Removed
palim_list_sessions - Removed
palim_list_summaries - Removed
palim_list_user_rules - Removed
palim_login - Removed
palim_logout - Removed
palim_migrate_encryption - Removed
palim_register - Removed
palim_repair_brain_hooks - Changed
palim_save_context14 fields changed- changed
Input schema / properties / context / descriptionPrevious 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." - changed
Input schema / properties / continues_from / descriptionPrevious 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." - changed
Input schema / properties / created_at / descriptionPrevious value: -"Optional chat creation date from the AI client (ISO 8601)."New value: +"Optional ISO 8601 chat date from the client." - changed
Input schema / properties / decisions_made / descriptionPrevious value: -"Decisions reached in this chat."New value: +"Decisions in this chat." - changed
Input schema / properties / key_topics / descriptionPrevious value: -"Main topics covered."New value: +"Main topics." - changed
Input schema / properties / open_items / descriptionPrevious value: -"Remaining tasks or unresolved questions."New value: +"Open tasks." - changed
Input schema / properties / origin / descriptionPrevious 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)." - changed
Input schema / properties / referenced_files / descriptionPrevious value: -"Relevant files or resources."New value: +"Relevant files." - changed
Input schema / properties / resolved_open_items / descriptionPrevious 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." - changed
Input schema / properties / session_id / descriptionPrevious 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>." - changed
Input schema / properties / source_urls / descriptionPrevious value: -"Optional chat URL and referenced URLs."New value: +"Optional URLs." - changed
Input schema / properties / status / descriptionPrevious value: -"Optional lifecycle status such as laufend or abgeschlossen."New value: +"Optional status, e.g. laufend or abgeschlossen." - changed
Input schema / properties / title / descriptionPrevious value: -"Exact chat title when visible. Omit if unavailable; Palim derives a short title from context."New value: +"Chat title when visible." - changed
Input schema / properties / tool_source / descriptionPrevious value: -"AI platform this chat originates from, for example codex, cursor, claude, chatgpt, gemini, perplexity, granola, or web."New value: +"Client: cursor, claude, chatgpt, …"
- Removed
palim_save_session - Removed
palim_search_by_date_range - Removed
palim_search_memories - Removed
palim_set_user_context - Removed
palim_show_session - Removed
palim_update_brain_topic - Removed
palim_update_memory - Removed
palim_update_session_metadata - Removed
palim_update_session_references - Removed
palim_update_user_profile - Removed
palim_update_user_rule
45 tool updates
- Changed
palim_add_memory1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_add_user_rule1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_backfill_blind_index1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_backfill_brain1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_browse_sessions1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_clean_session_tags1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_create_connection_url1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_create_summary1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_delete_memory1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_delete_session1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_delete_user_rule1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_export_brain1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_export_session1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_find_similar1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_get_brain1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_get_context1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_get_session1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_get_sessions1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_get_stats1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_get_summary1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_get_user_context1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_get_user_profile1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_help1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_list_sessions1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_list_summaries1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_list_user_rules1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_login1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_logout1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_migrate_encryption1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_register1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_repair_brain_hooks1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_resume1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_save_context1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_save_session1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_search1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_search_by_date_range1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_search_memories1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_set_user_context1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_show_session1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_update_brain_topic1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_update_memory1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_update_session_metadata1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_update_session_references1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_update_user_profile1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
- Changed
palim_update_user_rule1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "message": { + "description": "Human-readable tool result text.", + "type": "string" + } + }, + "required": [ + "message" + ], + "type": "object" +}
45 tool updates
- First observed
palim_add_memory - First observed
palim_add_user_rule - First observed
palim_backfill_blind_index - First observed
palim_backfill_brain - First observed
palim_browse_sessions - First observed
palim_clean_session_tags - First observed
palim_create_connection_url - First observed
palim_create_summary - First observed
palim_delete_memory - First observed
palim_delete_session - First observed
palim_delete_user_rule - First observed
palim_export_brain - First observed
palim_export_session - First observed
palim_find_similar - First observed
palim_get_brain - First observed
palim_get_context - First observed
palim_get_session - First observed
palim_get_sessions - First observed
palim_get_stats - First observed
palim_get_summary - First observed
palim_get_user_context - First observed
palim_get_user_profile - First observed
palim_help - First observed
palim_list_sessions - First observed
palim_list_summaries - First observed
palim_list_user_rules - First observed
palim_login - First observed
palim_logout - First observed
palim_migrate_encryption - First observed
palim_register - First observed
palim_repair_brain_hooks - First observed
palim_resume - First observed
palim_save_context - First observed
palim_save_session - First observed
palim_search - First observed
palim_search_by_date_range - First observed
palim_search_memories - First observed
palim_set_user_context - First observed
palim_show_session - First observed
palim_update_brain_topic - First observed
palim_update_memory - First observed
palim_update_session_metadata - First observed
palim_update_session_references - First observed
palim_update_user_profile - First observed
palim_update_user_rule
Related MCP Connectors
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
- mcpOAuthai.butlerbrain
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
- ContexelOAuthai.contexel
Shared AI memory. ChatGPT, Claude, Cursor and any MCP app read and write the same memory.
Hosted MCP memory for coding agents: persistent across sessions, editable markdown, team sharing.
Related MCP Servers
- AlicenseAqualityDmaintenancePersistent memory API for AI agents — store, recall, and inject semantically-searchable context across sessions. EU-hosted, GDPR-compliant. Supports Claude, Cursor, Cline, and any MCP-compatible client.42MIT
- AlicenseAqualityAmaintenancePersistent AI memory for Claude Code, Cursor, GitHub Copilot & Windsurf — sessions, lessons learned, semantic search, and team brain. 38 MCP tools. Free tier, EU servers.122300 npm2Apache 2.0
- AlicenseAqualityDmaintenanceMCP server for persistent, semantic memory across AI sessions; store context, decisions, and learnings and recall them with natural language search.221 npmMIT
- AlicenseNot gradedqualityDmaintenanceSelf-hosted semantic memory for AI agents. Save worklogs, decisions, and notes via MCP, then recall them across sessions by meaning rather than keyword. Backed by Postgres + pgvector with local embeddings (multilingual-e5-base).1MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.