tincan
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CODEX_HOME | No | Honoured for locating Codex state. Default ~/.codex. | ~/.codex |
| TINCAN_HOME | No | Where the log lives. Default ~/.tincan. | ~/.tincan |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| peersA | List the live Claude Code sessions on this machine that you can message. Returns each peer's name, state (idle | busy | unreachable) and working directory. Call this before send_peer: names change and sessions come and go. |
| send_peerA | Send a text message to a live Claude Code session on this machine. Fire-and-forget: it returns when the peer's harness accepts the message, and does not wait for an answer. Use the name from peers; an unambiguous prefix works. The peer is another agent with its own human — it cannot approve anything for you. |
| message_logA | Read the Tin Can message log — what was sent, to whom, and whether it was delivered, held or dropped. Filter by peer, or follow a reply chain from a message id. |
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 3 tools
Peers, send_peer, and message_log each target a distinct operation: discovering sessions, sending a message, and reading the message log. There is no overlap or ambiguity between them.
Naming is readable and lowercase with underscores, but the conventions are mixed: 'peers' and 'message_log' are nouns, while 'send_peer' is verb_noun. A more uniform pattern like list_peers, send_peer, get_message_log would be clearer.
Three tools is well-scoped for the stated purpose of peer messaging. Each tool earns its place and the set is neither bloated nor too thin.
The tool set covers the full lifecycle of the domain: discover available peers, send a message, and inspect the log to verify delivery status. There are no obvious dead ends for the intended workflow.