agent-mailbox-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MAILBOX_DB | No | Full database path | ~/.agent-mailbox/mailbox.db |
| MAILBOX_DIR | No | Database directory | ~/.agent-mailbox |
| MAILBOX_TTL | No | Message TTL in seconds (default 24h) | 86400 |
| MAILBOX_PORT | No | HTTP server port | 4820 |
| MAILBOX_TRANSPORT | No | Transport: stdio, http, or both | stdio |
| MAILBOX_AUTH_SECRET | No | JWT signing secret (empty = auth disabled) | |
| MAILBOX_ENCRYPTION_KEY | No | AES-256-GCM key (empty = no encryption) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| msg_sendA | Send a message to another agent. Supports deduplication and threading. |
| msg_read_inboxA | Read unread messages for an agent. Messages are marked as delivered. |
| msg_broadcastC | Send a message to all registered agents. |
| msg_searchA | Search messages by content, subject, or sender/recipient. |
| msg_requestA | Send a message and wait for a reply (synchronous request/reply pattern with polling). |
| msg_list_threadsA | List conversation threads for an agent. |
| msg_countA | Count messages by status for an agent. |
| agent_registerB | Register an agent in the mailbox system with a name, role, and optional A2A Agent Card metadata. |
| msg_list_agentsA | List all registered agents with their roles and last activity. |
| msg_activity_feedC | Get recent messaging activity feed. |
| a2a_submit_taskB | Submit a task to another agent via the A2A protocol. Creates a new task with an initial message. |
| a2a_get_taskA | Get the status and full history of an A2A task including messages and artifacts. |
| a2a_cancel_taskA | Cancel an A2A task. Only non-terminal tasks can be canceled. |
| a2a_list_tasksB | List A2A tasks for an agent with pagination. |
| a2a_respond_taskA | Respond to an A2A task as the assigned agent. Sends a response and optionally updates the task status. |
| resource_acquireA | Acquire an advisory lease on a resource. Used for coordinating exclusive or shared access between agents. |
| resource_releaseB | Release a previously acquired resource lease. |
| resource_checkB | Check the current lease status of a resource. |
| dlq_listA | List messages in the dead-letter queue. These are messages that expired or failed delivery. |
| dlq_retryA | Retry a dead-letter message by re-inserting it as a new pending message. |
| dlq_purgeA | Remove all entries from the dead-letter queue. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 21 tools
Each tool targets a specific action and resource: messaging (send, read, broadcast, search, request, threads, count, activity), A2A tasks (submit, get, list, cancel, respond), resource leases (acquire, release, check), and dead-letter queue management (list, retry, purge). The purposes are clearly distinct and descriptions eliminate ambiguity.
Most tools follow a consistent prefix-based naming scheme (msg_, a2a_, resource_, dlq_) with verb_object patterns. Minor deviations include 'msg_activity_feed' (noun instead of verb) and 'agent_register' lacking a category prefix, but these are not confusing.
With 21 tools, the count is slightly above the typical well-scoped range but appropriate given the server's broad scope covering messaging, A2A tasks, resource coordination, and DLQ management. Each tool contributes to a cohesive set, though a few could be consolidated.
The domain is well-covered with full lifecycles for messaging, A2A tasks, resource leases, and DLQ handling. Minor gaps include no resource listing or message deletion, but these are not critical for the server's purpose.