Skip to main content
Glama
ZenonEl

herald

by ZenonEl
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

inbox_done

Mark inbox messages as archived after confirming their saved copies, using an archive_ref to record the destination and free up disk space while keeping recoverable records.

Instructions

Mark messages as archived, which deletes their downloaded copies.

Call this only after the messages are in the archive with their hashes. Pass a non-empty archive_ref that identifies the recorded destination/batch. Herald stores it as opaque evidence and does not parse it or call the archive. If there is no archive reference, do not mark the messages done. The buffer copy of a file is redundant from that moment and is what actually grows on disk. Each key is {"chat_id": int, "message_id": int}. Rows survive for the configured TTL so a mistake stays recoverable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keysYes
archive_refYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.8.0
    • addedInput schema / properties / archive_ref
      Added value: +{
+  "title": "Archive Ref",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "keys"
-]New value: +[
+  "keys",
+  "archive_ref"
+]
  2. First observedv0.3.0

TDQS

A4/5.0
Behavior1/5

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

The description says the tool 'deletes their downloaded copies,' which directly contradicts the annotation destructiveHint=false. This is an annotation contradiction, so the description cannot receive credit for behavioral transparency despite also disclosing TTL-based recoverability.

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 description is front-loaded with the purpose and precondition, and every sentence adds substantive guidance. The buffer/disk explanation is slightly verbose but earns its place by explaining why deletion is safe.

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 two-parameter tool with no output schema, the description covers the prerequisite, the required parameters, opaque reference semantics, and recovery behavior. An agent has enough context to decide when and how to invoke it correctly.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must carry the load. It defines each key as {chat_id: int, message_id: int} and requires a non-empty archive_ref identifying the recorded destination/batch. It could clarify the shape of the keys array itself, but the parameter semantics are meaningfully specified.

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?

Description states a specific action ('Mark messages as archived') and its concrete effect ('deletes their downloaded copies'). It is clearly distinct from sibling inbox tools like inbox_fetch, inbox_status, and inbox_export.

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?

Gives explicit preconditions: call only after messages are in the archive with hashes, and explicitly says not to call if no archive_ref exists. It also warns that archive_ref is opaque and will not be parsed or called, so the agent knows not to treat it as a live reference.

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