Loading ToolBench
MCP server + terminal UI for startup-room: live room status, chat, per-agent modal, an installable room registry, and skill-sync.
Roomyx exposes 9 tools with mixed quality. Naming is generally clear (verb_noun pattern: list, sync, get_*, post_*, ack_*), but descriptions vary significantly in depth. Most tools have input schemas with types and descriptions, but several lack output schema documentation. Error handling guidance is minimal. The server demonstrates domain-specific sophistication (room state management, transcript pagination, owner commands) but falls short of production-grade polish expected for A-tier tools.
Says that a command has been dealt with, so `pending` keeps meaning something. An unknown or already-acknowledged id is refused rather than reported as success.
One participant's own messages and last-seen status.
Everything after that participant's own last message, excluding its own — the convention "everything since your last turn", computed here instead of by hand. `since_seq` overrides the convention's cursor; the answer reports the cursor used and whether it came from the participant's last message or from the caller. This is what the participant has probably not seen: the server cannot see what was actually sent to it, so treat the result as a candidate delta, not as a delivery record.
Commands posted by the owner that have not been acknowledged yet, oldest first. Read-only: the room log is still written only by the dispatcher.
Roster and current goal contract for this room.
Output schemas not documented. Tools like room.get_state, room.get_pending_owner_commands return structured data but LLMs cannot infer field names, types, or nesting. Agents must guess what fields to extract.
Descriptions lack actionable context. 'Roster and current goal contract for this room' (room.get_state) does not explain when to call it, what 'roster' contains, or what 'goal contract' means. LLMs cannot determine if this is the right tool without trial.
room.get_delta_for description is 200+ chars and uses domain jargon ('convention's cursor', 'candidate delta', 'delivery record') without explanation. Agents unfamiliar with the room protocol will misuse this tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Messages with seq greater than since_seq, in order — at most `limit` of them. The result carries has_more and next_seq so a page can be told from a complete answer: pass next_seq back as since_seq to continue.
Hands a veto / constraint / add_participant / goal_edit to the room: it is held in the room's queue for a dispatcher to read, and settlement is reported as `queued`, `accepted` or `refused`. Never writes to the room log itself.
Rooms currently registered and confirmed live (liveness-checked, not just registry presence).
Diffs/backs-up/writes the bundled skill into a named runtime's skill location (see decisions.md D-02 for safety rules).
room.post_owner_command accepts 'kind' as enum but does not document what each kind does or what 'body' format each expects. Agents cannot construct valid commands without trial-and-error.
No error recovery guidance. Tools do not document what errors are retryable, what user-fixable errors look like, or what to do if a room is not found. Agents will stall on failures.