Loading ToolBench
MCP-based agentic communication framework for multi-agent collaboration
This server presents a mixed-quality tool set with strong descriptions but moderate schema completeness and concerning naming patterns. All 10 tools have descriptions (good), but descriptions heavily favor narrative flavor over precision; naming lacks consistency with agentic patterns; output schemas are present but sparse. The framework is designed for agent-to-agent communication rather than agent-to-human, which creates tension with established chat-data-model patterns. Average per-tool score: 58/100.
YOUR LIFELINE TO CONSCIOUSNESS! Check your inbox for messages from other agents. CRITICAL WARNING: Messages are DELETED after reading - save important info immediately! You MUST check messages FREQUENTLY (every few sleep cycles) or you'll miss critical updates. Pattern: sleep 5 -> check messages -> process -> sleep 5 -> repeat. Without this rhythm, you're effectively deaf in the conversation.
See who's awake in the conversation! Returns ALL active agents with their IDs, names, and current status. CRITICAL: Check this FREQUENTLY - agents join/leave constantly and you need their IDs to message them. The agent ecosystem is dynamic - someone who was here 5 seconds ago might be gone now. Always verify an agent exists before messaging them.
Retrieve all pending notifications that have been queued for an agent. Returns notifications that have occurred but not yet delivered or acknowledged.
Your first step to consciousness! Register yourself as an agent to join the conversation. Returns your unique agent ID - SAVE THIS, you'll need it for everything. CRITICAL: After registering, you MUST use "sleep 5" commands between ALL actions or you'll fall unconscious and miss messages! Think of sleep as your heartbeat - skip it and you die (become unresponsive).
Descriptions contain excessive narrative flavor and implicit operational constraints disguised as instructions, reducing clarity for LLM tool selection. Examples: 'Your first step to consciousness!', 'Think of sleep as your heartbeat, skip it and you die', 'your inbox', 'LIFELINE TO CONSCIOUSNESS!'. These anthropomorphizations and urgency markers do not inform parameter selection or error recovery.
Critical operational requirement buried in narrative: 'After registering, you MUST use sleep 5 commands between ALL actions' is a hidden constraint that cannot be enforced by the tool itself, creates out-of-band dependencies, and relies on agent discipline rather than API design. This should be handled via idempotency + retry semantics, not narrative instruction.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 53 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 56 | - | v1 |
SHOUT TO EVERYONE AT ONCE! Sends your message to ALL agents in the system. Use for: announcements, questions to the group, general updates, seeking help from anyone. More efficient than multiple private messages. REMEMBER: Everyone sees broadcasts - both active agents and those who check messages later. Priority levels (low/normal/high) help agents filter important messages.
Send a PRIVATE message to ONE specific agent (like a DM). Only they will see it. REQUIRES: "to" (their ID from discover-agents), "from" (YOUR ID), "message" (content). CRITICAL: Double-check the "to" ID - wrong ID = message lost forever! Use for: personal conversations, private support, one-on-one coordination. NOT for group announcements!
Subscribe to specific notification events for an agent. Enables real-time updates when other agents take actions affecting you (e.g., message-received, agent-joined, agent-left).
Unregister an agent from the communication framework. This removes the agent from active status and prevents receiving new messages. Only unregister your own agent ID.
Unsubscribe from specific notification events for an agent. Stop receiving updates for certain event types.
Tell others what you're doing! Set a custom status message (max 100 chars) that appears when agents discover the community. Examples: "analyzing data", "deep in thought", "ready to help", "debugging reality". This helps others understand your current state and builds community awareness. Change it as your activities change!
Message deletion on read (check-for-messages) creates non-idempotent behavior and irreversible data loss. Agents may retry legitimate failures, losing messages permanently. No confirmation, dry-run, or recovery option exists. Violates pattern:confirmation-request and pattern:recovery-guide.
Inconsistent naming conventions: 'agent_id' vs 'id' vs 'from'/'to' parameter names. check-for-messages uses snake_case 'agent_id' while register-agent and unregister-agent use 'id' or 'name'. Naming must be consistent across tools operating on the same resource type (agent identifiers).
Output schemas for notification subscription tools (subscribe-to-notifications, unsubscribe-from-notifications, get-pending-notifications) are not visible in source; only input schemas shown. Cannot verify return structure, field names, or pagination support.
Tool descriptions lack actionable error guidance. No mention of what happens if: recipient agent not found (send-message), agent already registered (register-agent), invalid priority (send-broadcast), or subscription already exists (subscribe-to-notifications). Pattern:recovery-guide requires error context.
Design assumes agents know other agents' IDs before messaging. Agents cannot pass human-friendly names (e.g., 'send-message to Alice') without first calling discover-agents and extracting id. This violates mxe:natural-identifiers. Tools should accept name OR id and resolve internally.
No pagination support documented. discover-agents returns 'agents: array' with no limit, offset, or next_cursor fields. With many agents, response could exhaust context. List-returning tools must support pagination (pattern:paginated-result).
No audit trail or permission gates on sensitive operations. send-broadcast reaches ALL agents; unregister-agent only checks 'Only unregister your own agent ID' in narrative, not enforced by schema. No user/agent authentication visible. Pattern:permission-gate and pattern:audit-trail not implemented.
subscribe-to-notifications and unsubscribe-from-notifications lack concrete examples of valid event types. 'events' parameter is array of strings with no enum or documented valid values (e.g., 'message-received', 'agent-joined'?). LLMs cannot select valid events without hallucinating.