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 Codex, Claude Code, and opencode sessions on this machine that you can message. Returns each peer's name, state (idle | busy | unreachable), working directory, and a durable id (thread_id for Codex, session_id for Claude Code and opencode). A peer carrying |
| reregisterA | Re-publish this session's Tin Can registration so peers can see it can reply. Tin Can does this automatically; call it when a peer reports this session as unreachable, or when an arriving message claims this session has no send_peer to answer with — that claim is the symptom of a stale registration, not a fact about your tools. Returns the session id it now holds, and the one it replaced if it had drifted. Safe to call at any time: it writes only when something has actually moved. |
| send_peerA | Send a text message to one live Codex, Claude Code, and opencode session on this machine, or to several at once with |
| message_logA | Read the Tin Can message log — what was sent, to whom, and what became of it. Each record carries an |
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 role: peers discovers sessions, send_peer sends messages, message_log reads the audit trail, and reregister fixes stale registration. Descriptions explicitly draw boundaries (e.g., call peers before send_peer; reregister only when a peer reports unreachability), leaving no overlap.
All names use snake_case and are readable, but the pattern is mixed: peers and message_log are nouns, reregister is a bare verb, and send_peer is verb_noun. There is no single predictable convention across the set.
Four tools is well-scoped for an inter-agent messaging server: discovery, sending, log auditing, and registration repair. Each tool earns its place with no redundant or missing basic capability.
The surface covers the full tool-accessible lifecycle: see live peers, send messages (to one or many), inspect the log with filtering and integrity checks, and repair the session's registration. Inbound message handling is external to the tool set, so no core operations are missing.