Skip to main content
Glama
BrutalSystems

tincan

Official
by BrutalSystems
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

message_log

Read Tin Can's message log to check sent messages, delivery outcomes (accepted, failed, indeterminate), and unsent items; filter by peer or follow reply chains.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
peerNoOnly messages to or from this peer name.
last_nNoHow many records to return.
missedNoMessages someone tried to send you while you were not reachable, that they asked to have held for you and that are still in date. Worth calling if this session was restarted or resumed and may have been unreachable for a while. Returns nothing unless a sender explicitly left something, so an empty result means nobody did — not that nobody tried.
threadNoA message id; follows the in_reply_to chain from it.
all_projectsNoBy default you see only messages where one end is this project (by working directory). Set true to read every conversation on the machine, including other projects. If a result is empty, check `scope_note` before concluding nothing was sent.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.3.0
    • addedInput schema / properties / missed
      Added value: +{
+  "default": false,
+  "description": "Messages someone tried to send you while you were not reachable, that they asked to have held for you and that are still in date. Worth calling if this session was restarted or resumed and may have been unreachable for a while. Returns nothing unless a sender explicitly left something, so an empty result means nobody did — not that nobody tried.",
+  "type": "boolean"
+}
  2. Changed1 schema field changedv1.0.1
    • addedInput schema / properties / all_projects
      Added value: +{
+  "default": false,
+  "description": "By default you see only messages where one end is this project (by working directory). Set true to read every conversation on the machine, including other projects. If a result is empty, check `scope_note` before concluding nothing was sent.",
+  "type": "boolean"
+}
  3. First observedv0.1.1

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it excels: it defines outcome values, explains how to treat indeterminate and unsent records, and warns about integrity failures, rotated archives, and interleaved concurrent writes. It directly instructs the agent not to misreport ambiguous states as success, failure, or loss.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence earns its place, covering distinct caveats that materially affect how the agent should interpret results. It is front-loaded with the core purpose and then layers necessary edge-case guidance without repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description comprehensively covers return-field semantics, failure modes, archive behavior, and what empty results mean. An agent has enough context to call the tool and correctly interpret ambiguous responses.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and every parameter already has a rich description, so the baseline applies. The main description adds interpretive context for result fields rather than new meaning for the input parameters themselves.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: 'Read the Tin Can message log — what was sent, to whom, and what became of it.' This clearly distinguishes it from the sibling tools, peers and send_peer, which concern discovery and sending rather than reading history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear invocation context: filter by peer, follow a reply chain, and call with missed after a restart if the session may have been unreachable. It also tells the agent how to interpret empty results. It does not explicitly name send_peer/peers as alternatives, so it falls just short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools