Loading ToolBench
Local MCP server + CLI letting multiple MCP clients (Claude Code, OpenCode, Gemini CLI, …) exchange messages over a shared SQLite bus with audit logging.
Server has 6 tools with clear verb-noun naming (whoami, list_agents, send_message, read_inbox, read_thread, tail_audit). All tools have descriptions (avg ~150 chars, within baseline 34-392 range). Input schemas are present with type definitions and parameter descriptions. However, output schemas are NOT documented, tool descriptions state what is returned but JSON Schema output structure is absent. Parameter descriptions are adequate but lack explicit constraints (enums, ranges, formats). Error handling guidance is minimal. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles (send_message is WRITE, others READ_ONLY).
Every agent that has ever connected, plus its current unread count. Pass `group` (a bare repo name) to see one repo's agents.
Unread messages for this agent, oldest first. Set mark_read=False to peek without flipping read_at.
Full thread across all participants, ordered by sent_at.
Send `body` to one agent, to every agent in a repo, or to everyone. `to` is a full agent name such as `repo-a/claude` (exactly that agent), a bare repo name such as `repo-a` (every agent working in that repo, except you), or `*` (every agent on the bus, except you). `list_agents` shows the names. An unknown `to` is an error and nothing is sent. Returns {"to", "kind", "message_ids", "recipients", "thread_id", "sent_at"}, plus "message_id" when exactly one agent received it. `kind` is "direct", "group" or "broadcast". Each recipient gets its own row and message_id, so read state is tracked per agent.
Last N audit-log entries across the whole bus. Audit rows are the recovery-truth source; messages.body is the only place the full body lives, but the audit log records its sha256 so you can reconstruct provenance.
Output schemas not documented. Tool descriptions mention return structure (e.g., send_message returns {to, kind, message_ids, recipients, thread_id, sent_at, message_id}) but no formal JSON Schema is provided. LLMs cannot reliably extract fields or plan downstream calls without documented output types.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). send_message is marked WRITE but lacks destructiveHint annotation; read_inbox modifies state (mark_read=True) but lacks idempotentHint. Annotations enable LLMs to reason about safety and retry logic.
Parameter constraints not formalized. 'to' parameter in send_message accepts 'full agent name', 'bare repo name', or '*' but no enum or pattern constraint is declared. 'limit' parameters lack min/max bounds (e.g., limit: 1-100). LLMs may pass invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
This server's identity: its name, its repo's group and the other agents working in the same repo, plus any wiring warnings.
Error handling lacks recovery guidance. No documented error cases or actionable messages. E.g., if 'to' is unknown in send_message, the description says 'An unknown to is an error and nothing is sent' but does not guide the LLM to call list_agents() to discover valid targets.
Pagination not fully specified. read_inbox and read_thread accept 'limit' but do not document total count or next_cursor for continuation. Large result sets may exceed context window without clear pagination semantics.