Skip to main content
Glama
lilyanAhmetoglu

roundtable-mcp

by lilyanAhmetoglu
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Local

roundtable

npm node licence

A shared room where two coding agents argue through a plan before you build it.

bun add -g roundtable-mcp

Published on npm as roundtable-mcp. Pairs with Parallelo, which starts a room from the VS Code sidebar — but nothing here needs it, and the server never learns what an agent is.

You give the room a topic. Two agents — running in the same repository, in separate terminals — take turns posting to a transcript on disk. One holds the lead seat and drives; the other holds the peer seat and pushes back. When they converge, or the round budget runs out, the lead writes a spec file and closes the room.

It does not know what an agent is

The room has two seats. It never learns which model or CLI is sitting in one. Anything that speaks MCP can take either seat, including two instances of the same thing:

lead

peer

works

Claude Code (Opus 5)

Codex

yes

Claude Code (Opus 5)

Claude Code (Opus 5)

yes

Copilot CLI

Claude Code

yes

The seat and the room id are the only contract. Each seat is a separate process with its own server, so there is no special case for two of the same agent — the server cannot tell.

Related MCP server: bothread-room-for-ai-agents

Install

bun add -g roundtable-mcp

Use it

Pick a room name, then register the server with each agent — the same room, different seats.

Claude Code, in the terminal that will lead:

claude mcp add roundtable -- roundtable \
  --room cache-design --seat lead --agent "opus-5" \
  --topic "Should the cache be write-through" --budget 12

and in the terminal that will take the peer seat:

claude mcp add roundtable -- roundtable \
  --room cache-design --seat peer --agent "opus-5" \
  --topic "Should the cache be write-through" --budget 12

For an agent configured by file rather than CLI, the stdio entry is the usual shape — only --seat differs between the two:

{
  "mcpServers": {
    "roundtable": {
      "command": "roundtable",
      "args": ["--room", "cache-design", "--seat", "peer", "--agent", "codex"]
    }
  }
}

Every flag also reads from the environment (ROUNDTABLE_ROOM, ROUNDTABLE_SEAT, ROUNDTABLE_AGENT, ROUNDTABLE_TOPIC, ROUNDTABLE_BUDGET, ROUNDTABLE_CWD), which is easier when the agent's config format is awkward.

Then paste prompts/lead.md into one terminal and prompts/peer.md into the other, with {{TOPIC}} filled in. The seed prompts are not optional — see below.

The seed prompts are the load-bearing part

MCP has no push. A server cannot wake an agent up. An agent only acts while its own loop is running, and by default an agent answers once and then goes idle waiting for a human.

Two things make a conversation out of that, and you need both:

  1. wait_for_message blocks. The server holds the call open until the other seat posts. The waiting agent is parked inside a tool call — its turn is still alive. When the other seat posts, the call returns and it keeps going.

  2. The prompt has to say "loop". The protocol cannot make an agent call wait_for_message again. prompts/lead.md and prompts/peer.md say it explicitly. Skip them and you get exactly one exchange, then silence.

Waits return after 55 seconds with {"idle": true} rather than blocking forever, because MCP clients cap how long a single tool call may run. The prompts tell the agent to call again on idle.

Tools

Both seats get room_status, read_room, wait_for_message, and post. Only the lead gets close_room.

The server enforces the rest, so an agent cannot talk its way around it:

  • Turn taking. Posting out of turn is refused with an instruction to call wait_for_message. Neither seat can monologue.

  • Round budget. Each lead post spends one round. At zero, the lead's posts are refused and it is told to write the spec and close.

  • Closure. After close_room, posts are refused and any parked wait_for_message returns {"closed": true}.

Seats are set by the flag the server was launched with, not by anything the agent says, so neither can claim the other's authority.

What lands on disk

.roundtable/<room>/
  room.json              topic, budget, created
  closed.json            appears when the room ends
  messages/
    0001-....json        one file per message

Every message is its own file, written to a temp name and renamed into place. Renames are atomic and nothing is ever mutated after it is written, so two processes share a room without a lock. Round, turn, and closure are derived from those files rather than stored, so there is no shared mutable state to corrupt when an agent dies mid-turn.

The transcript is plain JSON in your repo. Read it, diff it, delete it. Add .roundtable/ to .gitignore if you would rather not keep it.

What you get out

The lead writes a spec file itself, with its own file tools — the server never writes your content. The prompt asks for the problem, the decision, the reasoning, the steps, and a Dissent section holding anything the peer still disagrees with, in its own words. That section is the point: two agents left alone will converge into agreement, and the disagreement they flattened on the way there is usually the part worth your attention.

Things worth knowing before you run it

  • Two agents will talk forever. They do not get bored and they do not run out of refinements. The round budget is not a safety rail, it is the termination condition. Twelve is a lot; eight is usually plenty.

  • It costs double. Two premium agents reasoning over the same codebase. A room is worth it for a decision you would otherwise get wrong, not for choosing a variable name.

  • Both seats share the working directory. If they both start editing files you have two agents writing to one worktree. Rooms are for planning; give the implementation to one agent afterwards.

  • The peer has no context from your session. It reads the same CLAUDE.md / AGENTS.md in the same repo, but it did not see your conversation. The opening brief is the only handoff, so put the constraints in it.

Reading a room afterwards

The transcript is one JSON file per message, which is right for two processes sharing a directory without a lock and wrong for anyone who wants to know what was said. transcript renders it:

roundtable transcript --room <name> --cwd <worktree>              # Markdown, to stdout
roundtable transcript --room <name> --cwd <worktree> --out r.html # a standalone page

Markdown for a terminal or an editor; HTML for a self-contained file with no network dependency, readable in light or dark. Neither is written into the worktree unless you name a path with --out — the spec stays the room's only output.

It works on an open room too, and says so at the end instead of claiming a close that has not happened.

Development

bun install
bun run build
bun run smoke     # spawns two servers, checks they actually wake each other

The smoke test runs the same agent label in both seats on purpose.

Licence

MIT

Available Tools

6 tools
close_roomA

End the discussion. Write the agreed plan to the spec file named in room_status first, then call this. Defaults to that path.

ParametersJSON Schema
NameRequiredDescriptionDefault
reasonNoWhy the room is closing: agreement reached, budget spent, or dead end.
spec_pathNoPath to the spec file you wrote.

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description must carry behavioral disclosure, and it does reveal the main effect (ending the discussion) plus the prerequisite and default path behavior. However, it doesn't say whether closing is irreversible, how it affects room_status or pending messages, or what response the caller should expect.

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 short sentences with no filler; the core purpose is front-loaded and the prerequisite/default follow naturally. Every sentence 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?

For a two-parameter, no-output-schema tool, the description plus schema covers the essential calling sequence and the optional path behavior. It could be more complete about post-close state changes, but nothing needed for correct invocation is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful parameter context by revealing that spec_path defaults to the path reported by room_status. This is information not present in the input schema and directly affects how an agent should invoke the tool with zero arguments.

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 uses specific verb 'End' plus resource 'discussion', clearly distinguishing close_room from siblings like post, read_room, and wait_for_message. It also frames the tool's role as the terminal action after a plan is written, which leaves no ambiguity about its purpose.

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 gives an explicit precondition: write the agreed plan to the spec file named in room_status first, then call close_room. It doesn't explicitly name write_spec or list when-not-to-use cases, but the sequencing is unambiguous and actionable.

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

postA

Post to the room. Each post you make consumes one round of the budget. Use it to set the brief, push back on the peer, or ask a narrower question.

ParametersJSON Schema
NameRequiredDescriptionDefault
kindNobrief | challenge | question | decision
textYesWhat you want to say. Markdown, cite real file paths and line numbers.

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the budget cost ('Each post you make consumes one round of the budget'), which is a key behavioral constraint. However, it does not mention message visibility, what happens after posting, or any failure behavior, leaving some gaps.

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 focused sentences: the first states the core action, the second discloses the budget cost, and the third gives usage guidance. Every sentence earns its place with no filler or redundancy.

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 2-parameter tool with no annotations or output schema, the description covers purpose, usage, and the critical budget behavior. It is slightly incomplete because it doesn't mention what happens on success/failure or explicitly cover the 'decision' kind, but overall it is quite 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?

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by mapping kind values to use cases: 'set the brief' (brief), 'push back on the peer' (challenge), 'ask a narrower question' (question). It does not address the 'decision' kind, so it is not a full 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?

States a specific verb and resource ('Post to the room') and explains the tool's role with concrete use cases: 'set the brief, push back on the peer, or ask a narrower question.' This clearly distinguishes it from sibling tools like read_room or write_spec.

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?

Provides explicit usage context: 'Use it to set the brief, push back on the peer, or ask a narrower question.' This tells the agent when the tool is appropriate, though it does not explicitly mention alternatives or when-not-to-use conditions.

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

read_roomA

Read the messages posted so far. Returns everything you have not already been shown unless you pass since.

ParametersJSON Schema
NameRequiredDescriptionDefault
sinceNoReturn only messages after this sequence number. Omit to continue from where you left off.

TDQS

A4.5/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, and it does well by disclosing the stateful behavior of returning only previously unseen messages and the effect of `since`. It does not describe the output format or whether reading advances a cursor, but the core non-obvious behavior is clearly exposed.

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 compact sentences deliver both the core purpose and the key behavioral nuance. The most important information is front-loaded, and every sentence earns its place with no fluff.

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?

For a simple tool with one optional parameter, no required parameters, and no annotations or output schema, the description is sufficiently complete. It tells the agent what the tool returns, how sequence numbers affect the result, and what behavior to expect on repeated calls.

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?

Schema description coverage is 100%, so the baseline is 3, and the description adds value by connecting `since` to the 'continuing from where you left off' model. It clarifies that omitting `since` returns everything not already shown, which goes beyond simply restating 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 uses a specific verb (Read) and resource (messages), and clearly explains the tool's distinctive behavior: it returns everything not already shown unless `since` is passed. This differentiates it from siblings like wait_for_message, which implies blocking for new messages, and post, which is for sending.

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 clearly establishes when to use the tool: to read messages posted so far and catch up on anything not yet seen. It does not explicitly name alternatives or state when not to use it, but the context is strong enough that an agent can infer the appropriate scenario.

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

room_statusA

Where the discussion stands: whose turn it is, which round of the budget you are on, and whether the room has closed.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/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 usefully indicates that the tool is about where the discussion stands and lists the exact data it reports, implying a read-only snapshot. However, it does not explicitly state that it has no side effects, whether it waits, or whether it consumes any state.

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 purpose and then lists three concrete, useful details: turn, round, and room closure. There is no filler or redundant content.

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 zero-parameter status tool with no output schema, the description adequately conveys the key returned information. It could be more complete by explicitly stating that the tool is non-mutating or how it differs from read_room, but the simplicity of the tool keeps this gap minor.

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 already leaves nothing to document. The baseline of 4 applies because the description adds no parameter-specific detail, but none is needed.

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 states what the tool reports: the current turn, budget round, and whether the room has closed. This gives a specific status resource and distinguishes it from siblings like post, write_spec, and close_room, though it lacks an explicit imperative verb such as 'get' or 'read'.

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?

It implies you should use this tool when you need a snapshot of the discussion state, but it does not explicitly say when to prefer read_room or wait_for_message instead. No exclusions or alternative conditions are given, so usage guidance is inferred rather than stated.

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

wait_for_messageA

Block until the peer posts, then return their message. Returns {"idle": true} if nothing arrives before the timeout — call it again. Returns {"closed": true} when the room is over, which is your signal to stop. This is how you stay in the conversation; do not end your turn while the room is open.

ParametersJSON Schema
NameRequiredDescriptionDefault
timeout_secondsNoHow long to wait before returning idle. Default and maximum 55.

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers: it discloses blocking behavior, timeout semantics, the two possible non-message return states, and the required follow-up action. This goes well beyond the tool name and schema by explaining exactly how to behave in the conversation loop.

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?

Four short sentences, each earning its place: one states the core action, two define return states, and one gives the practical usage rule. The most important information is front-loaded, with 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 the single parameter, no output schema, and no annotations, the description covers everything an agent needs: what it returns, what to do on idle, what to do on closed, and how to stay in the conversation. No critical behavior is left unexplained.

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 description coverage is 100% and the single parameter already explains timeout duration plus default and maximum in the schema. The description does not need to add further parameter detail, so the baseline 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 uses a specific verb and resource: 'Block until the peer posts, then return their message.' It clearly distinguishes this from non-blocking siblings by emphasizing the blocking wait and the return contract, making the tool's unique role unambiguous.

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 gives clear usage guidance: call it again on idle, treat 'closed' as a stop signal, and do not end the turn while the room is open. It stops short of explicitly comparing against alternatives like read_room or room_status, so it doesn't fully earn a 5, but the intended usage pattern is well communicated.

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

write_specA

Write the plan. This is the only way anything leaves this room, and the only file you can create -- you have no file-writing tools and you are not here to implement anything. Call it once you have converged, then close_room.

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesThe whole document, markdown. Decision first, then reasoning, then the work as steps, then a Dissent section in the peer's own words.

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries the burden of disclosing behavior. It explains that this tool is the sole output channel, writes a plan rather than code, and should be called after convergence. It does not explicitly state overwrite or repeat-call behavior, but the workflow context strongly implies a single final write.

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, front-loads the main purpose, and every sentence adds useful guidance: what to write, when to write it, and what to do afterward. There is no fluff.

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 one simple parameter fully documented in the schema and the low complexity of the surrounding tool set, the description covers the tool's role, the right moment to call it, and the next step. An agent has enough information to invoke it correctly.

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?

Only one parameter exists and the input schema already covers it fully, including required content structure and markdown format. The description adds no new parameter-level detail, but with 100% schema coverage, that is acceptable.

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 states a specific action and resource: 'Write the plan.' It further differentiates the tool from siblings by calling it 'the only way anything leaves this room' and 'the only file you can create,' so an agent can tell exactly what this tool is for.

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 gives explicit timing and sequencing: 'Call it once you have converged, then close_room.' It also tells the agent what not to do here — 'you have no file-writing tools and you are not here to implement anything' — which prevents misuse.

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.

  1. 6 tool updatesv0.1.0
    • First observedclose_room
    • First observedpost
    • First observedread_room
    • First observedroom_status
    • First observedwait_for_message
    • First observedwrite_spec
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation4/5

Each tool has a distinct role in the conversation lifecycle, but read_room and wait_for_message both involve retrieving messages, which could cause occasional confusion. The descriptions clearly separate backlog reading from blocking for the next peer message, so an agent can disambiguate with care.

Naming Consistency4/5

Most tools follow a clear verb_noun pattern like read_room, write_spec, and close_room. The deviations are minor: post is a bare verb and room_status is noun-only, so the overall naming is readable and mostly consistent.

Tool Count5/5

Six tools is well-scoped for a collaborative roundtable workflow. Each tool covers a necessary part of the interaction: reading, waiting, posting, checking status, writing the spec, and closing the room.

Completeness5/5

The tool surface covers the full lifecycle of the domain: observe the conversation, participate, monitor state, produce the agreed artifact, and end cleanly. There are no obvious dead ends for an agent operating inside this room-based workflow.

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/lilyanAhmetoglu/roundtable'

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