Provides embedding generation using locally-hosted Ollama models, enabling offline semantic memory search.
Provides embedding generation using OpenAI's API, enabling semantic search over team memories.
Provides persistent storage for memories and vectors using PostgreSQL with pgvector for relational and semantic queries.
Provides sub-millisecond vector search using Redis Stack for fast memory retrieval.
Click on "Deploy 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., "@SyncContext save: use React with TypeScript for frontend"
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.
Shared team memory for AI coding agents. Sync context, decisions, and knowledge across your entire team via the Model Context Protocol.
AI coding agents (Claude Code, Cursor, Windsurf) each maintain isolated context. Developer A's agent knows nothing about Developer B's decisions. This leads to:
Conflicting architecture decisions across team members
Repeated mistakes and lost institutional knowledge
Painful onboarding for new developers
No shared understanding between frontend, backend, and infra
Related MCP server: AIVectorMemory
SyncContext provides a shared semantic memory layer that connects your team's AI agents. One token per project, shared brain, unlimited team members.
Developer A (Frontend) --> saves: "Button uses Tailwind, prop X is required"
Developer B (Backend) --> searches: "frontend patterns" --> gets full context
Developer C (New hire) --> runs: get_project_context --> instant onboardingYour team deploys SyncContext (self-hosted or cloud)
Each developer adds the server URL + their project token to their MCP client
On first connection, the project is auto-created in the database
AI agents read and write shared memories scoped to the project
MCP Client (Claude Code, Cursor)
│
│ Authorization: Bearer <project-token>
│ X-Project-Name: "My Project"
│
▼
SyncContext Server (HTTPS)
│
├── New token? → Auto-create project in DB
├── Known token? → Load existing project
│
▼
PostgreSQL + pgvector (semantic search)Add to your .mcp.json (Claude Code) or MCP settings (Cursor):
{
"mcpServers": {
"synccontext": {
"url": "https://your-synccontext-server.com/mcp",
"headers": {
"Authorization": "Bearer your-project-token",
"X-Project-Name": "My Project"
}
}
}
}That's it. The project is auto-created on first connection.
git clone https://github.com/infinity-ai-dev/SyncContext.git
cd SyncContext
cp .env.example .env
# Edit .env: set SYNCCONTEXT_GEMINI_API_KEY
docker compose up -d# Requires PostgreSQL with pgvector
uv sync
uv run synccontextWorks with any MCP client that supports HTTP transport:
{
"mcpServers": {
"synccontext": {
"url": "https://your-server.com/mcp",
"headers": {
"Authorization": "Bearer your-project-token",
"X-Project-Name": "My Project"
}
}
}
}For local development with a direct database connection:
{
"mcpServers": {
"synccontext": {
"command": "uv",
"args": ["--directory", "/path/to/SyncContext", "run", "synccontext"],
"env": {
"SYNCCONTEXT_PROJECT_TOKEN": "my-team-token",
"SYNCCONTEXT_DATABASE_URL": "postgresql://user:pass@localhost:5432/synccontext",
"SYNCCONTEXT_GEMINI_API_KEY": "your-key"
}
}
}
}Tool | Description |
| Store decisions, patterns, bugs, conventions with metadata |
| Retrieve a specific memory by UUID |
| Update content (auto re-embeds if changed) |
| Remove a specific memory |
| Import multiple memories at once |
Tool | Description |
| Semantic search across all team knowledge |
| Find context about specific files |
| Discover related memories by similarity |
| Browse recent memories with filters |
Tool | Description |
| Full project summary (onboarding) |
| All knowledge categories with counts |
| Who's contributing knowledge |
Tool | Description |
| Create a new project (admin token required) |
| List all registered projects (admin token required) |
┌─────────────────────────────────────┐
│ Claude Code / Cursor / Windsurf │
│ (MCP Client) │
└──────────┬──────────────────────────┘
│ HTTPS + Bearer Token
┌──────────▼──────────────────────────┐
│ SyncContext MCP Server │
│ ┌────────────┐ ┌───────────────┐ │
│ │ Auth │ │ Per-request │ │
│ │ Middleware │──│ Project Scope │ │
│ └────────────┘ └───────────────┘ │
│ ┌────────────┐ ┌───────────────┐ │
│ │ Embedding │ │ Memory + │ │
│ │ Provider │ │ Search Service│ │
│ └────────────┘ └───────────────┘ │
└──────────┬──────────────────────────┘
│
┌──────────▼──────────────────────────┐
│ PostgreSQL + pgvector │
│ ┌──────────┐ ┌──────────────────┐ │
│ │ projects │ │ memories + │ │
│ │ (tokens) │──│ memory_vectors │ │
│ └──────────┘ └──────────────────┘ │
└─────────────────────────────────────┘Each project token maps to an isolated namespace. Multiple teams share the same server with full data isolation:
Token A ("sc_frontend...") → Project "Frontend App" → memories scoped to frontend
Token B ("sc_backend...") → Project "Backend API" → memories scoped to backend
Token C ("sc_infra...") → Project "Infrastructure" → memories scoped to infraProvider | Dimensions | Cost | Offline | Detected by |
Gemini | 768 | Free (1500 req/min) | No |
|
OpenAI | 1536 | $0.02/1M tokens | No |
|
Ollama | 768 | Free | Yes |
|
Backend | Best For | Persistence |
pgvector (default) | Relational queries + vectors | Disk (durable) |
Redis Stack | Sub-ms latency | AOF + volume (durable) |
All settings via environment variables (prefix SYNCCONTEXT_):
Variable | Default | Description |
| — | Default project token (stdio mode) |
| — | Admin token for create/list projects |
|
| PostgreSQL connection string |
|
|
|
|
|
|
| — | Gemini API key |
| — | OpenAI API key |
| — | Ollama server URL |
|
|
|
|
| HTTP bind address |
|
| HTTP port |
Docker Swarm with Traefik
PostgreSQL with pgvector extension
A domain pointing to your server
# Install pgvector
docker exec $(docker ps -q -f name=postgres) bash -c \
"apt-get update && apt-get install -y postgresql-16-pgvector"
# Create database + extensions
docker exec $(docker ps -q -f name=postgres) psql -U postgres -c "CREATE DATABASE synccontext"
docker exec $(docker ps -q -f name=postgres) psql -U postgres -d synccontext -c \
'CREATE EXTENSION IF NOT EXISTS "uuid-ossp"; CREATE EXTENSION IF NOT EXISTS "vector";'See deploy/swarm-stack.yml for a complete Portainer-ready stack with Traefik integration.
On first startup, the container runs migrations and creates all tables. Check logs to confirm.
uv sync --extra dev
uv run pytest tests/ -v # 53 tests
uv run ruff check core/ server/
uv run synccontext # run locally (stdio)Multi-arch images for linux/amd64 and linux/arm64:
docker pull infinitytools/synccontext:latest14 MCP tools (CRUD, search, bulk, admin)
pgvector + Redis backends
Gemini / OpenAI / Ollama embeddings (auto-detected)
Docker multi-arch builds (amd64 + arm64)
Multi-project with per-request auth
Auto-create projects from Bearer token
Auto-migrations on container startup
SyncContext Cloud (managed SaaS)
Web dashboard for memory management
Webhook notifications on memory changes
Memory expiration / archival policies
RAG integration (index entire codebases)
MIT — see LICENSE for details.
Save multiple memories at once.
Args: memories: List of memory objects with 'content' (required) and optional 'author', 'tags', 'file_path', 'memory_type'
Inputs: memories (required). Returns: result
Create a new project. Returns the generated token.
Args: name: Display name for the project description: Optional project description admin_token: Admin authentication token
Inputs: name (required), admin_token, description. Returns: result
Delete a specific memory by its ID.
Args: memory_id: UUID of the memory to delete
Inputs: memory_id (required). Returns: result
Find memories semantically similar to an existing memory.
Args: memory_id: UUID of the source memory top_k: Maximum number of similar memories (default 5)
Inputs: memory_id (required), top_k. Returns: result
Get a single memory by its UUID.
Args: memory_id: UUID of the memory to retrieve
Inputs: memory_id (required). Returns: result
Get a summary of the project's shared knowledge base.
Use this when onboarding to a project or when you need an overview of what the team has documented so far.
Inputs: no named parameters. Returns: result
List all contributors who have saved memories in this project.
Inputs: no named parameters. Returns: result
List recent memories from the project.
Args: limit: Maximum number of memories to return (default 20) tag: Filter by tag author: Filter by author memory_type: Filter by type (general, decision, bug, pattern, onboarding)
Inputs: tag, limit, author, memory_type. Returns: result
List all registered projects. Requires admin token.
Args: admin_token: Admin authentication token
Inputs: admin_token. Returns: result
List all unique tags used in this project with their usage counts.
Inputs: no named parameters. Returns: result
Save a memory to the shared team knowledge base.
Use this to store architecture decisions, patterns, bugs, conventions, or any context useful for team members and AI agents.
Args: content: The memory content to save author: Who is saving this (developer name/email) tags: Categorization tags (e.g. ["auth", "frontend", "decision"]) file_path: Related file path if applicable memory_type: Type: general, decision, bug, pattern, onboarding
Inputs: content (required), tags, author, file_path, +1 more. Returns: result
Find all memories related to a specific file path.
Args: file_path: File path to search for (substring match, case-insensitive) limit: Maximum number of results (default 20)
Inputs: file_path (required), limit. Returns: result
Search team memories by semantic similarity.
Use this to find relevant context, decisions, patterns, or conventions that team members have previously documented.
Args: query: Natural language search query top_k: Maximum number of results (default 5) tag: Filter by specific tag author: Filter by specific author
Inputs: query (required), tag, top_k, author. Returns: result
Update an existing memory. Re-embeds automatically if content changes.
Args: memory_id: UUID of the memory to update content: New content (triggers re-embedding if changed) tags: New tags (replaces existing) file_path: New file path memory_type: New memory type
Inputs: memory_id (required), tags, content, file_path, +1 more. Returns: result
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 14 tools
Most tools target distinct resource-action pairs, and descriptions clarify intent. The main overlaps are save_memory/bulk_save_memories and search_memories/find_similar, but their singular vs. bulk and query vs. example-based retrieval differences are reasonably clear.
The dominant verb_noun pattern (save_memory, list_memories, get_memory, delete_memory, update_memory, create_project) is clear and consistent. A couple of names like find_similar and search_by_file deviate from the object-oriented pattern but remain readable and predictable.
14 tools is within a reasonable scope for a shared knowledge base covering memory CRUD, project management, and metadata exploration. The count is slightly higher than necessary because bulk_save_memories and find_similar add convenience rather than essential functionality.
The memory lifecycle is well covered with create, read, update, delete, list, and multiple search modes, plus project overview and tag/contributor metadata. Minor gaps exist around project update/delete and a bulk delete operation, but these are not likely to block core workflows.
Team memory for AI coding agents and code reviews, reviewed by humans and served over MCP.
An MCP memory server. One memory your agents share — across models, devices and apps.
shared AI-context layer for teams — persistent memory your agents search and update over MCP
Hosted MCP memory for coding agents: persistent across sessions, editable markdown, team sharing.