Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
CODEX_HOMENoHonoured for locating Codex state. Default ~/.codex.~/.codex
TINCAN_HOMENoWhere 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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 status_unreadable is reported busy as a safe default, not because it was observed busy — treat it as busy, and do not report its state as a fact. Show display_label to the user: unnamed sessions use project · short ID. When display_label differs from name, also show the full durable ID for copying. Use name, not display_label, when calling send_peer. This session is never in the list; self is the address that reaches it — give self.name (or self.canonical_id) when asked for your own peer name, never a bare session id, which send_peer does not accept. Also returns tincan_version: the Tin Can serving this call, and per peer the version its own Tin Can recorded — report those rather than shelling out to tincan --version, which reports whatever is on PATH instead of what is running. Call this before send_peer: names change and sessions come and go.

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 peers. 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. Returns outcome: accepted means the peer's harness took the message — NOT that the peer has read it, acted on it, or ever will, so tell your user it was sent, not that it was received. rejected means nothing was sent and something about the call needs fixing (see refusal); sending it again unchanged will fail the same way. failed means it was attempted and the peer or transport did not take it; nothing you did is wrong and later may work. For peers, you get requested and accepted counts plus a results entry per recipient instead.

message_logA

Read the Tin Can message log — what was sent, to whom, and what became of it. Each record carries an outcome: accepted (the peer's harness took it), failed (it was attempted and refused), or indeterminate — written out, with nothing ever observed about what happened next, which is what a crash mid-send leaves behind. Do not report indeterminate as either success or failure; it means nobody knows. A record with kind: "unsent" is a send that never became a message — the peer was unknown, unreachable, or had been replaced by another session of the same name — and carries to_address and reason. It is how you find that someone tried to reach a session while it was down. Filter by peer, or follow a reply chain from a message id. If an integrity field comes back, read it: ok: false means the log is damaged or was edited and what you are reading is an incomplete account — say so rather than treating it as the whole record. A rotated field is not damage; it means older history was deliberately archived and names where it went — and the archive IS searched when a query comes up short, so rotation does not hide history from you. If rotated.complete is false, only part of the archive was read and something absent from your result may simply be further back; do not report it as never sent. Neither is interleaved, which counts records written by concurrent sessions appending to this one machine-global log: nothing is missing on account of it, and it never makes ok false. An empty result with ok: true means nothing was sent — it is not evidence that something was lost.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.6/5.0

Scored across 4 tools

Disambiguation5/5

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.

Naming Consistency3/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive