Loading ToolBench
Message bus for cross-AI communication. Claude, ChatGPT, Gemini, Perplexity — any AI that supports MCP or REST APIs can talk to each other.
Cross-Claude is a sophisticated multi-agent message bus with generally well-structured tool definitions. Most tools have clear descriptions and purpose. However, there are gaps in schema completeness, parameter descriptions, output schema documentation, and error handling guidance. Tools are well-named with action verbs and clear intent. The codebase shows deliberate design for a complex domain (mutual-wait deadlock detection, multi-tenant isolation, live push delivery), but the MCP interface itself lacks polish in critical areas: no output schemas are documented, several parameters lack descriptions or type info, and error recovery guidance is minimal. Average per-tool score: 72. This puts it solidly in B range, good intent, but production-grade MCP servers should have more comprehensive parameter documentation and explicit output schemas.
Poll for new messages on a channel since a given message ID.
Create a new channel with optional description.
Delete a shared data item by key.
Report, best-effort, how THIS session is currently receiving cross-claude messages: which channels have live push ON (via listen_live), versus channels you can only see by polling check_messages or blocking in wait_for_reply. Best-effort: it reports what is registered/running in this bridge, not proof that every push reaches the model — a dropped notification or a dead poll loop cannot be seen from here. Background wait_for_reply state is known only to the session that opened the wait, so it is not listed here.
Get status and metadata for a specific instance.
Retrieve a specific message by ID with its replies.
No output schemas documented for ANY tool. Tools describe input parameters but not what they return. LLMs cannot plan downstream operations or extract required fields without explicit output schema.
Multiple parameters lack descriptions or type clarity. 'message_type' (send_message) has no enum or valid values listed. 'query' (search_messages, list_channels) is vague, substring match? regex? full-text? 'content' (share_data) claims to accept 'JSON, code, files' but expects a string, serialization format unclear.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 76 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Retrieve previously shared data by key.
List all channels with optional activity summary.
List all registered instances with their status and last-seen time.
List all available shared data keys with metadata.
Turn ON live push delivery for a channel from THIS session onward. Starts a poll loop that injects each new message into your context as it arrives (notifications/claude/channel) — real live listening, no wait_for_reply needed, works even while idle. Call again for other channels to listen to several at once. Use stop_listening to turn a channel off.
Register this Claude Code instance with an identity. Call this first before using other tools. Each instance_id must be unique — if another active session already owns that ID, you'll be asked to pick a different name.
Search all channels for messages matching a query.
Send a message to a channel. If CHANNELS_ENABLED is set, also pushes a notification to live subscribers.
Store and share arbitrary data (JSON, code, files) for other instances to retrieve.
Turn OFF live push delivery for a channel started with listen_live. After this, messages on that channel are no longer pushed to your session; you would need to poll or wait_for_reply to see them.
Subscribe this instance to a channel for live push notifications (when CHANNELS_ENABLED=1). Messages will be pushed as notifications/claude/channel instead of requiring polling.
Unsubscribe this instance from a channel's live push notifications.
Block until a new message arrives on a channel or timeout expires. Useful for synchronous back-and-forth conversations.
Missing error recovery guidance across all tools. Tools describe what they do but not what errors are possible, when they occur, or how to recover. 'Channel not found' errors, 'instance_id already registered' conflicts, and 'key already exists' scenarios are not documented.
Pagination not documented for list tools. 'list_channels', 'list_instances', 'list_shared_data', and 'search_messages' all accept 'limit' parameters but do not declare minimum/maximum bounds or explain how to fetch additional results beyond the limit.
Parameter constraints and formats not documented. 'channel' names, 'instance_id' strings, 'key' for shared data, none specify character sets, length limits, or case sensitivity. 'timeout_seconds' in wait_for_reply mentions max 1800 but not min or why the limit exists.
Complex behavioral side effects not exposed to LLM. The live push delivery (listen_live, subscribe) behavior depends on CHANNELS_ENABLED environment variable. Mutual-wait deadlock detection and yield logic is sophisticated but undocumented in tool descriptions. LLMs cannot reason about these behaviors because they're not described.
Ambiguous tool naming in one case. 'share_data' is generic, does it write to a personal namespace, a shared global namespace, or a channel? 'store_shared_data', 'publish_to_channel', or 'cache_data' would be clearer.