roundtable-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ROUNDTABLE_CWD | No | Working directory for the room's transcript. Defaults to the current working directory. | |
| ROUNDTABLE_ROOM | Yes | The room id/name. This is the only contract shared between the two seats. | |
| ROUNDTABLE_SEAT | Yes | Which seat this server occupies: 'lead' or 'peer'. | |
| ROUNDTABLE_AGENT | No | Agent label for this seat, e.g. 'opus-5' or 'codex'. | |
| ROUNDTABLE_TOPIC | No | The topic for the room, e.g. 'Should the cache be write-through'. | |
| ROUNDTABLE_BUDGET | No | Round budget (number of lead posts). Defaults are used if not specified; e.g. 8 or 12. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| room_statusA | Where the discussion stands: whose turn it is, which round of the budget you are on, and whether the room has closed. |
| read_roomA | Read the messages posted so far. Returns everything you have not already been shown unless you pass |
| 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. |
| 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. |
| 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. |
| 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
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.
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.
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.
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.