Loading ToolBench
Coordinated multi-agent messaging and coordination MCP server.
mcp-agent-mail provides 11 tools with consistent naming conventions (verb_noun pattern) and complete input schemas with typed parameters. Most tools have descriptions (10/11), though several are minimal (20-50 chars). Schemas are properly structured with JSON Schema types and descriptions. However, output schemas are not documented, parameter descriptions lack detail about constraints and formats, and error handling guidance is absent. The server follows a clear composition pattern (project/agent/message lifecycle) but tools lack richness in documentation and recovery guidance expected of production-grade systems.
Mark a message as acknowledged/read
Create a new agent identity
Ensure a project exists in the messaging system
Fetch messages from an agent's inbox
Check the health status of the MCP server
List all agents/contacts in a project
Register a new agent in the system
Output schemas not documented. No return type specifications provided for any tool. LLMs cannot plan downstream tool calls or extract needed fields without knowing what data each tool returns.
Parameter descriptions lack constraint details. Fields like 'limit' in fetch_inbox, 'query' in search_messages, and 'agent_name' across multiple tools lack format specifications, min/max bounds, or allowed value enums. LLMs cannot validate inputs before submission.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Search messages across the system
Search messages in product-related conversations
Send a message from one agent to another
Get information about an agent
search_messages_product tool name is ambiguous and lacks context. The suffix '_product' is unclear, does it search only product-related conversations, or is it a product-specific instance? This violates naming clarity rules and creates duplicate-tool confusion (search_messages vs search_messages_product).
No error handling guidance provided. Tools lack descriptions of error conditions, recovery paths, or actionable error messages. When a tool fails (e.g., agent not found, invalid project), LLMs will not know what to try next.
No pagination guidance documented. fetch_inbox accepts 'limit' but no mention of offset, cursor, or total count. search_messages tools accept 'query' but no pagination parameters visible. Large result sets will exhaust context windows.
Parameter naming ambiguity: 'query' in search_messages tools is generic. Does it search by subject, sender, body, or all fields? Descriptions should specify search scope and format (e.g., 'Search by subject line, sender name, or message body. Prefix with field: for field-specific search, e.g. subject:urgent').
Credential handling not visible. No evidence of secret injection patterns in source. If project_key or agent credentials are passed as parameters, they risk appearing in logs. Verify no sensitive data flows through tool parameters.