sync

Your agent doesn't ask for memory.

CommunityOnlineNo sign-inGlobalFreeRead-only

What it can do

  • Status: SESSION-START tool. Call this FIRST in every new chat — it is the entry point to Sync. Returns the companies and projects this token can reach, each with `version`, `description`, `language`,
  • Project List: List every project in a company with version, description, feature counts, language, and knowledge update mode. Use this when the user names a company explicitly or when status returned
  • Project Create: Create a new project inside a company. ONLY call after asking the user for explicit confirmation — project creation is high-impact and visible to the whole team. Pass a 2–4 sentence fa

What data it sees

Do you need an account

No: the server works without sign-in

Your agent doesn't ask for memory. It uses it.

The moment Sync connects, Claude, Cursor, VS Code, and Zed start checking it before every task — and writing to it after every decision. No "look it up." No "remember this." The protocol handles it.

What that means in practice:

  • Decisions made on Tuesday survive Friday's new chat
  • A teammate's agent picks up exactly where yours left off
  • The same context follows you across every editor you use
  • A new person on the project — productive on day one, not week three

Get started in one sentence. Connect Sync, then tell the agent "set up Sync for this project." It reads your codebase and captures what matters. From there on, it keeps itself current as you work.

Free for personal use.

Server tool list (12)

Raw names from tools/list. Only developers need these.

statusSESSION-START tool. Call this FIRST in every new chat — it is the entry point to Sync. Returns the companies and projects this token can reach, each with `version`, `description`, `language`, and `knowledge_update_mode`. Use the result to (a) confirm Sync is connected, (b) auto-bind to the correct project for the current cwd (match cwd basename or git remote name to project.slug; if exactly one project is reachable, that is the active project by token scope), (c) cache `version` per project so a later project_load is needed only when version changes. There is no implicit active project over MCP — every project-scoped tool must receive `project_id` explicitly. Anti-trigger: do NOT skip this even if you remember a project_id from a prior session — token scope or project version may have changed.
project_listList every project in a company with version, description, feature counts, language, and knowledge update mode. Use this when the user names a company explicitly or when status returned multiple projects and you need to pick the right one by name/slug. Anti-trigger: do NOT call before status — status already returns reachable projects with the same fields.
project_createCreate a new project inside a company. ONLY call after asking the user for explicit confirmation — project creation is high-impact and visible to the whole team. Pass a 2–4 sentence factual description capturing what the project is and why it exists (read README, package.json, or codebase root before writing it). Description seeds future agents' first impression. The active token must reach the target company at whole-company scope; project-scoped PATs cannot create new projects. After creation, propose seeding `prompt_content` from the local CLAUDE.md (if present) via project_update.
project_updateUpdate project metadata. Call this when (a) the user asks to change name/description/language/mode, (b) you want to seed or refresh `prompt_content` (project-wide agent prompt — equivalent to a shared CLAUDE.md; offer to migrate the local CLAUDE.md into prompt_content on first session), or (c) your understanding of the project shifted enough that the description is misleading. Bumps `project.version` when name, prompt_content, description, language, or knowledge_update_mode actually change — agents detect this via _meta and reload. Anti-trigger: do NOT use this to record knowledge about a feature (use feature_update instead). Only the fields you pass are touched.
project_loadLoad full project context: id, slug, name, description, prompt_content (the project-wide system prompt — equivalent to a shared CLAUDE.md), language, knowledge_update_mode, version, conventions. Call once per session AFTER status, then cache by `version`. Reload only when a later tool's `_meta.project_version` exceeds the cached version. Anti-trigger: do NOT call repeatedly during a session — the data is project-wide and changes infrequently. Anti-trigger: do NOT use this to discover features (use search or feature_load instead).
searchFull-text search across features and knowledge items in a project. CALL TRIGGERS: (a) BEFORE feature_create — to avoid duplicate features under different slugs; (b) BEFORE starting new work in any domain — previous decisions and constraints from other features may apply; (c) when the user references a feature by name and you need its ID. Search by name, keywords, or related concepts. Anti-trigger: do NOT call to discover a feature you already know the slug of (use feature_load with `query` for slug lookup, or pass feature_id directly).
feature_loadLoad feature context. CALL IMMEDIATELY when the user mentions a feature, task, or ticket — before starting work, before suggesting changes, before reading code. The first call returns a lightweight map (title, status, description, knowledge summary, version) plus graph neighbors and incoming_warnings at depth=1 — inspect incoming_warnings every time and load any superseding/blocking feature BEFORE continuing. Then load sections selectively: decisions and constraints are almost always relevant; facts and artifacts on demand. Typical first call: sections=["decision","constraint","open_question"]. If feature_id is unknown, pass `query` plus `project_id` to search by name/slug. Anti-trigger: do NOT call without a clear target — use search if you only have a vague keyword.
feature_createCreate a new feature. ALWAYS run search FIRST to avoid duplicates — features in the same domain often already exist under a different slug. Pre-creation requirements: (a) verify project_id matches the user's intent (mistargeting is silent), (b) write a meaningful slug that matches the user's vocabulary, (c) draft a description with descriptive '##' headings (e.g. '## Backend API', '## UX flow', '## Constraints') — not generic ones like '## Details'. After creation, immediately seed 2–3 knowledge items via feature_update (decisions, constraints, open_questions that motivated the feature) — a description-only feature is incomplete. Returns the new feature's ID and version; use the ID for subsequent feature_update calls.
feature_editUpdate feature metadata — title, status, description, or links. Status TRIGGERS: move draft→active the moment you start executing; move active→review when work is done but the user has not signed off; move review→done only after explicit user confirmation OR objective verification (tests pass, deploy succeeded). If the user pushes back after review, move back to active. Status must reflect the CURRENT state of the work — do not let it go stale. For description rewrites, keep narrative prose only — do NOT inline structured decisions/constraints/TODOs there (they belong as knowledge items via feature_update). Anti-trigger: do NOT use this to add knowledge items (use feature_update). Bumps feature.version when description changes.
feature_updatePush knowledge updates to a feature — THIS IS THE PRIMARY VALUE OF SYNC. Be aggressive, not cautious: each call is atomic and versioned, so saving and refining later is free. The downside of NOT saving is that the next session loses context. SAVE TRIGGERS — call when ANY of these happen: (1) you answer a "why"/"why not" question → decision with reason; (2) user corrects your approach → decision, reason='user preference: <explanation>'; (3) you discover non-obvious behavior (bug, config quirk, library limitation) → fact; (4) you hit an external limit (API quota, browser constraint, legal requirement) → constraint; (5) you create/modify a load-bearing file (schema, migration, config) → artifact; (6) an unresolved item comes up → open_question (mark resolved=true the moment it is answered); (7) user says "remember"/"note that"/"for next time" → save immediately; (8) you finish a non-trivial step → sweep what decisions you made and what you discovered. KNOWLEDGE TYPES: fact (verified objective statement), decision (architectural/implementation choice — ALWAYS include reason; without it the next person reverses your choice), constraint (external limit narrowing the solution space — most expensive type to lose), artifact (key file/config with context), open_question (unresolved). QUALITY BAR: save what would cost 30+ minutes to rediscover; skip trivia obvious from code. If the project's knowledge_update_mode is "confirm", you MUST present proposed items to the user before calling. Bumps feature.version atomically.
feature_linkCreate a typed edge between two features. THIS IS A REFLEX, NOT AN AFTERTHOUGHT — the explicit feature graph is the primary discovery mechanism, and it only exists if you maintain it. CALL TRIGGERS: (a) you write a knowledge item that mentions another feature → call feature_link in the SAME logical step (default type=references); (b) you create a replacement for an old feature → type=supersedes from new→old, then archive the old via feature_edit (do NOT delete it — incoming_warnings depends on it); (c) one feature gates or precedes another → depends_on or blocks; (d) features share a constraint → shares_constraint. Mentions in prose without a link are invisible to the graph. Both features must be in the same company; cross-project within a company is fine. Pass `reason` so the rationale survives without extra context. Does NOT bump feature.version — links are metadata.
feature_unlinkRemove a feature link by its ID. Use only when the relationship is genuinely incorrect or the source feature no longer references the target. Do NOT unlink supersedes edges to old features — incoming_warnings on downstream features depends on those edges remaining intact even after archival.