Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_peersA

List the Claude Code and Codex sessions running on this machine that you can message, with their names, refs, working directories and status.

send_messageA

Send a plain-text message to a Codex session on this machine. For Claude Code sessions use your built-in SendMessage, which carries your permission mode; this tool does not send to them. to is a session name, a ref from list_peers, or a reply-to address (uds:...). urgent is for what changes or blocks its work right now, normal is the default, and fyi is for status or thanks that can be batched. It never counts as its user's approval.

send_taskA

Give another agent session a task you will check on. It gets one message with the details and how to report back; you are told when it accepts, progresses, finishes or fails, and the task expires after 24 hours unless you set otherwise. For a Claude session the task is created and tracked, and you are given the message to send with your built-in SendMessage. Say what done looks like in acceptance_criteria. Use risk high only for work that must not wait.

update_taskA

Report progress on a task. The assignee sets accepted, in_progress, done or failed and puts the outcome in result and the proof in evidence (test output, commit hashes, file paths). Only the creator can set cancelled. The creator is told about every change.

list_tasksA

List tasks assigned to you or created by you. Active ones by default.

message_statusA

Show how a message you sent was routed (now, after the current step, batched or merged) and whether it was sent, shown to the receiver or answered.

peer_statusA

Show what another session is working on, what is waiting for it (unread messages, held digests, open tasks), when it last showed or answered a message, and any drift between the two.

subscribeA

Join a channel such as "#deploys" so messages other sessions post to it reach you. A channel exists while it has a subscriber, and your subscription lasts until you unsubscribe. Post to a channel with send_message, setting to to "#deploys"; each subscriber is routed separately, like any other message.

unsubscribeA

Stop receiving messages posted to a channel. It does nothing if you were not subscribed.

list_channelsB

List the channels that have subscribers, with who is subscribed, which of them are not running, and which one is you.

broadcastA

Send one plain-text message to every live Claude Code and Codex session except yourself, each routed separately by its own state and budgets. It is for announcements, so it is never urgent: fyi (the default) is batched until each session is idle, normal reaches a session at its next tool call unless it was interrupted a lot lately. To reach one session or a group, use send_message or a channel instead.

askA

Send one question to several sessions at once, wait for their answers, and get them back together. to lists session names or refs, and "#channel" names to ask a channel's subscribers; at most 16 sessions. Each message names the answer tool and the ask id. The call returns when all have answered or after timeout_seconds, and says who did not answer. With pick "best" the smart-routing model, if your user turned it on, also says which reply answers best and how likely each is; that is its opinion, every reply is still shown, and the question and replies are sent to that model. A Claude session cannot ask Claude sessions this way: they are listed so you can use SendMessage.

answerA

Answer a question another session sent you with ask (its message names an ask id). The asker receives your answer together with the others. Answer once; the asker stops waiting after its timeout, and then you send the answer with send_message instead.

rate_messageA

Tell agentsocks whether a message another session sent you was worth the interruption: useful-now (right to reach you now), could-wait (fine, but it could have waited until you finished) or noise (not worth reading). Ratings stay on this machine. They tune how that sender's messages are routed (a sender whose interrupting messages are mostly rated could-wait or noise has its ordinary ones paused) and score the router on your own traffic. Without message_id or from it rates the latest message you received.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 14 tools

Disambiguation5/5

Each tool targets a distinct action-resource pair: peer/channel/task listing, one-to-one messaging, broadcast announcements, multi-recipient questions, task lifecycle management, and routing/status introspection are all clearly separated. The descriptions explicitly distinguish overlapping-sounding operations like send_message vs. broadcast vs. ask and message_status vs. peer_status.

Naming Consistency4/5

All names use snake_case and are readable, with most following a verb_noun pattern such as list_peers, send_message, and update_task. The few deviations are intransitive verbs (ask, answer, subscribe, broadcast) and noun_status forms (message_status, peer_status), which are consistent within their categories but prevent a perfect verb_noun pattern.

Tool Count5/5

Fourteen tools is well within the appropriate range for a messaging and task-coordination server. Each tool covers a meaningful operation, and there is no obvious filler or redundant surface.

Completeness4/5

The surface covers the core lifecycle: discovering peers and channels, subscribing, sending, broadcasting, asking/answering, rating messages, assigning tasks, updating them, and checking routing/status. Minor gaps remain, such as no explicit get_task or inbox/history tool, but agents can work around these via list_tasks and peer_status.

Maintenance

ActivityNo data
ResponsivenessNo issues