How do I use agnt-lock?

1. Click on "Install 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., "@agnt-lock Acquire lock on src/auth.ts for refactoring authentication" 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.

agnt-lock

by codewithriza

Overview Schema Related Servers Score Discussions

TypeScript

Local

The Context Traffic Controller for Multi-Agent Repositories

Stop AI agents from destroying each other's work.

MIT License Build MCP Compatible Node.js TypeScript

Quick Start · How It Works · MCP Config · CLI Usage · Contributing

💥 The Problem: Agentic Collision

You're running multiple AI agents on the same codebase. Maybe Claude Code is refactoring your auth module while Aider is updating your API routes. Everything seems fine until:

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│   🤖 Agent A (Claude Code)          🤖 Agent B (Aider)         │
│   ┌─────────────────────┐          ┌─────────────────────┐     │
│   │ Reading auth.ts...  │          │ Reading auth.ts...  │     │
│   │ Planning refactor   │          │ Planning new routes │     │
│   └────────┬────────────┘          └────────┬────────────┘     │
│            │                                │                   │
│            ▼                                ▼                   │
│   ┌─────────────────────┐          ┌─────────────────────┐     │
│   │ Writing auth.ts...  │          │ Writing auth.ts...  │     │
│   │ ✅ Refactor done!   │          │ ✅ Routes added!    │     │
│   └────────┬────────────┘          └────────┬────────────┘     │
│            │                                │                   │
│            └───────────┐  ┌─────────────────┘                   │
│                        ▼  ▼                                     │
│                 ┌──────────────┐                                │
│                 │  💀 auth.ts  │                                │
│                 │  CORRUPTED   │                                │
│                 │  Build: FAIL │                                │
│                 └──────────────┘                                │
│                                                                 │
│   Agent A's refactor is GONE. Agent B overwrote it.            │
│   Neither agent knows the other existed.                        │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

This is "Agentic Collision" — and it's the #1 reason multi-agent workflows fail silently.

What goes wrong:

🔄 Silent overwrites — Agent B nukes Agent A's changes with zero warning
🧠 Context loss — Each agent hallucinates that it's the only one working
🔁 Infinite loops — Agents "fix" each other's changes back and forth forever
💀 Broken builds — The repo ends up in a state no single agent intended

Related MCP server: asynkor

✅ The Solution: AGNT-LOCK

AGNT-LOCK is a lightweight coordination layer that sits between your AI agents and your repository. It uses the Model Context Protocol (MCP) to give every agent awareness of what other agents are doing.

graph TB
    subgraph Agents
        A[🤖 Claude Code]
        B[🤖 Roo Code]
        C[🤖 Aider]
        D[🤖 Cursor]
    end

    subgraph AGNT-LOCK
        MCP[🔐 MCP Server]
        SM[📋 State Manager]
        IL[📝 Intent Log]
    end

    subgraph Repository
        F1[📄 auth.ts]
        F2[📄 routes.ts]
        F3[📄 config.ts]
    end

    A -->|acquire_lock| MCP
    B -->|acquire_lock| MCP
    C -->|get_repo_state| MCP
    D -->|release_lock| MCP

    MCP --> SM
    SM --> IL
    SM -->|✅ Grant / 🔒 Block| Agents
    SM -.->|tracks| Repository

How it works:

Before editing, an agent calls acquire_lock(filepath, agent_name, intent)
If the file is free → lock is granted, intent is logged
If the file is locked by another agent → request is blocked with details about who holds it and why
After editing, the agent calls release_lock(filepath) to free the file
Any agent can call get_repo_state() to see the full coordination map

🚀 Quick Start

Install

# Clone the repository
git clone https://github.com/codewithriza/AGNT-LOCK.git
cd AGNT-LOCK

# Install dependencies
npm install

# Build
npm run build

Run as MCP Server

# Start the MCP server (stdio transport)
node dist/index.js

Install globally (CLI)

npm install -g .
agnt-lock status

⚙️ MCP Configuration

For Claude Desktop / Claude Code

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "agnt-lock": {
      "command": "node",
      "args": ["/absolute/path/to/AGNT-LOCK/dist/index.js"],
      "env": {}
    }
  }
}

For Cursor

Add to your .cursor/mcp.json:

{
  "mcpServers": {
    "agnt-lock": {
      "command": "node",
      "args": ["/absolute/path/to/AGNT-LOCK/dist/index.js"]
    }
  }
}

For Roo Code (VS Code)

Add to your MCP settings in Roo Code:

{
  "mcpServers": {
    "agnt-lock": {
      "command": "node",
      "args": ["/absolute/path/to/AGNT-LOCK/dist/index.js"],
      "disabled": false,
      "alwaysAllow": ["acquire_lock", "release_lock", "get_repo_state"]
    }
  }
}

💡 Tip: Replace /absolute/path/to/AGNT-LOCK with the actual path where you cloned the repo.

🛠️ MCP Tools

AGNT-LOCK exposes 4 tools via the Model Context Protocol:

Tool	Description
`acquire_lock`	Lock a file before editing. Blocks if already locked by another agent.
`release_lock`	Release a file lock after editing. Commits intent to session history.
`get_repo_state`	Get the full coordination map: active locks, agents, recent activity.
`force_release_all`	Emergency reset: force-release all locks in the repository.

acquire_lock

// Parameters
{
  filepath: "src/auth.ts",        // File to lock
  agent_name: "claude-code",      // Who's locking it
  intent: "Refactoring auth middleware to use JWT"  // Why
}

// Response (success)
{
  "success": true,
  "message": "✅ Lock acquired on \"src/auth.ts\" by \"claude-code\".",
  "lock": {
    "filepath": "src/auth.ts",
    "agent_name": "claude-code",
    "intent": "Refactoring auth middleware to use JWT",
    "acquired_at": "2026-03-15T10:30:00.000Z",
    "expires_at": "2026-03-15T10:45:00.000Z"
  }
}

// Response (blocked)
{
  "success": false,
  "message": "🔒 BLOCKED: File \"src/auth.ts\" is locked by agent \"aider\"...",
  "blocked_by": { ... }
}

get_repo_state

📊 AGNT-LOCK Repository State
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Session: session_20260315_a3f8k2
Active Locks: 2
Active Agents: claude-code, aider

🔒 Locked Files:
  • src/auth.ts → claude-code (intent: "Refactoring auth middleware")
  • src/routes.ts → aider (intent: "Adding new API endpoints")

📝 Recent Activity:
  🔐 claude-code → acquire "src/auth.ts"
  🔐 aider → acquire "src/routes.ts"
  🔓 roo-code → release "src/config.ts"

💻 CLI Usage

AGNT-LOCK also includes a CLI for manual coordination and debugging:

# Check repository coordination state
agnt-lock status

# Manually lock a file
agnt-lock lock src/index.ts my-agent "Updating the main entry point"

# Release a lock
agnt-lock unlock src/index.ts my-agent

# Emergency: release all locks
agnt-lock reset

# Start MCP server from CLI
agnt-lock serve

📁 Project Structure

AGNT-LOCK/
├── src/
│   ├── index.ts          # MCP server entry point (stdio transport)
│   ├── server.ts         # MCP tool definitions (acquire, release, state)
│   ├── state-manager.ts  # Core .agentlock state engine
│   └── cli.ts            # Color-coded CLI dashboard
├── tests/
│   └── state-manager.test.ts  # Vitest unit tests (9 tests)
├── website/              # Next.js + Tailwind landing page
│   ├── app/
│   │   ├── page.tsx      # Dark-mode landing page
│   │   ├── layout.tsx    # Root layout with metadata
│   │   └── globals.css   # Tailwind + custom styles
│   └── package.json
├── dist/                 # Compiled JavaScript (after build)
├── .agentlock/           # Runtime state directory (auto-created, gitignored)
│   └── state.json        # Current locks & intent log
├── vitest.config.ts      # Test configuration
├── package.json
├── tsconfig.json
├── LICENSE               # MIT
└── README.md

🔒 How the Lock System Works

┌──────────────────────────────────────────────────────────────┐
│                    .agentlock/state.json                      │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  active_locks: {                                             │
│    "src/auth.ts": {                                          │
│      agent_name: "claude-code",                              │
│      intent: "Refactoring auth middleware",                  │
│      acquired_at: "2026-03-15T10:30:00Z",                   │
│      expires_at: "2026-03-15T10:45:00Z"    ← Auto-expiry    │
│    }                                                         │
│  }                                                           │
│                                                              │
│  intent_log: [                                               │
│    { agent: "roo-code", action: "acquire", file: "..." },   │
│    { agent: "roo-code", action: "release", file: "..." },   │
│    { agent: "claude-code", action: "acquire", file: "..." } │
│  ]                          ↑ Rolling log (max 500 entries)  │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Key Design Decisions:

File-level locking — Granular enough to allow parallel work, broad enough to prevent conflicts
15-minute TTL — Locks auto-expire to prevent deadlocks from crashed agents
Intent logging — Every lock/unlock is logged with why the agent needed the file
Zero external dependencies — State is a single JSON file, no database required
Ownership verification — Only the locking agent (or force-release) can unlock a file

🤝 Contributing

Contributions are welcome! Here's how to get started:

# Fork and clone
git clone https://github.com/YOUR_USERNAME/AGNT-LOCK.git
cd AGNT-LOCK

# Install dependencies
npm install

# Build
npm run build

# Test the CLI
node dist/cli.js status

Ideas for contributions:

🌐 HTTP/SSE transport (for remote agent coordination)
📊 Web dashboard for visualizing lock state
🔔 Webhook notifications when locks are contested
🧪 Test suite
📦 npm package publishing
🐳 Docker container

Available Tools

4 tools

acquire_lockA

Acquire an exclusive lock on a file before editing. Prevents other AI agents from modifying the same file simultaneously. Returns lock status and blocker info if already locked.

ParametersJSON Schema

Name	Required	Description
`intent`	Yes	Brief description of what the agent plans to do with this file (e.g., 'Refactoring the auth middleware')
`filepath`	Yes	Relative path to the file to lock (e.g., 'src/index.ts')
`agent_name`	Yes	Name of the AI agent requesting the lock (e.g., 'claude-code', 'aider', 'roo-code')

TDQS

A4.2/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 discloses the exclusive nature of the lock, the concurrency prevention behavior, and what happens if already locked ('Returns lock status and blocker info if already locked'). It does not cover lock duration or release requirements, but the key behavioral traits are conveyed.

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 and 37 words, with the primary action and purpose in the first sentence and the return/blocker behavior in the second. Every sentence earns its place with no redundancy or filler.

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?

For a simple lock-acquisition tool with fully documented parameters and no output schema, the description adequately explains the purpose, exclusivity, and blocker-related return info. It could mention lock release or lifecycle, but the sibling tool release_lock implies the pattern, making the description sufficiently complete for an agent.

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

Parameters3/5

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

The input schema already provides 100% coverage with descriptions for all three parameters (filepath, agent_name, intent). The tool description adds no parameter-specific information, so the baseline of 3 applies.

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 action: 'Acquire an exclusive lock on a file before editing.' It uses a specific verb (acquire) and resource (a file) and distinguishes itself from siblings like release_lock and force_release_all by focusing on acquiring the lock initially.

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?

The description provides clear context: use it 'before editing' to 'prevent other AI agents from modifying the same file simultaneously.' It does not explicitly name alternatives or exclusions, but the purpose is well-scoped relative to sibling tools.

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

force_release_allA

Emergency: Force-release ALL active locks. Use only when agents are stuck or locks are stale. This will free every locked file in the repository.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool force-releases all locks, which is a broad and forceful action, but it doesn't mention potential side effects like disrupting active lock holders, whether the operation is reversible, or any permission requirements. The description is adequate but not deeply transparent about consequences.

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, with the first sentence serving as an immediate, urgent call to action ('Emergency: Force-release ALL active locks') and the second clarifying the scope. Every word earns its place—there is no redundancy or filler.

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?

For a simple, zero-parameter emergency tool, the description covers what it does, when to use it, and its all-encompassing scope. It could add a caution about irreversibility or impact on other agents, but given the simplicity and the emergency context, it is mostly complete.

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?

The tool has zero parameters, so the schema is empty and coverage is trivially 100%. The description confirms that no input is needed because it operates on all locks. This aligns with the baseline of 4 for zero-parameter tools.

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 that the tool force-releases ALL active locks, freeing every locked file in the repository. This distinguishes it from sibling tools like release_lock (which targets a specific lock) and acquire_lock. The scope is unambiguous and the verb 'force-release' is specific.

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?

The description explicitly limits usage to emergency scenarios: 'Use only when agents are stuck or locks are stale.' This provides a clear trigger condition and implies normal lock releases should use release_lock instead, though it doesn't name the alternative explicitly. The 'Emergency:' prefix reinforces the exceptional nature of this tool.

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

get_repo_stateA

Get the current coordination state of the repository. Shows all active locks, which agents are working, and recent intent history. Use this before starting work to understand what other agents are doing.

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 clearly conveys a read-only, informational behavior by saying 'Get' and 'Shows', and provides useful context about the state contents. It does not mention edge cases like staleness or failures, but for a simple state query this is adequate.

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, front-loaded with the core purpose and followed by a practical usage note. Every sentence earns its place with no redundancy.

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 the tool's simplicity (zero parameters, no output schema), the description fully covers what the tool returns, its content, and when to use it. The sibling tools are all mutating lock operations, so the read-only nature is clear in context.

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?

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific details, but none are needed since the schema already confirms no inputs exist.

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 uses the specific verb 'Get' with the resource 'current coordination state of the repository' and lists concrete contents (active locks, working agents, intent history). It clearly distinguishes this read-only state inspection from the sibling mutation tools (acquire_lock, release_lock, force_release_all).

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 states when to use: 'Use this before starting work to understand what other agents are doing.' This provides a clear usage context and implicitly differentiates it from the lock-manipulation siblings.

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

release_lockA

Release a previously acquired lock on a file. Call this after finishing edits to allow other agents to work on the file. The intent is committed to session history.

ParametersJSON Schema

Name	Required	Description	Default
`filepath`	Yes	Relative path to the file to unlock
`agent_name`	No	Optional: name of the agent releasing the lock (for ownership verification)

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It adds context that 'The intent is committed to session history' and implies the lock is released, but it does not disclose potential failure modes, ownership checks, or side effects beyond the intent being logged.

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 three sentences with no fluff: purpose, usage guidance, and a behavioral note. Each sentence earns its place and the structure front-loads the core purpose.

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?

For a simple lock-release tool, the description covers the core function, when to call it, and a behavioral side effect. It does not cover error cases or the optional agent_name parameter, but these are reasonably handled by the schema and the tool's simplicity.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema for parameters; it does not mention agent_name or provide additional detail about filepath that is not already in the 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?

The description clearly states the action ('Release') and the resource ('a previously acquired lock on a file'). It distinguishes from siblings by focusing on a single file lock, which contrasts with force_release_all and acquire_lock.

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?

The description provides explicit timing: 'Call this after finishing edits to allow other agents to work on the file.' This gives clear usage context but does not mention alternatives or when not to use (e.g., force_release_all).

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. Dates show when Glama detected each change.

4 tool updatesv1.0.0Aug 9, 2026
- First observedacquire_lock
- First observedforce_release_all
- First observedget_repo_state
- First observedrelease_lock

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: acquiring, releasing, viewing state, and emergency release. The only potential overlap is between release_lock and force_release_all, but their scopes (single vs. all) and contexts (normal vs. emergency) make them unambiguous.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: acquire_lock, release_lock, get_repo_state, force_release_all. The verbs and nouns are descriptive and match their functionality, making the set predictable and coherent.

Tool Count5/5

With 4 tools, the server is well-scoped for a lock management purpose. Each tool covers a necessary operation without redundancy, and the count falls comfortably within the ideal 3-15 range.

Completeness4/5

The server covers the full lock lifecycle: acquire, release, query state, and emergency cleanup. The only minor gap is a lack of a per-file lock check endpoint, but get_repo_state provides sufficient visibility into lock status.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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
LTD MCP
io.github.Eshller
Project management MCP for AI agents with safe task reads and writes.
Project Management Agent Orchestration
12
Tokenmaxxing
io.github.Brock-Denton
Coordinate coding agents through MCP using existing AI plans, saved work, and independent checks.
Agent Orchestration Coding Agents Autonomous Agents
1
Sunaiva Gate — Agent Rule Enforcement A
io.sunaivacore
MCP enforcement layer that intercepts AI agent actions and blocks rule violations before execution.
Security Autonomous Agents
162

Related MCP Servers

mcp-coordinator
Agent Orchestration Autonomous Agents
swoofer
A
license
Not graded
quality
A
maintenance
Prevents AI coding agents from conflicting by coordinating file claims and resolving conflicts in real-time across multiple sessions.
Updated 3 days ago (2026-09-02 23:16 UTC)
336
1
MIT
asynkorofficial
Agent Orchestration Developer Tools
asynkor
A
license
Not graded
quality
D
maintenance
Coordination layer for AI coding agents working on the same codebase. Adds file locks, shared project memory, and cross-machine file sync so Claude Code, Cursor, Windsurf, and other MCP agents stop overwriting each other.
Updated 4 months ago (2026-05-03 08:23 UTC)
50
Apache 2.0
lalanoo-protocol
Agent Orchestration Developer Tools
MacXhi
A
license
Not graded
quality
C
maintenance
Enables multi-agent coordination with file locking, shared registry, async messaging, and architectural decision logging via MCP tools.
Updated 2 months ago (2026-07-15 21:46 UTC)
MIT
AgentSync MCP Server
Agent Orchestration Project Management Developer Tools
dipakkr
A
license
Not graded
quality
B
maintenance
Provides MCP tools for AI coding agents to coordinate on shared repositories, enabling task claiming, conflict detection, and plan management in real-time.
Updated a month ago (2026-08-08 14:35 UTC)
11
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/codewithriza/AGNT-LOCK'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

The Context Traffic Controller for Multi-Agent Repositories

💥 The Problem: Agentic Collision

What goes wrong:

✅ The Solution: AGNT-LOCK

How it works:

🚀 Quick Start

Install

Run as MCP Server

Install globally (CLI)

⚙️ MCP Configuration

For Claude Desktop / Claude Code

For Cursor

For Roo Code (VS Code)

🛠️ MCP Tools

acquire_lock

get_repo_state

💻 CLI Usage

📁 Project Structure

🔒 How the Lock System Works

Key Design Decisions:

🤝 Contributing

Ideas for contributions:

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

asynkorofficial

Latest Blog Posts

MCP directory API