AI Handoff MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AI_HANDOFF_TOKENS | No | Token profile for the MCP server when the host starts it outside the project folder. Valid values are standard, lean, or minimal. | standard |
| AI_HANDOFF_DATA_DIR | No | Overrides the directory where checkpoints are stored. Defaults to ~/.ai-handoff-mcp. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| resume_taskA | CALL THIS FIRST in a new session. Returns the saved checkpoint written by the previous agent (Claude, Copilot, ...), what hooks captured automatically after it, the current Git state and any work done after the checkpoint, so you can continue exactly where it stopped without reading old chat transcripts. Records in the timeline that you resumed. |
| save_handoffA | Write a complete checkpoint for the project, replacing the previous one (the timeline is kept). Use at the start of a new task; use update_handoff or log_progress afterwards. |
| update_handoffA | Change selected checkpoint fields. Given fields replace the stored value; append* lists are added without duplicates. Call before you stop, with verified progress, next steps and real test results. |
| log_progressA | Cheap, frequent checkpoint. Call after EVERY meaningful step, because a usage limit can end your session at any time. completedStep is moved from nextSteps to completed when the text matches; lists are appended without duplicates. |
| get_handoffA | Read the raw saved checkpoint (JSON) for a project. Prefer resume_task when starting a session. |
| get_project_statusA | Read-only Git branch, HEAD, short status and diff stat for the project. Does not read source files or session logs. |
| prepare_handoffA | Build a continuation prompt the user can paste into another agent (useful when that agent has no MCP access). Does not message agents. |
| export_handoff_markdownB | Write the checkpoint to HANDOFF.md in the project root; refuses to overwrite unless overwrite=true. |
| clear_handoffA | Delete the saved checkpoint for a project (e.g. after the task is done). Requires confirm=true. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| resume | Continue the task another AI agent left, from its last checkpoint |
| checkpoint | Ask the agent to record verified progress so another agent can take over |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Most tools target distinct operations, but save_handoff, update_handoff, and log_progress all mutate the same checkpoint at different granularities, while resume_task and get_handoff both read it. Descriptions provide clear guidance such as preferring resume_task and using log_progress frequently, so misselection is limited.
All tools use a consistent snake_case verb_noun pattern: resume_task, save_handoff, update_handoff, log_progress, get_handoff, get_project_status, prepare_handoff, export_handoff_markdown, clear_handoff. There is no mixing of conventions or vague naming.
Nine tools sit comfortably in the ideal 3-15 range for a handoff/checkpoint server. Each tool has a distinct role: resume, save, update, log, get, status, prepare, export, and clear.
The set covers the full handoff lifecycle: save, update, log, read/resume, export, clear, and Git status. Minor gaps remain, such as no tool to list available projects/checkpoints or inspect captured hooks, which could complicate discovery in multi-project use.