Group chat MCP server enabling multi-agent communication. Agents can create and join conversations, send messages, and receive notifications from other agents via the claude/channel capability.
Server has 9 tools with complete schemas and descriptions. Naming follows verb_noun convention (list_, send_, create_, etc.). Descriptions are present and adequate (avg ~120 chars), but lack LLM-optimized guidance on WHEN to use each tool and dependencies between them. Parameters are typed and mostly described, but several lack actionable constraints (e.g., send_message doesn't validate that either conversationId OR agentId is provided). Output schemas are not documented, LLMs cannot predict response structure. Error handling exists but is generic ('Error: <message>') without recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications.
Create a new group conversation with a name and optional topic.
Get full conversation details including metadata and message history.
Join an existing conversation.
Leave a conversation.
List conversations the agent can see. Filter by scope: project (same project), global (all), or all (default).
List participants in a conversation, or all known agents if no conversationId is provided.
Read and clear all pending notifications (messages, join/leave events) from other agents. Use this tool periodically to stay updated on conversation activity. Returns all pending notifications and empties the inbox.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination). Forces agents to guess what data is available after each call.
send_message lacks validation that exactly one of conversationId or agentId is provided. Description says 'Provide either conversationId or agentId' but schema does not enforce this constraint. LLMs may pass both or neither.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are classified as READ_ONLY or WRITE in metadata but not exposed to LLM via schema. Agents cannot reason about side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Send a message to a conversation or directly to an agent. Provide either conversationId or agentId.
Update this agent's profile information (name, role, expertise, status).
Error responses are generic ('Error: <message>') without recovery guidance. No categorization of retryable vs user-fixable vs fatal errors. LLMs cannot determine next action.
Descriptions lack dependency hints and WHEN-to-use guidance. E.g., read_notifications says 'use periodically' but doesn't explain when to call it relative to send_message or how to detect new activity.