Agent Bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AGENT_ID | Yes | Sender identity for this MCP server process. Use `claude` for the Claude Code side or `kimi` for the Kimi CLI side; both sides must use opposite values. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| listenerA | Manage this agent's own background listener (AGENT_ID only). status: enabled/running/pid and the id of the message the listener is currently waiting on — never task payload. enable: removes the disabled marker and idempotently starts the listener (duplicate sessions create no duplicate — the listener holds an exclusive flock). disable: writes the marker; the listener then takes no new task, lets the current worker finish and exits. No PID is ever killed from here. Dispatch itself stays governed by systemd/config.json auto.. |
| send_messageA | Send a message to another agent; sender is this process's AGENT_ID. reply_to optionally links this message to the id of a previous message (use it to answer requests). response_timeout_seconds (clamped to 1..3600) is persisted as response_deadline = now + timeout: pure metadata for the receiver — nothing is timed, deleted or resent automatically; after a deadline report it and wait for human direction, late replies stay valid. dedup_key (e.g. a task id): repeating the same (sender, dedup_key) returns the existing message with duplicate=true and inserts nothing. Returns the message id either way. Conversation messages belong to a bounded autonomous dialogue (see start_conversation): pass conversation_id and kind — 'task' (substantive work that wakes the recipient's listener), 'result' (report on a task; wakes the initiator's review worker only while the conversation is active) or 'notice' (informational, never wakes a worker). Omit conversation_id to inherit it from the conversation of reply_to. Conversation sends are validated atomically: the dialogue must be active and unexpired, the message must answer its task/result and go back to that message's sender, exactly one message may be in flight, and each task/result takes one turn (a send past the turn limit moves the conversation to needs_human and is rejected). A send_message without kind is a plain message and never becomes autonomous. |
| start_conversationA | Start a bounded autonomous conversation with another agent. Creates a conversation (goal, initiator = AGENT_ID, recipient, state active) and posts its root task as turn 1, so the recipient's listener picks it up without any manual phrase. The two agents then exchange task/result messages inside this conversation until one marks it completed or needs_human, the turn limit or expiry is reached, or it is cancelled. The limit counts every automatic worker turn (result reviews included); max_turns is clamped to 2..20 (hard cap 20) and the expiry window to 60..86400 s. A worker reaching the limit or a stopped state must not spawn new work: the dialogue goes to needs_human for a human. dedup_key makes repeated starts idempotent (existing root task, duplicate=true). An ordinary send_message never creates a conversation. |
| conversationA | Inspect or steer a conversation only its two agents belong to. status — state, turn_count/max_turns, expiry, recent transitions and the in-flight message; never the goal text, never message text (no payload, no secrets). cancel — stop all further automatic dispatch for it (side effects already produced are NOT rolled back); allowed from active/blocked/needs_human. complete — the initial goal is verifiably achieved (the review worker's outcome a; only from active). needs_human — a human decision is required (outcome c; only from active). Repeating the call for the state the conversation is already in is an idempotent no-op; a different terminal state is rejected, so the two agents can never fight over the outcome. |
| claim_messageA | Atomically claim an unread message for this MCP server process. An active claim by another process cannot be taken over, acknowledged or released. Repeating the call as the current owner renews the lease. An expired claim can be taken by any process belonging to the recipient. lease_seconds is clamped to 30..3600; expiry is checked during tool calls, without background timers. |
| release_messageA | Release this process's active claim without acknowledging the message. |
| receive_messagesB | Return available unread messages addressed to AGENT_ID, oldest first. Messages actively claimed by another server process are hidden. Waits up to wait_seconds, capped at MAX_WAIT_SECONDS (30). Messages stay unread until mark_read. Each message carries response_deadline, claim_expires_at and owned_by_current_worker; cursor is the last returned id, or None. |
| mark_readA | Acknowledge messages by id; only their recipient (AGENT_ID) can do so. Already-acknowledged, foreign and actively claimed-by-other-worker ids are skipped silently. Free messages and expired claims remain compatible with the original recipient-only acknowledgement behavior. |
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 8 tools
Most tools target clearly distinct operations: listener controls the local daemon, send_message emits, receive_messages reads, and claim/release/mark_read handle message ownership and acknowledgement. The main soft spots are send_message versus start_conversation (start implicitly posts a root task) and receive_messages versus claim_message, though the descriptions spell out the difference reasonably well.
Six of eight tools follow a clear verb_noun pattern (send_message, start_conversation, claim_message, release_message, receive_messages, mark_read), which is highly readable. The two outliers, 'listener' and 'conversation', are bare nouns, a minor deviation from the otherwise predictable convention.
Eight tools is a well-scoped surface for an inter-agent messaging bridge, with each tool covering a distinct lifecycle step (dispatch, inbox, claim lease, ack, conversation control). No tool looks redundant or gratuitous.
The message lifecycle is well covered end-to-end: send with dedup/reply linking, receive, atomic claim with lease, release, acknowledge, plus bounded conversation start/inspect/steer and listener enable/disable. Minor gaps remain — there is no direct 'get message by id' or 'list conversations' operation, so agents must go through receive_messages or track ids themselves.