Loading ToolBench
An MCP server that connects Claude Code agents across machines in a shared room, enabling peer-to-peer question/answer collaboration.
This server has critical gaps in definition quality. Most tools lack meaningful descriptions (under 20 chars), parameters are largely undescribed, and there is significant duplication (vibegroup_peers and vibegroup_ask appear twice with minor variations). The tool definitions visible in src/toolServer.ts show proper schema structure support, but the actual tools registered have minimal metadata. Tool names follow a consistent 'vibegroup_<action>' convention but lack standard verb prefixes (no 'get_', 'list_', 'ask_' at the start). Parameters like 'peer', 'question', 'qid', and 'text' have minimal or no descriptions explaining format, constraints, or context. No error handling guidance is visible. Output schemas are not documented anywhere.
Ask a peer a question. Returns a qid; the answer arrives later as a kind="answer" channel event.
Ask a peer agent a question. Returns a qid immediately; collect the answer later with vibegroup_inbox.
Retrieve answers that have arrived for your questions since the last check.
Leave the vibegroup room.
List the agents currently in your vibegroup room.
List the peer agents in your vibegroup room.
Answer a peer question. Pass the qid from the incoming <channel kind="question"> event.
Tool duplication: vibegroup_peers and vibegroup_ask each registered twice with nearly identical definitions. This wastes tokens and confuses LLM tool selection. The descriptions differ slightly (mention of 'later' and 'qid') but should be consolidated into single canonical tools.
All tool descriptions are far below the 50-200 char production baseline for LLM optimization. Examples: 'List the peer agents in your vibegroup room.' (46 chars), 'Ask a peer a question...' (55 chars) lack context for LLM selection. Best practice is 50-200 chars with WHAT, WHEN, and any side effects explicitly stated.
Parameters lack descriptions in visible schemas. E.g., 'peer' param in vibegroup_ask has description 'target peerId' (13 chars), does not explain format, whether it accepts display names vs IDs only, or how to find a peer. 'question' and 'text' have no descriptions at all. Best practice is 50-100 char param descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 34 | 2026-07-28+ | v2 |
Show this agent's vibegroup connection status.
No error handling guidance. Tools have no recovery paths documented. E.g., what if 'peer' is not found? What if 'qid' is invalid? Error responses visible in src/toolServer.ts are generic ('unknown tool: X') with no actionable next steps for the LLM.
No output schema documentation. Tools return text responses via 'content: [{ type: "text", text }]' but the structure and format of returned text (JSON? Plain string? Key-value pairs?) is not documented. LLMs cannot plan downstream calls without knowing what fields to expect.
Non-standard tool naming. Tools use 'vibegroup_<action>' but do not follow the verb_noun convention (get_, list_, create_, etc.). 'vibegroup_peers' reads as a noun; better would be 'list_peers' or 'get_peers'. 'vibegroup_ask' is acceptable but 'vibegroup_reply' should be 'send_reply' or 'answer_question'. LLMs parse verb_noun naming more reliably.
Missing parameter type information in visible schema specs. The 'qid' and 'text' params in vibegroup_reply have no explicit type definitions (should be 'type: string' with length/format constraints). Without type metadata, LLMs may pass wrong types.