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 | {} |
| 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 plain-text message to a hoptell peer by name (offline peers get it when they reconnect), or to @ / @all (every ONLINE peer with that role / every online peer; not queued for offline peers). |
| wait_for_messageA | Block until a peer message arrives (or the timeout passes), then return it. Use this to listen when messages are not pushed to you (e.g. in Codex). |
| read_inboxA | Return and clear messages received from peers that were not pushed to you. |
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 4 tools
Each tool has a clearly distinct purpose: list peers, retrieve queued messages, send messages, and block for incoming messages. The potential overlap between read_inbox and wait_for_message is well-resolved by descriptions specifying non-blocking retrieval versus blocking wait.
All tools follow a consistent snake_case verb-first pattern (list_peers, read_inbox, send_message, wait_for_message). The slight variation in wait_for_message with a preposition is common and does not break predictability.
Four tools is well-scoped for a peer messaging server, covering discovery, sending, queued receiving, and blocking receiving without redundancy or bloat. Every tool earns its place.
The surface covers the full messaging lifecycle: peer discovery, send (including broadcast to roles/all), and two complementary receive modes (non-blocking queued and blocking wait). No obvious gaps for the stated purpose.