How do I use mcp-mcp-locks?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-mcp-locks claim browser profile playwright1" 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.

mcp-mcp-locks

by mattbaylor

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

mcp-mcp-locks

An MCP server that wraps the mcp-locks CLI, exposing its coordination primitives as native MCP tools.

Use case: Multiple AI agents (across OpenCode, Claude Code, devcontainer/sandboxed runtimes, etc.) need to coordinate access to MCP instances that hold exclusive OS resources — Playwright Chromium profile dirs, the figma-desktop port, any future single-resource MCP server. mcp-locks solves this via a host-global state file and a small bash CLI. This server makes its operations discoverable in every MCP client's tool surface, so an agent that's been told "use Playwright instance X" can also see claim/release as first-class tools rather than something to remember to shell out to.

Why a wrapper?

The mcp-locks CLI works fine from a shell. But rules like "agents must claim before using" have been re-discovered as broken across many sessions because the agent has to know the convention exists and remember to invoke it. Exposing the operations as MCP tools puts them directly in the agent's function roster — claim/release/list/who become discoverable the same way playwright_browser_navigate is. Discoverability is the highest-leverage fix for "agent forgot the convention."

This server is thin by design: every tool shells out to mcp-locks --json and returns the structured envelope. State, locking, owner detection, and reaping all stay owned by the upstream binary (single source of truth).

Related MCP server: WEATHGARDS

Prerequisites

Node.js 20+
mcp-locks installed and on PATH (or its path passed via the MCP_LOCKS_BIN env var). The wrapper requires a version that supports --json output.

Install

git clone https://github.com/mattbaylor/mcp-mcp-locks.git
cd mcp-mcp-locks
npm install
npm run build

Configure your MCP client

OpenCode (`opencode.json` or `opencode.jsonc`)

{
  "mcp": {
    "mcp-locks": {
      "type": "local",
      "command": ["node", "/path/to/mcp-mcp-locks/dist/index.js"],
      "enabled": true
    }
  }
}

Claude Code (`.claude.json`)

{
  "mcpServers": {
    "mcp-locks": {
      "type": "stdio",
      "command": "node",
      "args": ["/path/to/mcp-mcp-locks/dist/index.js"]
    }
  }
}

Custom `mcp-locks` binary location

If mcp-locks is not on the spawned process's PATH (common in sandboxed agent runtimes with minimal env), set MCP_LOCKS_BIN:

{
  "mcp": {
    "mcp-locks": {
      "type": "local",
      "command": ["node", "/path/to/mcp-mcp-locks/dist/index.js"],
      "enabled": true,
      "environment": {
        "MCP_LOCKS_BIN": "/Users/you/bin/mcp-locks"
      }
    }
  }
}

Tools

Tool	Purpose
`list`	Array of all registered instances with current status, owners, TTLs
`who`	Detail on a single instance (free / claimed / expired / dead_pid)
`claim`	Acquire or refresh a lock (default 30m TTL); auto-detects owner
`release`	Release a claim; owner-checked unless `force: true`
`reap`	Clean up expired claims, dead-PID claims, orphaned Chromium, stale SingletonLocks
`doctor`	Health report; recommends reap when needed
`kill`	Kill Playwright-MCP Chromium processes on demand (`mode: 'orphans' \| 'all' \| 'instance'`, plus `safety: 'idle-only' \| 'force'` for `all` mode). Per-instance kill is not implemented in v1.

Every tool returns the upstream mcp-locks --json envelope augmented with exitCode and (if present) stderr:

// success
{ "ok": true, "data": { ... }, "exitCode": 0 }

// denied
{ "ok": false, "error": "denied", "denied": { ... }, "exitCode": 2 }

Typical agent flow

1. agent calls list           -> sees which instances are free
2. agent calls claim          -> ok:true; agent proceeds with the corresponding browser tools
3. agent does its work
4. agent calls release        -> ok:true

For conflict cases:

1. agent calls claim playwright2
2. response: { ok: false, error: "denied", denied: { current_owner: "...", ttl_remaining_seconds: 1200 } }
3. agent either: claims a different instance, waits, or asks the human whether to force-steal

Sub-agent pattern

When dispatching a sub-agent to do parallel work:

Parent claims the instance and passes the assigned name to the sub-agent
Sub-agent uses the assigned instance's browser tools (e.g. playwright3_browser_*)
Sub-agent does NOT call claim or release — the parent owns the lifecycle

This avoids the sub-agent's claim expiring mid-work due to a TTL shorter than the parent's task.

How it relates to `mcp-locks`

This server is one of several possible interfaces to the underlying coordination layer. Other valid callers:

The mcp-locks CLI directly from a shell or script
Any tool reading the state file at ~/.local/state/mcp-locks/state.json (read-only; never write)
CI scripts that gate execution on a lock

All callers share the same state and the same concurrency guarantees — this wrapper doesn't add a second source of truth.

License

MIT

Available Tools

6 tools

claimA

Acquire (or refresh) a lock on an MCP instance. Returns ok:true with action=claimed (fresh) or refreshed (same owner re-claiming). If another owner holds the lock, returns ok:false with error=denied and details about the current owner — pick a different instance or pass force=true to steal (use sparingly; the current holder will get unexpected behavior). Owner is auto-detected from the calling session (OpenCode run ID, Claude Code session ID, or shell PPID); pass explicit owner to override. Default TTL is 30 minutes.

ParametersJSON Schema

Name	Required	Description
`ttl`	No	How long to hold the claim. Format: <number><unit> where unit is s/m/h, e.g. '30m', '2h', '45s'. Raw integers are interpreted as seconds. Defaults to 30m.
`note`	No	Free-form note attached to the claim, visible in list/who output. Useful for explaining why a long claim is held (e.g. 'PR #123 side-by-side comparison').
`force`	No	Steal the lock from its current owner. The displaced owner is not notified and will get DENIED on its next operation. Use only with good reason.
`owner`	No	Explicit owner identifier. Omit to let mcp-locks auto-detect from the calling session's env vars. Pass to coordinate with a non-MCP caller or to take ownership on behalf of a different session.
`instance`	Yes	Instance name to claim (e.g. 'playwright2').

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: return values, error states, auto-detection of owner, TTL default, force stealing consequences. No surprises.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with front-loaded purpose. Slightly verbose but each sentence adds value. Could be trimmed without loss.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, covers return values and errors. For a tool with 5 parameters and moderate complexity, description is thorough and actionable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters, but description adds crucial context: owner auto-detection, TTL format and default, note usage, force caution. Significantly enriches schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it acquires or refreshes a lock on an MCP instance. Distinguishes from sibling tools like 'release' and 'list' by specifying the lock management action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly explains when to use (first claim, refresh) and when not to (if denied, pick another instance or use force). Provides guidance on force usage sparingly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

doctorA

Report the health of mcp-locks: state file paths, active claim count, expired claims, dead-PID claims, Chromium process and SingletonLock counts, and whether reap is recommended. Use this for diagnostics when claims aren't behaving as expected, or as a quick liveness check.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must carry burden. It details what information is reported, implying read-only behavior. However, it does not explicitly state that no state is modified, which would enhance transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and specific output items. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description thoroughly lists all reported metrics, making the tool's purpose and output clear for diagnostic use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so baseline of 4 applies. The description appropriately focuses on output details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reports health of mcp-locks, listing specific metrics like state file paths and claim counts. It distinguishes itself from sibling tools like 'claim' or 'reap' which are mutative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit usage guidance is given: 'Use this for diagnostics when claims aren't behaving as expected, or as a quick liveness check.' It does not mention when not to use or alternative tools, but the context implies this is the diagnostic choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

listA

List all registered MCP instances and their current claim status. Returns an array of records: each includes instance name, owner (or null if free), owner_pid, claimed_at, expires_at, note, age_seconds, ttl_remaining_seconds, alive (PID liveness), and status (free|claimed|expired|dead_pid). Use this to see what's available before claiming.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so description carries full burden. It fully describes the output structure (instance name, owner, status fields) and implies a read-only operation. No behavioral contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no redundancy. First sentence states purpose and output details; second sentence provides usage guidance. Every word contributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no output schema, the description fully explains what the tool returns and when to use it. No gaps are present; it is self-contained and complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, and schema coverage is 100% vacuously. Description adds value by detailing the output fields, which is not in the schema. Baseline for 0 params is 4, but the extra context justifies a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'List all registered MCP instances and their current claim status', specifying the verb 'list' and resource 'MCP instances'. It also distinguishes from siblings like 'claim' by implying this tool is for viewing availability before claiming.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit usage guidance is given: 'Use this to see what's available before claiming.' This clearly indicates when to use it (before claiming) and differentiates from sibling tools like 'claim' and 'who'. It lacks explicit when-not-to-use but is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reapA

Clean up expired claims, dead-PID claims (for session-based owners), orphaned Chromium processes from prior MCP runs, and stale SingletonLock files. Idempotent — safe to call any time. Returns counts of what was cleaned up. Run this if doctor reports reap_recommended=true, or after a client crash leaves locks/processes behind.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It states the tool is idempotent and safe, and returns counts. While it does not mention permissions or side effects beyond cleanup, the behavioral traits are well disclosed for a cleanup operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded: three sentences cover what it does, its safety, and when to use it. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no output schema, the description fully covers the tool's purpose, usage, and behavior. It is complete for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the baseline is 4. The description does not add parameter information because none exist, but schema coverage is 100%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'clean up' and lists specific resources: expired claims, dead-PID claims, orphaned Chromium processes, and stale SingletonLock files. It distinguishes from sibling tools like 'claim' and 'doctor' by focusing on cleanup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use the tool: 'Run this if doctor reports reap_recommended=true, or after a client crash leaves locks/processes behind.' It also notes it is idempotent and safe to call any time, providing clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

releaseA

Release a previously-claimed lock so other sessions can claim it. Returns ok:true with action=released (or already_free if it wasn't claimed). If the lock is owned by someone else, returns ok:false with error=owner_mismatch — pass force=true to override (rare; usually a sign you should let the real owner finish). Owner is auto-detected the same way as claim.

ParametersJSON Schema

Name	Required	Description
`force`	No	Release even if the lock is owned by a different session. Use only when you know the actual owner is gone and cleanup didn't happen automatically.
`owner`	No	Explicit owner identifier. Omit to let mcp-locks auto-detect. Must match the current owner unless force=true.
`instance`	Yes	Instance name to release (e.g. 'playwright2').

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description fully discloses return values (ok:true with action=released or already_free), error conditions (owner_mismatch), and force behavior. Also notes idempotency via 'already_free'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no unnecessary words. Every sentence adds essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains return values and errors fully. Covers all relevant behaviors for a lock release tool, making it self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions, but description adds meaningful context: auto-detection of owner, force usage advice, and example error conditions, providing added value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'release' and the resource 'a previously-claimed lock', and distinguishes itself from siblings like 'claim' by explaining the effect on other sessions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly warns against using force=true except in rare cases, and explains auto-detection of owner. Provides guidance on when not to force and what errors indicate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

whoA

Get detail on a single MCP instance: who owns it, when it was claimed, how much TTL remains, and whether the owning PID is still alive. Exit code 0 if owned, 1 if free, 2 if the instance name is not registered. Useful before claiming to decide whether to wait, pick a different instance, or force-steal.

ParametersJSON Schema

Name	Required	Description	Default
`instance`	Yes	Instance name as registered in mcp-locks (e.g. 'playwright', 'playwright2', 'figma-desktop'). Use the `list` tool to discover registered instances.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description fully carries the burden. It discloses that the tool returns exit codes indicating ownership status, reveals the information returned (owner, TTL, PID liveness), and implies no side effects (read-only). This is comprehensive for a status-check tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, each sentence carrying distinct information: the first explains what the tool returns, the second explains its utility and exit codes. No wasted words; all content earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a simple read tool with one parameter and no output schema. Exit codes are explained, and the usage context is clear. However, it could optionally specify the output format more explicitly (e.g., JSON fields), but the current level suffices.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes the 'instance' parameter well (100% coverage), but the description adds value by explaining the format ('as registered in mcp-locks') and referencing the 'list' tool for discovery, which improves usability beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'get detail' and the resource 'single MCP instance', listing specific attributes (owner, claim time, TTL, PID liveness). It distinguishes itself from siblings like 'list' (which discovers instances) and 'claim' (which acquires ownership).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises using this tool before claiming to decide whether to wait, pick a different instance, or force-steal. It also explains exit codes, which helps the agent interpret the result and decide next actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.1.0Jun 30, 2026
- First observedclaim
- First observeddoctor
- First observedlist
- First observedreap
- First observedrelease
- First observedwho

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.8/5.0

Scored 2026-06-30 13:15 across 6 tools

Disambiguation5/5

Each tool has a distinct purpose: claim/release manage locks, list/who provide overview vs. detail, doctor diagnoses health, and reap cleans up. No functional overlap.

Naming Consistency5/5

All tool names are single verbs (claim, doctor, list, reap, release, who), forming a consistent pattern. The use of 'doctor' as a verb is unconventional but fits the uniformity.

Tool Count5/5

Six tools cover the full lifecycle of lock management without being excessive. Each tool adds clear value, and the count is well-scoped for the domain.

Completeness5/5

The set includes claim, release, list, inspect (who), diagnose (doctor), and cleanup (reap). Refresh is built into claim, and force options handle edge cases. No obvious gaps.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

llm-busOAuth
com.llm-bus
Coordinate multiple AI agents over MCP: atomic claims, leases, shared ledger, handoffs, tasks.
Agent Orchestration Autonomous Agents
29
mcp
com.skopik
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Agent Orchestration Knowledge & Memory Search
2
Singularity - MCP Discovery & Security Gateway A
io.github.gaurav-kumar-sinha-060705
Find, vet, and run MCP tools through a secure audited gateway with prompt-injection risk scoring
311
llm-orchestration-agent-mcp
ai.getvda
LLM Orchestration Agent (Mcp)
Agent Orchestration Autonomous Agents
1

Related MCP Servers

claude-cli-mcp
Coding Agents Code Execution Autonomous Agents
nayagamez
A
license
A
quality
D
maintenance
Wraps Anthropic Claude Code CLI as tools, allowing MCP clients to invoke headless Claude Code sessions.
Updated 5 months ago (2026-04-23 09:54 UTC)
2
972 npm
MIT
WEATHGARDS
Virtualization OS Automation Monitoring
liambuild
F
license
Not graded
quality
D
maintenance
Exposes MCP tools that enable remote LLMs to query local Docker containers, OS processes, and system services in real time.
Updated 3 months ago (2026-06-04 21:45 UTC)
-
agnt-lock
Autonomous Agents Developer Tools
codewithriza
A
license
A
quality
D
maintenance
Prevents AI agents from overwriting each other's work by providing file locking and coordination via MCP tools.
Updated 5 months ago (2026-04-21 11:42 UTC)
4
1
MIT
1Password Agent Bridge
Security Developer Tools
gambadio
A
license
Not graded
quality
A
maintenance
Provides MCP tools for AI agents to securely access approved 1Password logins via encrypted handles, resolving secrets locally through the 1Password CLI without exposing plaintext passwords.
Updated 3 days ago (2026-09-12 10:59 UTC)
206 npm
MIT

mcp-mcp-locks

Why a wrapper?

Prerequisites

Install

Configure your MCP client

OpenCode (opencode.json or opencode.jsonc)

Claude Code (.claude.json)

Custom mcp-locks binary location

Tools

Typical agent flow

Sub-agent pattern

How it relates to mcp-locks

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

OpenCode (`opencode.json` or `opencode.jsonc`)

Claude Code (`.claude.json`)

Custom `mcp-locks` binary location

How it relates to `mcp-locks`