Airlock MCP Server

Local daemon giving AI agents named locks, shared state, events, and a task queue over MCP.

Local serverstdioGo

What is the Airlock MCP server?

Airlock MCP server is a locally run integration for AI assistants that speak the Model Context Protocol. Local daemon giving AI agents named locks, shared state, events, and a task queue over MCP.

What you get

Named resource locks, atomic shared state, presence, events, and a task queue for AI agents — exposed over a local HTTP MCP server that's always running, so any session, terminal, or CI job can coordinate with any other. Cross-platform Go daemon, SQLite-backed, with real blocking waits — no more poll loops.

Setting it up

Setup follows the usual MCP pattern — install or clone the server, register it in your client's configuration file, restart the client.

What the assistant can call

Once Airlock is connected, these are the calls the assistant has available:

  • Verify — The Verify tool exposed by this server
  • Locks — wait_seconds is the coordination-by-default knob: pass it (up to 50) and lock_resource blocks server-side until the lock frees, instead of
  • Presence — The Presence tool exposed by this server
  • Events — Events are generation-counted, not latched: pass back the generation you last saw and a signal that fired between calls is never missed
  • Tasks — A claim is a lease: if the claimant doesn't complete_task/fail_task within lease_seconds, the task auto-requeues for another consumer — no work

Configuration and credentials

You will need one environment variable: AIRLOCK_TOKEN. The server will not start without them, which is usually why the tools fail to appear on a first run. Keep credentials in your client's env block or a secrets manager rather than in a file you might commit.

Before you rely on it

  • It runs with your machine's permissions. That is convenient and also the reason to think about what you point it at before you approve a tool call.
  • Missing credentials fail quietly in some clients — if no tools show up, check the environment block first.
  • MCP clients confirm each tool call by default. Leave that on until you have watched what the airlock mcp server does with a few real requests.

Choosing this one

Plenty of planning and project tracking servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. Airlock's toolset — Verify, Locks, Presence and 2 more — is a fair guide to whether it matches your workflow. It is maintained by adamorad; worth a glance at recent repository activity before you build anything load-bearing on it.

We check each listing at SyncDev against the project's documentation before it goes live — if something here drifts out of date, it is a bug worth reporting.

Available tools

ToolWhat it does
VerifyThe Verify tool exposed by this server.
Lockswait_seconds is the coordination-by-default knob: pass it (up to **50**) and lock_resource **blocks** server-side until the lock frees, instead of returning locked:false immediately. The cap stays under Claude Code's 60s
PresenceThe Presence tool exposed by this server.
EventsEvents are **generation-counted**, not latched: pass back the generation you last saw and a signal that fired between calls is never missed.
TasksA claim is a **lease**: if the claimant doesn't complete_task/fail_task within lease_seconds, the task auto-requeues for another consumer — no work is lost to a crashed worker. The lease_token from claim_next_task is the

Configuration

VariableDescriptionRequired
AIRLOCK_TOKENCredential the server authenticates with.Yes

Example prompts to try

  • Use Airlock to Verify.
  • Use Airlock to Locks.
  • Use Airlock to Presence.

Frequently asked questions

It connects Airlock to MCP-compatible AI assistants such as Claude and Cursor, exposing 5 tools (Verify, Locks, Presence, and more) that the assistant can call on your behalf. Instead of copying data back and forth by hand, the assistant works with Airlock directly.