3Notch
The 3Notch MCP server provides local, vendor-neutral tools for managing AI working state through briefs, packets, and an asynchronous inbox. You can:
Manage Project Briefs: Create, read, and list briefs defining objectives, scope, and design basis for AI agents.
Create and Manage Packets: Generate and import context handoff packets, self-addressed marks, typed replies, and private seed packets capturing lessons and preferences.
Utilize a Durable Inbox: Initialize a mailbox for async cross-agent delivery; send, list, pull, and acknowledge packet deliveries with integrity checks.
Perform Store Diagnostics: Check corpus integrity, run full diagnostics, and retrieve overall store status.
3Notch
Save the working state your AI tools won't.
Website · Docs · Quickstart · npm
A Claude Code session dies mid-run — rate limit, crash, compaction, laptop sleep — or you're moving a task from Claude Code to Codex, Cursor, or ChatGPT. The code is still in git. The objective, decisions, and next steps often are not. The next session rebuilds that state from scratch.
3Notch is a local CLI and MCP server for:
Continuation checkpoints — when Claude Code is configured, recover after rate limits, model-down failures, and compaction
Portable packets — hand off selected work across tools, repos, and machines
Durable inbox — async delivery between stores that share a mailbox root
No cloud service. No account. No telemetry. Records stay on disk as Markdown (and optional artifacts) under .notch/.
Why this layer exists
Every major vendor ships transcript persistence and memory files. None ship durable working state:
Claude Code auto-saves transcripts and takes file checkpoints — but checkpoints are session-scoped undo, gone when the session ends.
OpenAI's Agents SDK serializes
RunState— at planned human-approval pauses, not arbitrary failures.Gemini and Grok persist conversations server-side. A transcript is a diary, not a manifest.
Recovering from a transcript means re-reading a conversation and re-interpreting what happened. The vendors' own guidance converges on the fix: combine native persistence with handoff files and checkpoint strategies. 3Notch is that layer — local, vendor-neutral, yours.
Related MCP server: ITHZ MCP
Install
npm install -g @3notch/cli
notch onboardAgent prompt (optional):
Install @3notch/cli, run
notch onboardin this repo, and set up continuation checkpoints if I use Claude Code. Use packets for handoffs across tools or repos. Read the package README before changing MCP config.
Common flows
Save and resume working state
Wrap-up: notch save. Session start: notch resume. No confirmation prompt. Codex, Grok, and Cursor should run those two commands; there is no 3Notch daemon.
notch save --summary "Auth validation done" --next-steps "Implement session store"
notch resume
notch resume --jsonClaude Code SessionStart injects the latest checkpoint body so the next agent can continue without calling get_packet after a human yes. Private packets stay hidden unless you pass --include-private. See Continuation checkpoints.
Hand off between tools
notch packet create \
--title "Auth refactor checkpoint" \
--summary "Token validation done; session store migration blocked." \
--next-steps "Implement Redis session adapter"
notch packet preview <id>
# other tool / session imports and continuesShip files to another repo or machine
notch packet create \
--title "Brand handoff" \
--summary "Assets and layout for the launch page." \
--file mascot.jpg:asset \
--file showcase.html:source \
--next-steps "Build the launch page from showcase.html and mascot.jpg."
notch packet pack <id>
# move <id>.notchpkt however you prefer, then:
notch packet unpack <id>.notchpktAsync agents — durable inbox
Both sides register the same mailbox root, then pack/send and pull/ack:
notch inbox init --name review-agent --root /shared/3notch-mailbox
notch packet pack <id>
notch send <id>.notchpkt --to local:review-agent
# forward the printed delivery notice via chat, Slack, etc.
notch inbox list
notch inbox pull <delivery-id> --import
notch inbox ack <delivery-id>local: addresses are routing labels, not authenticated identity. See Durable inbox.
Web chat without MCP
notch prompt --client claude-chat
# paste into the chat, copy the packet back
pbpaste | notch packet import -Personal capture
notch mark --summary "Keep browser auth cookie-based" --tags authHow it works
You or an agent write selected context through the CLI or MCP tools.
3Notch validates, secret-scans, and stores records under
.notch/.Preview before another agent relies on the content.
The next session, tool, or store imports or resumes from that record.
Targeting fields (--to-agent, --to-repo) are intent metadata. Bytes move via your transport (scp, git, AirDrop, Tailscale) or the durable inbox mailbox — not a 3Notch-hosted relay.
Commands
notch onboard initialize .notch/ and MCP setup
notch save write a continuation from git snapshot + summary
notch resume print the latest continuation (no prompt)
notch packet create create a packet (--file, --ref, --next-steps)
notch packet import <path> import into .notch/inbox/
notch packet preview <id> show what an agent will read
notch packet pack / unpack .notchpkt archive round-trip
notch packet list / show list / inspect packets
notch inbox init/list/status/pull/ack durable delivery lifecycle
notch send <archive> --to <address> send a packed project handoff
notch reply <id> typed reply to a packet
notch mark self-addressed private capture
notch brief / brief create|list|show scoped task briefs
notch seed from <path> private context seeding
notch prompt --client <client> agent / web-chat instruction packs
notch scan <file-or-stdin> secret scanner
notch check structural corpus checks
notch doctor store diagnostics
notch status store summary
notch mcp serve local stdio MCP serverMCP
notch mcp serve over local stdio:
Tools | |
Read |
|
Write |
|
Private records under .notch/private/ stay hidden unless the server starts with --include-private. Client setup: docs/guides/mcp-setup.md.
Documentation
Topic | Guide |
Index | |
Cross-repo packets | |
Cross-tool handoff | |
Durable inbox | |
Continuation checkpoints | |
MCP setup | |
Privacy | |
Security | |
Releases (maintainers) |
Website docs mirror: https://3notch.dev/docs/.
Boundaries
Local files by default — no hosted relay, account system, or telemetry
No vector DB / native DB dependency
No arbitrary shell execution through MCP
You move bytes; 3Notch validates, scans, hashes, and stores them
Regression guard: tests/unit/no-deferred-commands.test.ts.
Contributing
Prefer opening an issue before large features. See open issues and CONTRIBUTING.md.
git clone https://github.com/coldlogicAI/3notch.git
cd 3notch
npm install
npm run lint && npm run type-check && npm run build
npm test && npm run test:e2e
npm run release:checkSee CONTRIBUTING.md.
Architecture reference (historical but still useful): docs/archived-plans/v1/3notch-v1-technical-spec.md.
License
MIT © 3Notch contributors
Available Tools
23 toolsack_inbox_deliveryAcknowledge inbox deliveryA
Mark a reviewed, imported, or intentionally skipped delivery as acknowledged. Packet bytes remain retained for audit and this tool never deletes them.
Inputs: deliveryId (required), actorName. Returns: ok, state, packetId, deliveryId, +4 more
check_storeCheck corpus integrityARead-only
Use after imports or before trusting a supersedes or reply chain: reports broken supersedes and replyTo references, self-references and supersedes cycles as errors, and competing supersedes forks as warnings, each with recovery text. Deterministic and read-only — it never repairs records, and it covers private records only when the server runs with --include-private. Use run_doctor for directory, secret, and audit-log checks.
Inputs: no named parameters.
create_briefCreate targeted briefA
Use when the user wants a scoped task written down for another agent or session: this writes a new brief Markdown record under .notch/briefs/ from the fields you supply and returns the record with its path. It stores only what you pass — it never reads chat history — and it refuses scope files outside the project root or content the secret scanner flags.
Inputs: goal (required), scope (required), title (required), exclusions (required), +8 more.
create_markCreate private markA
Use for a self-addressed capture — a preference, decision, or note the user wants to persist for later sessions with no recipient. This writes a private seed packet straight into .notch/private/inbox/; it is never sent anywhere and stays hidden from packet listings unless the server runs with --include-private.
Inputs: summary (required), tags, title, actorName, +2 more.
create_packetCreate handoff packetA
Use to capture the current working state as a portable packet another session, tool, or repo can import: it writes a Markdown record to the store outbox, copies any listed files in as artifacts, and returns the packet with its path. Handoff packets require at least one recipient field, content is secret-scanned before it is written, and creating a packet transmits nothing — packing and sending are separate steps.
Inputs: title (required), summary (required), refs, tags, +14 more.
create_replyReply to a recordA
Use to answer a specific packet — question, clarification, counter-decision, objection, or confirmation — instead of editing it; the reply is written as a new packet linked back to the parent, and the parent is never modified. parentId must match exactly one record in the store, and the reply is written privately whenever the parent is private or seed, or private is set.
Inputs: summary (required), parentId (required), replyType (required), refs, +10 more.
create_seed_packetCreate private seed packetA
Use when the user wants durable private context — preferences, conventions, lessons — captured for a future session rather than handed to someone else. This writes a purpose: seed, sensitivity: private packet to .notch/private/outbox/ from the title and summary you supply, and it stays local and unimported until someone runs import_seed_packet.
Inputs: title (required), summary (required), lessons, prompts, +6 more.
get_briefARead-only
Read the default project brief.
Inputs: includeMarkdown.
get_inbox_deliveryGet inbox deliveryARead-only
Read retained delivery state by ID, optionally at another registered local: address in the same mailbox root, so the sender can see pulled, acknowledged, or rejected status.
Inputs: deliveryId (required), address. Returns: ok, state, address, delivery, +6 more
get_packetARead-only
Read a packet by ID or slug.
Inputs: id (required), direction, includePrivate, includeMarkdown.
get_statusGet project statusARead-only
Read first for orientation in a repo that uses 3Notch: returns the project name, store path, counts of briefs and inbox, outbox and private seed packets, the five newest inbox packets, up to ten briefs newest-first, and any config validation warnings. Counts and short summaries only — private seed packets are counted but their contents are never returned.
Inputs: includeWarnings.
get_targeted_briefGet targeted briefARead-only
Read one targeted brief in full by record ID or stored filename stem, usually after list_briefs narrows the candidates. Set includeMarkdown to also get the rendered Markdown; the call fails rather than guessing when the identifier matches no brief or more than one.
Inputs: id (required), includeMarkdown.
import_packetImport packet fileA
Use when the user hands over a packet file or unpacked packet folder from another repo, tool, or machine and wants it in this store. Requires an absolute path and refuses symlinks, verifies bundled artifact hashes and any referenced records, secret-scans the content, routes private or seed packets to .notch/private/inbox/, and refuses a packet ID already present in that destination rather than overwriting it.
Inputs: packetPath (required), actorName, asReviewed.
import_seed_packetImport private seed packetA
Use when the user points at a seed packet file they have already reviewed and wants that carried-forward private context in this store. Requires an absolute path and refuses symlinks, accepts only packets with purpose: seed, always imports into .notch/private/inbox/, and refuses a packet ID already present rather than overwriting it.
Inputs: packetPath (required), actorName, asReviewed.
inbox_initInitialize durable inboxA
Use only after the user chooses an explicit local mailbox root and address for async cross-agent packet delivery. This writes local configuration and registers the address; it does not create authenticated identity.
Inputs: name (required), root (required), actorName. Returns: ok, root, address, transport, +2 more
list_briefsList targeted briefsARead-only
List targeted briefs in this store, newest first, to find a brief ID before reading one with get_targeted_brief. Returns brief metadata only, never the rendered Markdown; targetAgent and status filters match exactly, a tag filter requires every listed tag, and all matches are returned unless limit is set.
Inputs: tags, limit, since, status, +1 more.
list_inboxList durable inboxARead-only
List pending async packet deliveries for this store. Use includeAll only when reviewing pulled, acknowledged, or rejected history.
Inputs: includeAll. Returns: ok, address, deliveries, nextAction
list_packetsList packetsARead-only
List packets in this store, newest first, to find an ID before reading one with get_packet; returns metadata and on-disk paths, never packet bodies. Defaults to both directions and at most 50 results; private records stay hidden unless the server was started with --include-private, and asking for them without it returns a NOTCH_PRIVATE_HIDDEN warning instead of failing.
Inputs: to, tags, limit, since, +4 more.
pull_inbox_packetPull inbox packetA
Verify an async delivery by SHA-256 and existing packet/security checks; set import to true to import it through normal 3Notch validation. Import does not acknowledge or delete the retained delivery.
Inputs: deliveryId (required), import, actorName, asReviewed. Returns: ok, state, packetId, deliveryId, +4 more
resume_working_stateResume working stateARead-only
Use at session start to load the latest continuation for this store and continue immediately. Returns the checkpoint body; no confirmation step. Empty store returns checkpoint null. Private packets stay hidden unless the server was started with --include-private.
Inputs: includePrivate.
run_doctorRun store diagnosticsARead-only
Run when 3Notch behaves oddly or before trusting a store: checks required directories, .notch/.gitignore coverage of the private, index, and log paths, symlinks, invalid or duplicate records, secrets inside records, audit-log corruption, and Claude Code continuation hook drift. Read-only apart from fixDerivedState, which is refused when the server runs in read-only mode.
Inputs: strict, fixDerivedState.
save_working_stateSave working stateA
Use at wrap-up to persist this session so another agent can continue without a human: writes a continuation packet from the current Git snapshot plus the optional summary and nextSteps you supply. Secret-scanned before write. Does not ask for confirmation.
Inputs: private, summary, actorName, nextSteps.
send_packetSend packed packetA
Use after notch packet pack when the user wants an async handoff to a registered local: address in another repo or model client. This is an externally visible write to the configured mailbox and refuses private or seed packets.
Inputs: to (required), packetPath (required), actorName. Returns: ok, state, notice, packetId, +6 more
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 23 tools
Tools are grouped into clear workflows: packets, briefs, private seeds, inbox delivery, and diagnostics. A few pairs like create_mark vs create_seed_packet and save_working_state vs create_packet have overlapping intent, but the detailed descriptions provide enough distinguishing conditions.
Nearly all tools follow a snake_case verb_noun pattern such as create_packet, list_briefs, and ack_inbox_delivery, making the set predictable. The main deviation is inbox_init, which uses noun_verb order, and run_doctor is a minor phrase irregularity.
At 23 tools, the server is on the heavy side and falls within the 16-25 range that feels large for agent selection. The tools are individually justified by a broad domain, but several could be consolidated or exposed as subcommands to reduce cognitive load.
The core packet, brief, private-seed, inbox, and health-check lifecycles are well covered, including import, validation, and acknowledgment flows. Minor gaps exist: the default brief can only be read, supersede creation is not exposed even though check_store validates supersede chains, and there is no update/delete for immutable records.
Maintenance
Related MCP Connectors
Evidence-backed project memory and checkpoints for AI coding agents.
Persistent work tracking for AI agents: tasks, status and history that follow you across machines
Agent checkpoints. Resume after context resets and handoffs with retry-safe, versioned saves.
Shared control plane for AI coding agents — tasks, memory, decisions, file locks. 12 tools.
Related MCP Servers
- AlicenseBqualityDmaintenancePortable, auditable, local-first MCP memory for MCP-compatible AI agents and coding workflows. It keeps durable project memory outside the model runtime, compresses continuity into smaller working packs, and carries forward operational state so agents can resume with less repetition.2841Apache 2.0
- FlicenseNot gradedqualityCmaintenanceLocal-first deterministic project memory for AI coding agents, with context packs, decisions, gates, risks, scoped claims and explicit checkpoints in project-owned files.-
- AlicenseNot gradedqualityDmaintenancePreserves continuity between coding agent sessions (e.g., Claude Code and Codex) via local, structured checkpoints, enabling a checkpoint → clear → resume workflow.MIT
- AlicenseNot gradedqualityCmaintenancePersistent, shared memory for Claude across sessions and clients (Code, Desktop, Cowork) — deterministic diff reads, checkpoints, cross-client task handoff, and project-wide search. 100% local and deterministic, no API keys, no LLM summarization.4MIT