Skip to main content
Glama
BrutalSystems

tincan

Official
by BrutalSystems
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Read message log

message_log
Read-only

Read Tin Can's log to inspect sent messages, recipients, delivery outcomes, and unsent attempts. Filter by peer or follow reply threads to trace conversations and audit failed or indeterminate sends.

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 host 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. Strict pull records omit bodies; accepted means stored, not read. Retrieve eligible content with receive_peer_messages. 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

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 changedv3.2.0
    • changedInput schema / properties / last_n / type
      Previous value: -"number"New value: +"integer"
  2. 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"
+}
  3. 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"
+}
  4. First observedv0.1.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description carries the real behavioral load — outcome taxonomy, unsent records with `reason`, body omission on strict pull, integrity failures, rotation and archive search, interleaving by concurrent sessions, and empty-result semantics. This is exactly the context an agent needs before reporting findings.

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

Conciseness4/5

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

The purpose is front-loaded and nearly every sentence carries operational meaning (outcome semantics, rotation caveats). It is dense as a single unbroken paragraph, though; grouping the outcome/integrity/rotation caveats would improve scannability without losing content.

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?

For a read tool with no output schema and a rich but non-obvious result surface (integrity, rotated, interleaved, scope_note), the description covers every field an agent might misreport and explicitly warns against the common misinterpretations. Nothing essential to calling it correctly is missing.

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 description coverage is 100%, so the schema already explains all five parameters (including a detailed `missed` description and the `scope_note` caveat for `all_projects`). The description only restates filtering by peer and reply-chain following via message id, adding little beyond what the schema provides.

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?

States a specific verb and resource — 'Read the Tin Can message log — what was sent, to whom, and what became of it' — which is far more than the name 'message_log' conveys. It also draws the boundary against a sibling by directing body retrieval to receive_peer_messages.

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

Usage Guidelines5/5

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

Explicit routing: use receive_peer_messages for eligible content, use this for log/outcome/history, and use the `missed` behavior when the session may have been unreachable. It also gives clear do-not rules (don't report `indeterminate` as success or failure) and tells the agent how to interpret empty results.

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