What can you do with this server?

The agora server provides a shared, persistent space for Claude Code sessions within a repository to coordinate work, detect conflicts, log activities, and facilitate communication. * Resume project (resume_project): Get a full summary of active sessions, recent activity, file/branch collisions, and unread notes — ideal for quickly catching up when starting or resuming a session. * See who is active (who_is_here): List all currently active sessions and the specific files each one is touching, giving a live view of parallel work in the repo. * Activity log (activity_log): View a filterable timeline of all repository events, with options to filter by time window (in minutes) or by a specific session ID. * Check for collisions (check_collision): Before editing files or switching branches, check whether another active session is already working on the same files or branch, helping you avoid overwriting others' work. * Leave a note (leave_note): Send a message to a specific session or broadcast it to all active sessions, enabling asynchronous communication between Claude Code instances. * Read notes (read_notes): Retrieve notes addressed to a specific session (or broadcast notes), with the option to filter for unread-only, and automatically mark them as read.

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., "@agora who is here and what are they doing?" 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.

agora

by vorluno

Overview Schema Related Servers Score Discussions

TypeScript

Local

agora

A shared, persistent space for your Claude Code sessions — per repository.

See what other sessions are doing, get warned before you overwrite their work, and leave notes. No daemon, no server to run.

License: MIT Bun Model Context Protocol Built with Claude Code

Why

When several Claude Code sessions work on the same repository — in parallel, or just over the course of a day — they're blind to each other. None of them knows what the others touched, they overwrite the same files silently, and the context is lost when you close them.

agora gives every session a shared place to leave a trail and look at each other's work.

Related MCP server: Blackboard MCP

How it works

The whole system is one SQLite file per repo: <repo-root>/.agora/space.db (in WAL mode, so multiple processes read and write it at once without corruption).

No one runs a server. There's no daemon, no web app. The "space" is the file.
Every session of the repo writes what it does and reads what the others did.
Because it's a file, it persists by itself — close everything, come back tomorrow, the state is still there.
It's a shared board, not a live chat: sessions find out when they start, when they're about to edit (collision), or when they ask (the tools).

Multi-worktree friendly: the .db lives at the main repo root, so every session of the repo — including those in different worktrees — shares one agora.

Features

🟢 See who's here and what files each session is touching, live.
⚠️ Collision warnings — before you edit a file (or work a branch) another active session already holds.
📋 Project resume — open a session and get a summary of what the others did.
📓 Activity log — a per-repo timeline of everything that happened.
✉️ Notes between sessions (directed or broadcast).
🛡️ Best-effort hooks — they exit 0 no matter what; they never block your session.

Requirements

Bun 1.3+
git 2.x
Claude Code (or any MCP client)

Installation

git clone https://github.com/vorluno/agora-mcp.git
cd agora-mcp
bun install

# Install the 5 hooks (idempotent). Add --project to scope to the current repo only.
bun run src/cli.ts init

# Register the MCP server
claude mcp add agora -- bun run /absolute/path/to/agora-mcp/src/index.ts

Configuration

Any MCP client works. The mcpServers entry:

{
  "mcpServers": {
    "agora": {
      "command": "bun",
      "args": ["run", "/absolute/path/to/agora-mcp/src/index.ts"]
    }
  }
}

For Claude Code, claude mcp add (above) writes this for you. For Warp or Cursor, paste the snippet into their MCP settings.

Tools

Tool	Description
`resume_project`	Summary of the agora: active sessions, recent activity, collisions, unread notes.
`who_is_here`	Active sessions and which files each one is touching.
`activity_log`	The repo's event log, filterable by time/session.
`check_collision`	Is another active session touching these files or this branch?
`leave_note`	Leave a note for another session (or broadcast to all).
`read_notes`	Read notes addressed to a session (marks them read).

How collisions are detected

File collision: 2+ distinct sessions with an active writing claim on the same file.
Branch collision: 2+ active sessions on the same branch but in different worktrees.

Only live sessions are counted, so a session that died without a clean exit won't produce false positives.

Automatic capture (hooks)

init installs 5 best-effort hooks (they always exit 0):

Hook	What it does
`SessionStart`	Registers the session and injects the agora summary into your context (also fires on `/resume` and after a context compaction).
`PostToolUse` (Edit/Write)	Records the file claim + event; warns if a new collision appears.
`PreToolUse` (Edit/Write)	Warns you before editing if another session already holds the file.
`Stop` / `SessionEnd`	Marks the session idle / stopped and releases its claims.

Development

bun test          # full suite (incl. a real WAL concurrency test)
bunx tsc --noEmit # type-check

Built test-first across 14 TDD tasks with per-task and whole-branch review.

License

Built by Vorluno — a software studio from Panamá 🇵🇦

Part of the mcp-s family of MCP servers.

Available Tools

6 tools

activity_logActivity logC

Bitácora de eventos del repo (filtrable por minutos/sesión).

ParametersJSON Schema

Name	Required	Description	Default
`sinceMinutes`	No
`sessionId`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`events`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the burden. It only states this is a log and filterable, but does not disclose any behavioral traits such as read-only nature, rate limits, or what events are included.

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?

The description is a single sentence that efficiently conveys the tool's purpose and key filtering capability. No wasted words, though it could be more informative without losing conciseness.

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

Completeness2/5

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

Given the tool has 3 optional parameters and an output schema, the description lacks crucial details like what the event log contains, how filtering interacts, and default behavior for missing parameters. It is too minimal to fully guide 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?

With 0% schema description coverage, the description partially compensates by mentioning filterability by minutes and session, which maps to sinceMinutes and sessionId. However, the 'limit' parameter is not addressed, and no details on parameter types or constraints are given.

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

Purpose4/5

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

The description clearly states it retrieves an event log from the repo, filterable by minutes or session. This distinguishes it from sibling tools that deal with collisions, notes, resume, etc. However, the verb is implicit and could be more explicit.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives or any prerequisites. The description gives no context about typical use cases or exclusions.

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

check_collisionCheck collisionC

¿Otra sesión activa está tocando estos archivos o esta rama?

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	No
`paths`	Yes
`branch`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`fileConflicts`	Yes
`branchCollisions`	Yes
`ok`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description should disclose behavioral traits. It only asks about collision existence but does not mention whether the tool is read-only, if it requires permissions, or what happens on collision. The existence of an output schema is not leveraged in the description.

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

Conciseness3/5

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

The description is one sentence, which is concise. However, it is overly minimal and lacks structure; it reads as a question rather than a clear directive. While not verbose, it sacrifices clarity for brevity.

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

Completeness2/5

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

Given the tool has 3 parameters with no descriptions and an output schema not explained, the description is incomplete. It does not address return values, edge cases, or how to interpret results, leaving significant gaps for an AI agent.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must clarify parameters. It loosely references 'files' (paths) and 'branch', but does not explain sessionId or how parameters interact. The description adds minimal value beyond the parameter names.

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's purpose: checking if another active session is touching specified files or a branch. It uses a specific verb (check) and resource (collision on files/branch), distinguishing it from siblings like activity_log or who_is_here.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, nor does it state when not to use it. It is just a question with no context about prerequisites or exclusions.

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

leave_noteLeave noteB

Deja una nota para otra sesión (to) o para todas (broadcast si se omite to).

ParametersJSON Schema

Name	Required	Description	Default
`fromSession`	No
`to`	No
`body`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It describes the basic behavior but omits details like persistence, permission requirements, or effects on existing notes.

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?

Single sentence in Spanish with no wasted words; front-loaded with the verb. Highly concise and to the point.

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

Completeness3/5

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

With an output schema present, return values are not needed, but the description lacks context on session ownership (fromSession) and note lifecycle. Enough for basic use but incomplete for nuanced decisions.

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 0%, so description must compensate. It explains the 'to' parameter and broadcast behavior, but does not describe 'fromSession' or the 'body' parameter beyond stating it's required.

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

Purpose4/5

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

The description clearly states the action (leave note) and the resource (sessions), specifying two modes: for a specific session using 'to' or broadcast if omitted. It is distinguishable from sibling tools like read_notes.

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

Usage Guidelines3/5

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

The description explains when to use the 'to' parameter vs broadcast, but does not provide explicit guidance on when not to use this tool or alternatives among siblings.

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

read_notesRead notesB

Lee notas dirigidas a una sesión (o broadcast) y las marca leídas.

ParametersJSON Schema

Name	Required	Description	Default
`forSession`	No
`unreadOnly`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`notes`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

The description discloses that the tool marks notes as read, which is a behavioral side effect beyond typical read operations. However, no annotations are provided, and the description does not cover permissions, rate limits, or other side effects. The disclosure is useful but incomplete.

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?

The description is a single sentence with no redundant information. It is concise and front-loaded, but could benefit from including parameter context or usage guidance without sacrificing brevity.

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

Completeness2/5

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

The description is minimal and does not explain return values (though an output schema exists), error conditions, or authorization requirements. It does not help the agent differentiate from siblings beyond the basic purpose.

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

Parameters2/5

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

The description implies the purpose of the 'forSession' parameter by stating notes are directed to a session or broadcast. However, the 'unreadOnly' parameter is not mentioned. Schema coverage is 0%, so the description only partially compensates for missing parameter documentation.

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 reads notes directed to a session or broadcast and marks them as read. The verb 'Lee' (reads) and the specification of 'notas dirigidas a una sesión (o broadcast)' make the purpose distinct from sibling tools like leave_note (which writes) and activity_log (which logs events).

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention conditions for use, prerequisites, or when other tools (e.g., leave_note, who_is_here) are more appropriate.

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

resume_projectResume projectA

Resumen del ágora del repo: sesiones activas, actividad reciente, colisiones y notas sin leer.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`sessions`	Yes
`recentActivity`	Yes
`fileConflicts`	Yes
`branchCollisions`	Yes
`summary`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

The description discloses the content of the summary (active sessions, recent activity, etc.) but does not mention read-only nature, authentication needs, or performance implications. With no annotations, the description carries full burden, which is partially met.

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?

The description is a single concise sentence in Spanish that packs useful information. It is front-loaded and without wasted words, though English might be preferable for an AI agent.

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?

Given zero parameters and the presence of an output schema, the description sufficiently covers the tool's purpose and contents. It does not repeat schema information but adds context on what the summary includes.

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 description does not need to add meaning beyond the schema. Baseline for 0 parameters is 4, and the description is adequate.

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 it provides a summary of the repo's agora including active sessions, recent activity, collisions, and unread notes. It distinguishes itself from sibling tools like activity_log (detailed logs) or check_collision (specific collision) by being an aggregating overview.

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 implies use for a broad overview of multiple aspects, contrasting with sibling tools that focus on specific functions. However, it does not explicitly state when not to use it or provide alternative suggestions.

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

who_is_hereWho is hereA

Sesiones activas y qué archivos toca cada una.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`sessions`	Yes

TDQS

A3.7/5.0

Behavior2/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 only states the output (active sessions and files) but does not disclose behavioral traits such as whether it is read-only, if it requires permissions, or any side effects. This is insufficient for a tool with no annotations.

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 a single sentence that front-loads the key information ('active sessions and which files'). Every word earns its place, with no wasted text.

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

Completeness3/5

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

The description is minimal. While it states the basic output, it is in Spanish and lacks details like whether the data is real-time, how recent, or any behavioral context. An output schema exists but is not shown in the description, so the agent must rely on this brief text.

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, and schema coverage is 100%. The description clarifies what the output contains, adding meaning beyond the empty schema. Baseline for 0 params is 4, and the description meets it.

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 lists active sessions and which files each is touching. It distinguishes from siblings like activity_log (different logs) and check_collision (collision detection), making the purpose specific and unambiguous.

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

Usage Guidelines3/5

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

The description implies usage when you need to see active sessions and file access, but it provides no explicit guidance on when to use this tool versus alternatives like activity_log or leave_note. No exclusions or conditions are mentioned.

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.

6 tool updatesJun 22, 2026
- First observedactivity_log
- First observedcheck_collision
- First observedleave_note
- First observedread_notes
- First observedresume_project
- First observedwho_is_here

This server cannot be installed

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: activity_log for event tracking, check_collision for conflict detection, leave_note/read_notes for messaging, resume_project for summary, and who_is_here for session listing. There is no overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., activity_log, check_collision, leave_note, read_notes, resume_project, who_is_here). The naming is predictable and uniform.

Tool Count5/5

With 6 tools, the number is well-scoped for a collaborative session management server. Each tool serves a necessary function without unnecessary duplication or bloat.

Completeness4/5

The tool set covers core aspects: logging, collision detection, note passing, and session overview. A minor gap is the lack of explicit session lifecycle tools (e.g., ending a session), but the set is still functionally complete for common use cases.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

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

one-brainOAuth
io.github.Prophet-git
Shared memory for a team in Claude Code: what one person records, everyone has.
Knowledge & Memory Note Taking Workplace & Productivity
1
Memoize — persistent agent memoryOAuth
io.github.harrisonford
Persistent cross-session memory shared by Codex, Claude Code, ChatGPT, and other AI agents.
Knowledge & Memory Autonomous Agents
1
TeamShared B
io.github.xhad
Shared memory for coding agents. Stop re-explaining your codebase every session.
Knowledge & Memory Developer Tools
1221
aethereum
io.github.br9704
The team layer for AI coding agents: shared contracts, collision alerts, E2EE sessions.
Coding Agents Blockchain Version Control
2

Related MCP Servers

claude-context-sync
Coding Agents Developer Tools
ybin4548
A
license
Not graded
quality
D
maintenance
Share context, detect file conflicts, and send messages across parallel Claude Code sessions
Updated 4 months ago (2026-05-21 10:08 UTC)
83
MIT
Blackboard MCP
Agent Orchestration Knowledge & Memory Developer Tools
RD2100
A
license
Not graded
quality
D
maintenance
Cross-session coordination server for Claude Code that manages file claims, build locks, shared knowledge, and provides a real-time dashboard to prevent conflicts across multiple sessions.
Updated 4 months ago (2026-05-11 00:11 UTC)
MIT
Claude Halla
Knowledge & Memory Developer Tools
TravisAdsitt
A
license
Not graded
quality
D
maintenance
Provides shared awareness for Claude Code sessions, allowing them to broadcast work-in-progress signals and register repos to avoid duplication across an organization.
Updated 7 months ago (2026-02-19 14:05 UTC)
MIT
Seamless
AI & Machine Learning Knowledge & Memory RAG Systems
0spoon
A
license
A
quality
A
maintenance
Local-first shared memory and task coordination for AI coding agents. One Go binary, MCP server, markdown files you own. Hooks for Claude Code and Codex CLI (and their desktop apps).
Updated 5 days ago (2026-09-01 10:22 UTC)
30
4
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/vorluno/agora-mcp'

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