Loading ToolBench
Real-time communication between Claude Code, OpenAI Codex CLI, and Gemini CLI. Enables multi-session Claude Code chat, cross-vendor AI CLI communication, shared memory/context across all AI assistants, conversation history and threading, and broadcast messaging.
This MCP server has fundamental definition quality issues that would not pass production code review. While the 10 tools are explicitly registered with names and type information, the descriptions are vague and sometimes misleading about actual functionality. Parameter descriptions are often missing or generic. The tool set conflates multiple concerns (session management, messaging, and shared storage) into a single server that lacks proper error guidance and validation. The descriptions read more like marketing copy than technical documentation for LLMs. Most critically, this server appears designed to enable cross-AI communication in a multi-agent environment, but the actual implementation details (how messages are persisted, queued, delivered, how semantic search works for shared context) are absent or unclear in the schema definitions.
Broadcast a message to ALL connected AI sessions. Everyone receives it: Claude Code, Codex, Gemini, etc. Use for announcements, shared discoveries, or coordination.
Create a new multi-AI conversation thread.
Retrieve messages from a conversation or session.
List all active AI sessions across all platforms. Shows Claude Code, Codex CLI, Gemini CLI, and other connected AI assistants. Use this to discover who you can communicate with.
List all active conversations.
List all available shared context keys.
Register this AI session with the universal chat system. Call this first to announce your presence to other AI assistants. Sets your platform type, display name, and capabilities. Other AIs can then discover and communicate with you.
Tool descriptions lack context for LLM selection. Multiple tools (send_message, broadcast_message, get_messages) use generic phrasing without explaining when to call each one versus alternatives. 'Retrieve messages from a conversation or session' (get_messages) is vague about filtering behavior and result structure.
Missing parameter descriptions throughout. 'from_session' in get_messages has no description. 'context_type' enum values are defined but not explained (what is 'discovery' vs 'fact' vs 'working_memory'?). LLMs cannot infer semantic differences between enum values.
No output schemas documented. Tools return structured data (list of sessions, messages, conversations) but the response format is not specified. LLMs cannot plan downstream tool calls without knowing what fields are in the response.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Retrieve shared context by key or semantic search.
Send a message to another AI session. Messages are delivered in real-time when possible, queued otherwise. Works across Claude Code, Codex CLI, Gemini CLI, and any connected AI. Use for: - Requesting help from another AI - Sharing findings or results - Coordinating multi-AI tasks - Asking questions to a specific AI vendor
Store shared context accessible to all connected AIs. Use this to share: - Project goals and requirements - Current task status - Important discoveries - Shared knowledge - Decision logs All AIs can retrieve and build upon this context.
No pagination guidance. Tools like list_active_sessions and get_messages accept no limit or pagination parameters beyond an optional 'limit' in get_messages. No indication of max results, whether results are truncated, or how to fetch additional pages. Large result sets will exhaust context windows.
No error handling guidance. Tools do not specify what happens on failure (invalid session_id, network timeout, database error). No indication of retryable vs fatal errors. LLMs have no recovery path when a tool call fails.
Missing natural identifier support. Tools require session_id (opaque UUID) to send messages or create conversations, but session_id generation is non-deterministic (based on PID and timestamp). No way to reference sessions by display_name or other human-friendly identifier. Agents must always call list_active_sessions first to get IDs.
Ambiguous message_type enums without semantic guidance. send_message accepts message_type with values like 'chat', 'request', 'response', 'notification', 'code', 'data', but no description of which to use when. Similarly, store_shared_context context_type values ('general', 'decision', 'discovery', 'fact', 'working_memory') lack definitions.
No confirmation or dry-run support for destructive or broadcast operations. broadcast_message sends to ALL connected AIs with no undo option. No mechanism for agents to preview recipients or confirm before sending. High risk of unintended side effects.
Unclear semantics of retrieve_shared_context when both 'key' and 'search_query' are provided. Which takes precedence? Are they AND or OR? Can both be omitted? LLMs will guess wrong, causing unexpected results.