This server enables seamless transfer and management of conversation context between different AI chats, AI systems (Claude, ChatGPT, etc.), or projects within the same AI.
Core Features:
Save conversations - Store full conversation context with auto-generated keys and titles, summaries, and metadata
List saved handoffs - View lightweight summaries of all saved conversations without loading full content
Load conversations - Retrieve full conversation content by key with optional message limiting
Clear data - Delete specific handoffs by key or clear all saved conversations
Monitor storage - Check usage statistics and configured limits
Technical Capabilities:
Auto-connect sharing - Automatically shares handoffs across multiple MCP clients (Claude Desktop, Claude Code, etc.) via background HTTP server
Auto-reconnection - Seamlessly recovers when server goes down without manual intervention
Memory-based storage - Lightweight temporary storage with FIFO auto-cleanup when limits reached (no disk writes)
Flexible configuration - Customize storage limits, connection settings, and server behavior via environment variables
Human-readable format - Uses standard Markdown format (## User / ## Assistant) for conversation storage
Uses Markdown as the common format for saving and loading conversation contexts, ensuring that handoffs between AI sessions are human-readable and preserve structure such as user and assistant roles.
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., "@Conversation Handoff MCP save our discussion about the API design for later review"
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.
MCP server for transferring conversation context between AI chats or different projects within the same AI.
Tags & Search (v0.12.0+): Tag handoffs with structured labels (project:foo, issue:176) and discover them with handoff_search — multi-criteria filtering by tags, text, project, AI, status, and date range
Handoff Metadata (v0.11.0+): Enrich handoff_list with message count, size, status, and next action — decide on work resumption without loading full conversations
Comments/Annotations (v0.10.0+): Add notes and annotations to handoffs for cross-session context
Server Restart (v0.9.0+): Restart the shared HTTP server from any MCP client — useful after package updates
Audit Logging (v0.7.0+): Optional structured JSONL logging for diagnostics (--audit flag)
Verbatim Conversation Saving (v0.6.1+): AI saves complete conversations without summarization or abbreviation
Merge Handoffs (v0.6.0+): Combine multiple related handoffs into one unified context
MCP Apps UI (v0.5.0+): Interactive UI for browsing and managing handoffs on compatible clients
Auto-Connect (v0.4.0+): Server automatically starts in the background - no manual setup required
Auto-Reconnection (v0.4.0+): Seamlessly reconnects when server goes down - no manual intervention needed
Memory-Based Storage: Lightweight temporary clipboard design - no files written to disk
Common Format: Human-readable Markdown format
Lightweight API: Returns only summaries when listing to save context
Auto-Generated Keys (v0.4.0+): Key and title are now optional in handoff_save
Related MCP server: Pensieve MCP Server
Works with Claude Desktop, Claude Code, Codex CLI, Gemini CLI, and other MCP clients.
Client | Config File |
Claude Desktop (macOS) |
|
Claude Desktop (Windows) |
|
Claude Code |
|
Codex CLI |
|
Gemini CLI |
|
Cursor |
|
ChatGPT Desktop | In-app settings (Developer Mode) |
No pre-installation required - runs via npx.
{
"mcpServers": {
"conversation-handoff": {
"command": "npx",
"args": ["conversation-handoff-mcp@latest"]
}
}
}For global installation:
npm install -g conversation-handoff-mcpgit clone https://github.com/trust-delta/conversation-handoff-mcp.git
cd conversation-handoff-mcp
npm install
npm run buildMCP configuration:
{
"mcpServers": {
"conversation-handoff": {
"command": "node",
"args": ["/path/to/conversation-handoff-mcp/dist/index.js"]
}
}
}Note: Codex CLI uses TOML format. See Codex MCP documentation for details.
Save conversation context. Key and title are auto-generated if omitted (v0.4.0+). The conversation field stores the complete verbatim content — AI is instructed not to summarize or abbreviate messages (v0.6.1+).
// With explicit key and title
handoff_save(
key: "project-design",
title: "Project Design Discussion",
summary: "Decided on MCP server design approach",
conversation: "## User\nQuestion...\n\n## Assistant\nAnswer..."
)
// Auto-generated key and title (v0.4.0+)
handoff_save(
summary: "Decided on MCP server design approach",
conversation: "## User\nQuestion...\n\n## Assistant\nAnswer..."
)
// → key: "handoff-20241208-143052-abc123" (timestamp + random)
// → title: "Decided on MCP server design approach" (from summary)Get list of saved handoffs (summaries only).
handoff_list()Load full content of a specific handoff.
handoff_load(key: "project-design")
handoff_load(key: "project-design", max_messages: 10) // Last 10 messages onlyDelete handoffs.
handoff_clear(key: "project-design") // Specific key
handoff_clear() // Clear allMerge multiple related handoffs into one. Useful for combining discussions from separate sessions.
// Merge two handoffs (chronological order by default)
handoff_merge(keys: ["session-1", "session-2"])
// With custom key and delete sources
handoff_merge(
keys: ["design-v1", "design-v2", "design-v3"],
new_key: "design-final",
new_title: "Final Design Document",
delete_sources: true,
strategy: "sequential"
)Parameter | Required | Default | Description |
| Yes | - | Array of handoff keys to merge (min 2) |
| No | auto | Key for merged handoff |
| No | auto | Title for merged handoff |
| No | auto | Summary for merged handoff |
| No |
| Delete source handoffs after merge |
| No |
|
|
Check storage usage and limits.
handoff_stats()For MCP Apps-compatible clients, handoff_list automatically opens an interactive UI. Non-compatible clients receive the standard JSON response.
List View: Card-based list showing title, source AI, and date
Detail View: Expandable cards showing summary and conversation (parsed as User/Assistant messages)
Load (v0.5.2+): Insert handoff content into chat to continue conversation
Delete: Remove handoffs directly from UI
Note: According to the MCP Apps specification,
sendMessageshould add messages directly to the conversation and trigger a model response. However, Claude Desktop's current implementation inserts the message into the chat input field instead, requiring the user to press Enter. When you click "Load", the handoff content will be inserted into the input field - press Enter to send it to Claude. This behavior is expected to improve in future Claude Desktop updates.
Starting with v0.4.0, the server automatically starts in the background when an MCP client connects. No manual setup required!
[User launches Claude Desktop]
→ MCP client starts
→ Scans ports 1099-1200 in parallel for existing server
→ If no server found: auto-starts one in background
→ Connects to server
→ (User notices nothing - it just works!)
[User launches Claude Code later]
→ MCP client starts
→ Scans ports 1099-1200 in parallel
→ Finds existing server
→ Connects to same server
→ Handoffs are shared!Mode | When | Behavior |
Auto-Connect (default) | No | Discovers or auto-starts server |
Explicit Server |
| Connects to specified URL |
Standalone |
| No server, in-memory only |
Handoff data is stored in memory only:
Data is shared across all connected MCP clients via the HTTP server
Data is lost when the server process stops
No files are written to disk - lightweight and clean
Perfect for temporary context sharing during active sessions
FIFO Auto-Cleanup: When limit is reached, oldest handoff is automatically deleted (no errors)
When the shared server goes down during operation:
[Server stops unexpectedly]
→ User calls handoff_save()
→ Request fails (connection refused)
→ Auto-reconnection kicks in:
→ Rescan ports 1099-1200 for existing server
→ If found: connect to it
→ If not found: start new server in background
→ Retry the original request
→ User sees success (transparent recovery!)Configurable retry limit via HANDOFF_RETRY_COUNT (default: 30)
On final failure: outputs pending content for manual recovery
Other MCP clients automatically discover the new server on their next request
The server automatically shuts down after a period of inactivity:
Default: 24 hours of no requests
Configurable via HANDOFF_SERVER_TTL environment variable
Set to 0 to disable auto-shutdown
Next MCP client request will auto-start a new server
Standard configuration (recommended) - Just works with auto-connect:
{
"mcpServers": {
"conversation-handoff": {
"command": "npx",
"args": ["conversation-handoff-mcp@latest"]
}
}
}Specify custom server:
{
"mcpServers": {
"conversation-handoff": {
"command": "npx",
"args": ["conversation-handoff-mcp@latest"],
"env": {
"HANDOFF_SERVER": "http://localhost:3000"
}
}
}
}Force standalone mode (no server):
For Claude Desktop only. Claude Desktop cannot transfer conversations between projects by default, but since it shares memory space as a single app, this MCP server enables handoffs between projects. Claude Code and CLI tools run as separate processes per tab/session, so handoffs don't work in this mode.
{
"mcpServers": {
"conversation-handoff": {
"command": "npx",
"args": ["conversation-handoff-mcp@latest"],
"env": {
"HANDOFF_SERVER": "none"
}
}
}
}If you prefer manual control:
# Default port (1099)
npx conversation-handoff-mcp --serve
# Custom port
npx conversation-handoff-mcp --serve --port 3000Method | Path | Description |
POST | /handoff | Save a handoff |
POST | /handoff/merge | Merge multiple handoffs |
GET | /handoff | List all handoffs |
GET | /handoff/:key | Load a specific handoff |
DELETE | /handoff/:key | Delete a specific handoff |
DELETE | /handoff | Delete all handoffs |
GET | /stats | Get storage statistics |
GET | / | Health check |
Scenario: Design discussion in Claude Desktop → Implementation in Claude Code
In Claude Desktop - Have a design discussion:
User: Let's design an authentication system for my app.
Assistant: I recommend using JWT with refresh tokens...
[detailed discussion continues]Save the conversation - When ready to hand off:
User: Save this conversation for implementation in Claude Code.
Assistant: (calls handoff_save)
✅ Handoff saved with key: "auth-design-20241208"In Claude Code - Load and continue:
User: Load the auth design discussion.
Assistant: (calls handoff_load)
# Handoff: Authentication System Design
[Full conversation context loaded]
I see we discussed JWT with refresh tokens. Let me implement that...Key Points:
The AI automatically formats and saves the conversation
Context is fully preserved including code snippets and decisions
No manual copy-paste needed
Note: The server automatically starts in the background when the first MCP client connects. No manual startup required.
Customize behavior via environment variables.
Variable | Default | Description |
| (auto) |
|
|
| Port range for auto-discovery |
| 30 | Auto-reconnect retry count |
| 10000 | Auto-reconnect interval (ms) |
| 86400000 (24h) | Server auto-shutdown after inactivity (0 = disabled) |
| (disabled) |
|
Variable | Default | Description |
| 100 | Maximum number of handoffs |
| 1048576 (1MB) | Maximum conversation size |
| 10240 (10KB) | Maximum summary size |
| 200 | Maximum title length |
| 100 | Maximum key length |
{
"mcpServers": {
"conversation-handoff": {
"command": "npx",
"args": ["conversation-handoff-mcp@latest"],
"env": {
"HANDOFF_MAX_COUNT": "50",
"HANDOFF_MAX_CONVERSATION_BYTES": "524288"
}
}
}
}## User
User's message
## Assistant
AI's responseThe handoff_load output includes security markers to protect against prompt injection attacks:
Warning banner: Alerts AI that content is user-provided and untrusted
Code blocks: User content is wrapped in code blocks to prevent interpretation as instructions
End marker: Clear boundary marking end of user content
This prevents malicious content stored in handoffs from being interpreted as AI instructions.
MIT
trust-delta
Clear handoffs. If key is provided, clears only that handoff. Otherwise clears all.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Optional: specific handoff key to clear |
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 mentions the action ('clear') but doesn't specify whether this is destructive, reversible, requires permissions, or has side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency about its behavior and impact.
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 extremely concise with two sentences that directly address functionality and parameter usage. Every word earns its place, and it's front-loaded with the core action. There's no wasted text, making it efficient and easy to parse.
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 complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'clear' entails (e.g., deletion, reset, or archival), potential consequences, or return values. For a tool that modifies data, this lack of context makes it inadequate for safe and informed use.
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%, with the parameter 'key' documented as 'Optional: specific handoff key to clear.' The description adds minimal value by restating that if key is provided, it clears only that handoff; otherwise, it clears all. This aligns with the schema but doesn't provide additional meaning or examples, so it meets 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 clearly states the verb ('clear') and resource ('handoffs'), specifying what the tool does. It distinguishes between clearing a specific handoff versus all handoffs, which provides operational clarity. However, it doesn't explicitly differentiate from sibling tools like handoff_list or handoff_restart, which prevents a perfect score.
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 implies usage by stating 'If key is provided, clears only that handoff. Otherwise clears all,' which gives some context on when to use different parameter configurations. However, it lacks explicit guidance on when to use this tool versus alternatives like handoff_restart or handoff_merge, and doesn't mention prerequisites or exclusions, leaving gaps in decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all saved handoffs with summaries. Returns lightweight metadata without full conversation content. Opens interactive UI if supported.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of handoffs |
| handoffs | Yes | List of handoffs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some context: 'Returns lightweight metadata without full conversation content' clarifies the output scope, and 'Opens interactive UI if supported' indicates a potential UI interaction. However, it lacks details on permissions, rate limits, or error handling, leaving gaps for a tool with no annotation coverage.
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 highly concise and front-loaded, consisting of two sentences that efficiently convey key information: the core function and additional behavioral notes. Every sentence earns its place without redundancy or unnecessary elaboration, making it easy to parse.
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's low complexity (0 parameters, no annotations) and the presence of an output schema, the description is reasonably complete. It covers the purpose and key behavioral traits (lightweight metadata, UI interaction). However, it could benefit from more explicit differentiation from siblings to fully guide usage in context.
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 has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description doesn't add parameter details, which is appropriate here. Since there are no parameters, the baseline is 4, as the description doesn't need to compensate for any schema gaps.
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's purpose: 'List all saved handoffs with summaries.' It specifies the verb ('List'), resource ('saved handoffs'), and scope ('all'), distinguishing it from siblings like handoff_load or handoff_save. However, it doesn't explicitly differentiate from handoff_stats, which might also list metadata, leaving room for slight ambiguity.
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 guidance on when to use this tool versus alternatives. It mentions 'Returns lightweight metadata without full conversation content,' which hints at its output but doesn't clarify when to choose it over siblings like handoff_load (which might retrieve full content) or handoff_stats (which could provide statistical summaries). No explicit when/when-not or alternative recommendations are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a specific handoff by key. Returns full conversation content.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The key of the handoff to load | |
| max_messages | No | Optional: limit number of messages to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns 'full conversation content', which is useful, but doesn't disclose behavioral traits like whether it's read-only, requires permissions, handles errors, or has rate limits. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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, efficient sentence that front-loads the core action ('Load a specific handoff by key') and adds the return value. There is zero waste, and every word 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 tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose and return value, but lacks behavioral context and usage guidelines. Without annotations or output schema, it should do more to compensate, but it meets the bare minimum for a read operation.
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 schema already documents both parameters (key and max_messages). The description adds no additional meaning beyond what the schema provides, such as format details or usage examples for the parameters. Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb ('Load') and resource ('a specific handoff by key'), and specifies the return value ('full conversation content'). It distinguishes from siblings like handoff_list or handoff_clear by focusing on retrieval of a single item, but doesn't explicitly differentiate them in the text.
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 provided on when to use this tool versus alternatives like handoff_list (for listing) or handoff_merge (for combining). The description implies usage for loading a handoff when you have its key, but lacks explicit when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Merge multiple handoffs into one. Combines conversations and metadata from related handoffs into a single unified handoff.
| Name | Required | Description | Default |
|---|---|---|---|
| keys | Yes | Keys of the handoffs to merge (minimum 2) | |
| new_key | No | Key for the merged handoff. Auto-generated if omitted. | |
| new_title | No | Title for the merged handoff. Auto-generated if omitted. | |
| new_summary | No | Summary for the merged handoff. Auto-generated from source summaries if omitted. | |
| delete_sources | No | Whether to delete source handoffs after merging | |
| strategy | No | Merge strategy: 'chronological' sorts by creation time, 'sequential' keeps array order | chronological |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions merging and combining data but lacks critical details: whether this is a destructive operation (implied by 'merge' but not explicit), permission requirements, error handling, or what happens to source handoffs (only hinted at in the schema via 'delete_sources'). This leaves significant gaps for a mutation tool.
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 with zero waste, front-loading the core action ('merge multiple handoffs into one') and efficiently detailing the scope ('combines conversations and metadata'). Every word contributes directly to understanding the tool's function.
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 mutation tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context (e.g., side effects, error cases), output details, and usage guidance, relying solely on the schema for parameter info. This is inadequate given the tool's complexity and potential impact.
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 schema already documents all parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain why merging is needed or how parameters interact). Baseline 3 is appropriate since the schema does the heavy lifting.
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 specific action ('merge multiple handoffs into one') and the resources involved ('handoffs'), distinguishing it from sibling tools like handoff_list or handoff_load. It specifies what gets combined ('conversations and metadata') and the outcome ('single unified handoff'), providing a precise purpose.
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 guidance on when to use this tool versus alternatives like handoff_clear or handoff_save, nor does it mention prerequisites or exclusions. It states what the tool does but offers no context for decision-making, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart the shared HTTP server. Useful when the server is in an unhealthy state. All stored handoffs will be lost (data is in-memory).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the destructive effect ('All stored handoffs will be lost') and the reason ('data is in-memory'), which are crucial for understanding the tool's impact. However, it does not cover other potential aspects like permissions or rate limits.
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 highly concise and front-loaded, with two sentences that each earn their place: the first states the action and usage context, and the second warns of data loss. There is no wasted text, making it efficient and easy to parse.
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's complexity (a destructive restart operation), no annotations, and no output schema, the description is mostly complete. It covers the purpose, usage context, and critical behavioral impact (data loss). However, it lacks details on what 'unhealthy state' means or any error handling, leaving minor gaps.
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 has 0 parameters with 100% coverage, so no parameter information is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and effects. A baseline of 4 is applied as it handles the zero-parameter case well without unnecessary details.
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 specific action ('Restart the shared HTTP server') and the resource ('shared HTTP server'), distinguishing it from sibling tools like handoff_clear or handoff_list. It goes beyond a tautology by explaining the purpose ('when the server is in an unhealthy state').
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 context for when to use this tool ('when the server is in an unhealthy state'), but does not explicitly mention when not to use it or name alternatives. It implies usage guidance without being fully explicit about exclusions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a conversation handoff for later retrieval. Use this to pass conversation context to another AI or project.
structured (default): Organize content using the template below. Much faster — reduces output tokens to ~5-20% of the original conversation. Best for most handoffs.
verbatim: Save the complete word-for-word conversation. Use only when exact wording matters (e.g., legal text, precise error messages).
## Key Decisions
- [Decision]: [Rationale]
## Implementation Details
[What was built/changed, with relevant code snippets]
## Code Changes
[Files modified with brief description]
## Open Issues
- [Issue]: [Status/Context]
## Next Steps
- [ ] Action itemOmit sections that don't apply. Add custom sections if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Unique identifier for this handoff (e.g., 'project-design-2024'). Auto-generated if omitted. | |
| title | No | Human-readable title for the handoff. Auto-generated from summary if omitted. | |
| format | No | Output format. 'structured' (default): organized template - faster. 'verbatim': complete word-for-word conversation. | structured |
| summary | Yes | Brief summary of the conversation context (2-3 sentences) | |
| conversation | Yes | The conversation content. For format='structured': use the structured template above. For format='verbatim': the COMPLETE verbatim conversation in Markdown format (## User / ## Assistant) — NEVER summarize or shorten messages. | |
| from_ai | No | Name of the source AI (e.g., 'claude', 'chatgpt') | claude |
| from_project | No | Name of the source project (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the tool's behavior regarding format selection and template usage, but doesn't disclose other behavioral traits like whether saves are permanent, if they overwrite existing handoffs, authentication requirements, or rate limits. The description adds useful context about format trade-offs but leaves other aspects unspecified.
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 appropriately sized and well-structured with clear sections. The purpose is stated upfront, followed by format guidance and template details. While comprehensive, some template details could be considered overly verbose for a tool description, though they're relevant to usage.
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 7 parameters with 100% schema coverage but no annotations or output schema, the description provides good contextual completeness. It explains the tool's purpose, format options, and usage guidelines thoroughly. However, it doesn't describe what happens after saving (e.g., confirmation message, error conditions) or how saved handoffs integrate with sibling 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?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: it explains the rationale behind format choices ('Much faster — reduces output tokens to ~5-20%'), provides detailed template guidance for structured format, and clarifies when to use verbatim format. This adds significant value over the schema's parameter 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's purpose: 'Save a conversation handoff for later retrieval' with the specific goal of 'pass[ing] conversation context to another AI or project.' It distinguishes from siblings like handoff_load (retrieval) and handoff_clear (deletion) by focusing on saving/persisting data.
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 explicit guidance on when to use each format option: 'structured' is 'default' and 'Best for most handoffs,' while 'verbatim' should be used 'only when exact wording matters (e.g., legal text, precise error messages).' It also distinguishes from siblings by focusing on saving rather than loading, clearing, or listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get storage statistics and current limits. Useful for monitoring usage.
| 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 mentions the tool is for 'monitoring usage,' which implies a read-only operation, but doesn't explicitly state whether it's safe, requires authentication, has rate limits, or what the output format looks like. This leaves significant gaps in understanding the tool's behavior beyond its basic purpose.
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 extremely concise and front-loaded, consisting of just two short sentences that directly state the purpose and usage context. Every word earns its place, with no redundant or unnecessary information, making it highly efficient and easy to parse.
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's low complexity (0 parameters, no output schema, no annotations), the description is somewhat complete for a basic monitoring tool. However, it lacks details on what specific statistics or limits are returned, and without annotations or output schema, the agent might not fully understand the response format. This makes it adequate but with clear gaps in completeness.
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 has 0 parameters with 100% coverage, meaning there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. According to the rules, 0 parameters warrants a baseline score of 4, as the description doesn't have to compensate for missing schema information.
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's purpose with a specific verb ('Get') and resource ('storage statistics and current limits'), making it immediately understandable. However, it doesn't explicitly differentiate this tool from its siblings (like handoff_list or handoff_load), which could have overlapping monitoring functions, so it doesn't reach the highest score.
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 implied usage guidance by stating it's 'Useful for monitoring usage,' which suggests when to use it. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., handoff_list for listing items or handoff_clear for clearing storage), and doesn't mention any exclusions or prerequisites.
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 clearly distinct purpose with no overlap: clear, list, load, merge, restart, save, and stats cover unique operations. The descriptions specify different actions (e.g., clearing vs. loading vs. merging), making misselection unlikely.
All tools follow a consistent 'handoff_verb' pattern (e.g., handoff_clear, handoff_list, handoff_load). This verb_noun structure is uniform throughout, with no deviations in style or casing, making the set predictable and readable.
With 7 tools, the count is well-scoped for managing conversation handoffs. Each tool serves a specific function (e.g., saving, loading, clearing, merging), and none feel redundant or missing, fitting the domain's lifecycle needs appropriately.
The tool set provides complete CRUD-like coverage for handoff management: save, load, list, clear, merge, restart, and stats. This covers the full lifecycle from creation to deletion, with no obvious gaps for the stated purpose of handling conversation handoffs.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Portable AI memory shared across models and harnesses - plain markdown you own.
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Memory for deep conversational context across any platform
Cross-LLM persistent memory: store context once, recall it from any AI model.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/trust-delta/conversation-handoff-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server