hoptell
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HOPTELL_ENV | No | Path to a settings file to load environment variables from | |
| HOPTELL_HOME | No | Local state directory (default ~/.hoptell) | |
| HOPTELL_NAME | No | This agent's peer name (letters, digits, _ and -). Default <hostname>-<pid>. | |
| HOPTELL_PUSH | No | Push mode: 'channel' or 'listener', overrides detection | |
| HOPTELL_RELAY | Yes | Relay URL, ws://host:7777 or wss:// behind TLS | |
| HOPTELL_ROLES | No | Comma-separated roles for routing messages, e.g. reviewer,backend | |
| HOPTELL_TOKEN | Yes | Shared secret, or a member's own token |
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
} |
| experimental | {
"claude/channel": {}
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_peersA | List hoptell peers (agent sessions on this or other machines) and whether they are online. |
| send_messageA | Send a text message to a named peer, or broadcast to @ or @all. Direct messages can be queued for known offline peers. Broadcasts target online peers only and are not queued for offline peers. Snapshot command: |
| wait_for_messageB | Wait for inbox messages up to timeout_seconds and return them. Use this only when this session's delivery instructions call for waiting. The wait can also end for a held-message notice or cancellation. Review a snapshot's supplied content; its file label is not a local path. Reply with review_request_id, based_on set to its sha256, and reply_to when available. Before using a local checkout, run |
| read_inboxC | Return messages received from peers. Listener command (listener delivery only): |
| ack_messagesA | Acknowledge a handled message batch using its receipt. Unacknowledged messages may reappear after the configured acknowledgement timeout. |
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 5 tools
The tools mostly have distinct roles: list peers, send, read, acknowledge, and wait. The main overlap is between read_inbox and wait_for_message, since both return inbox messages, though wait_for_message is explicitly conditional on delivery instructions.
All tool names use snake_case with a verb-first pattern: list_peers, send_message, ack_messages, wait_for_message, and read_inbox. The slight variation between 'messages' and 'inbox' is natural and does not break predictability.
Five tools is well scoped for a peer-messaging server. Each tool corresponds to a core action: discovering peers, sending, receiving, waiting, and acknowledging.
The core messaging lifecycle is covered: peer discovery, send, read, wait, and acknowledge. Minor gaps remain around message history, sent-message inspection, or richer peer state, but the essential workflows are present.