agentsocks
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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. |
| 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 |
| 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. |
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
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.
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.
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.
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.