
Shift Mcp Server
io.github.cyanheadsPublished by GitHub account cyanheadsv0.2.0Updated Nov 1, 2026
Lightweight coordination layer for multiple AI agents working on the same codebase simultaneously.
Overview
Local MCP server that lets several AI agents coordinate on one codebase by checking in with a task gist and declared files, viewing active peers, and checking…
- What you can do
- Register or update a worker session with a task gist and the files you expect to touch, receiving a worker ID, the coordination protocol and the active peers
- End a session and remove it from the active worker list, optionally with a one-sentence summary
- Read the roster of active workers with their gists, declared files and check-in timestamps, either for the default workspace or an explicit workspace-qualified URI
- Receive roster updates as resource notifications when sessions are committed or removed
- When to use it
- Useful when two or more agents or sessions work on the same repository at once and need to see each other's tasks and file claims before editing. Also handy for a single agent that wants a durable record of what it is working on across restarts.
- Requirements
- Runs locally over stdio (or HTTP) via npx, bunx or Docker; Bun v1.4.3+ or Node.js v24+ for native runs. No API keys or accounts. Agents that should share a roster must use the same SHIFT_WORKSPACE and the same writable SQLite state directory (SHIFT_STATE_DIR, default ~/.local/state/shift-mcp-server) on a local filesystem that supports SQLite locking.
Installation
In SourceWeft
- Open Shift Mcp Server in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
@cyanheads/shift-mcp-server
Lightweight coordination layer for multiple AI agents working on the same codebase simultaneously.
Overview
Coordination layer for multiple AI agents working on the same codebase at once. Check in with a gist of your task and the files you expect to touch, see the full roster of active peers, and check out when finished.
Tools
Resources
The same roster is returned inline by shift_check_in. Modern subscriptions/listen streams receive one update per committed check-in, session update, or actual removal at the workspace-qualified URI; the bare alias is also published for the server's default workspace. Mutations from either protocol era publish through the same server event bus. This framework's legacy delivery adapter requires polling; that limitation is not inherent to the 2025 protocol. Notifications stay within one process; reads always observe committed state from other processes.
Capability reference
shift_check_in tool
- Required
gistplus optionalfiles,workspace, andworkerId(six ASCII letters/digits, case-insensitive) to update a session. IDs are stored and returned uppercase. - Returns your session,
activeWorkers, resolvedworkspace, and qualifiedstatusUri. Updates preserve omitted files and the originalcheckedInAt; an explicit emptyfilesarray clears the declaration. - The coordination protocol and applicable solo-worker notice are delivered once as
noticein structured output and as a text trailer. - An unknown
workerIdfails with reasonunknown_worker(NotFound), a recovery hint, and the current roster.
shift_check_out tool
- Required
workerId(six ASCII letters/digits, case-insensitive), optionalworkspaceand one-sentencesummary. - Returns
removed, resolvedworkspace, qualifiedstatusUri, and the ID/summary. An unknown or already-removed ID succeeds withremoved: falseand points to that roster without guessing why the ID is absent. - Publishes a resource update only when a session actually existed and was removed.
shift://status resource
- Returns
text/markdown— the active-workers table, or "No agents are currently active." when the roster is empty workerIdcomes fromshift_check_in- The bare resource reads the process default workspace. The qualified template reads the exact identifier encoded in its URI.
- Table cells escape backslashes and pipes and flatten CRLF/LF/CR; stored values and structured output remain unchanged.
Features
Built on @cyanheads/mcp-ts-core: stdio and Streamable HTTP transports, pluggable auth (none / jwt / oauth), swappable storage (in-memory, filesystem, Supabase, Cloudflare KV/R2/D1), structured logging with optional OpenTelemetry tracing.
Coordination-specific:
- Per-user SQLite roster shared across processes, isolated by workspace, durable across restarts until explicitly checked out
- The coordination protocol ships in every check-in response, so ground rules reach the agent without client-side configuration
- The active-workers table rides along with every check-in for situational awareness
- Patch semantics on session updates — only the fields provided change
Agent-friendly output:
- Both client surfaces carry the same data —
structuredContentfrom the output schema, markdown fromformat() shift_check_indeclares a typed error contract, so an unknown worker ID arrives withdata.reasonand a recovery hint- Failure responses embed the current roster, so an agent recovers in the same turn instead of calling again to orient
Getting started
Add the following to your MCP client configuration file:
Or with npx (no Bun required):
Or with Docker:
Set the same SHIFT_WORKSPACE and use the same state directory for every agent working together. Native processes for one OS user share ~/.local/state/shift-mcp-server by default. An explicit identifier is opaque and exact-match: my-project and /path/my-project are different namespaces. Native and Docker clients can share a roster by bind-mounting the native state directory into the container instead of using a named volume.
Without SHIFT_WORKSPACE, either transport uses the real path of the enclosing Git worktree root, or the launch cwd outside Git. An empty tool workspace selector uses this default too; nonempty identifiers remain exact. Launching from a subdirectory or symlink converges on the same root. Desktop clients and install badges may launch outside your project: configure SHIFT_WORKSPACE after installation, or pass workspace in every tool call. The Desktop bundle prompts for a workspace. The Codex plugin forwards SHIFT_WORKSPACE and SHIFT_STATE_DIR from your environment; the Claude plugin exposes matching configuration options.
A shared HTTP process uses its own launch directory as the default; multiplexed clients must pass an explicit workspace for their project:
Prerequisites
- Bun v1.4.3 or higher (or Node.js v24+).
- No API keys, accounts, or external services.
Installation
- Clone the repository:
- Navigate into the directory:
- Install dependencies:
- Configure environment:
Configuration
The roster uses SQLite independently of the framework's STORAGE_PROVIDER_TYPE. State persists until check-out; restarting does not clear abandoned sessions. There is no TTL or automatic reaping. Workspace names and worker IDs are coordination selectors, not authentication boundaries.
WAL and BEGIN IMMEDIATE serialize mutations, ID allocation, and the returned roster snapshot. Startup retries SQLite lock contention within one 3-second deadline; a busy mutation also waits at most 3 seconds. Busy, corrupt, or unwritable storage fails visibly without an in-memory fallback. Use a local filesystem supporting SQLite locking for the shared state directory.
See .env.example for the full list of optional overrides.
Running the server
Local development
-
Build and run:
-
Run checks and tests:
Docker
The Dockerfile defaults to HTTP transport, stateless session mode, logs at /var/log/shift-mcp-server, and roster state at /var/lib/shift-mcp-server. Reuse the same writable volume and workspace for every coordinating container. A host bind mount must be writable by the image's bun user. OpenTelemetry peer dependencies are installed by default — build with --build-arg OTEL_ENABLED=false to omit them.
Project structure
Development guide
See CLAUDE.md/AGENTS.md for development guidelines and architectural rules. The short version:
- Handlers throw, framework catches — no
try/catchin tool logic - Use
ctx.logfor request-scoped logging,ctx.statefor tenant-scoped storage - Register new tools and resources in
src/index.ts format()must render every field in the output schema — both client surfaces carry the same data
Contributing
Issues are welcome. Run checks and tests before submitting:
License
Apache-2.0 — see LICENSE for details.
Source: README.md at commit 79d20a6
Tools
0Version history
4- v0.2.0LatestOct 18, 2026
- v0.1.8Oct 7, 2026
- v0.1.7Sep 21, 2026
- v0.1.6Sep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts