Skip to main content
Glama
yomi

yomi

Official
by RikaiDev

get_unread_digest

Returns a read-only digest of all unread LINE conversations with recent decrypted messages and sender names, so you can review unread activity in one call.

Instructions

One-shot unread digest: every LINE conversation with unread messages (all pages of the inbox, newest activity first), each with its most recent messages (default 10), E2EE-decrypted, with resolved sender names. Saves calling list_conversations then get_chat_messages per chat. Read-only: never marks anything read, never touches the search index; denylist-excluded conversations are omitted. Returns an empty list when nothing is unread — never fabricated.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of unread conversations to return, most recently active first (default: all of them).
perChatNoMaximum recent messages to include per unread conversation (default 10).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.2
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum number of conversations to scan for unread (default 20)."New value: +"Maximum number of unread conversations to return, most recently active first (default: all of them)."
  2. Addedv0.4.1
  3. Removedv0.3.0
  4. First observedv0.2.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations supplied, the description carries full behavioral burden and does so: read-only with no read-state mutation, no search-index side effects, E2EE decryption, denylist-excluded conversations omitted, ordering guarantee, and an explicit guarantee of an empty list rather than fabricated data. These are exactly the mutation/side-effect facts an agent needs before calling an unannotated tool.

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?

Front-loaded with the core deliverable and every clause adds information (decryption, denylist, empty-list guarantee). It is a single dense run-on sentence with heavy parentheticals, which is efficient but slightly harder to scan than a split structure would be.

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?

No output schema exists, so the description must convey the return shape, and it does: a list of conversations, each with its most recent messages and resolved sender names, empty when nothing is unread. Combined with the disclosed filtering and ordering, an agent has everything required to call and interpret the result.

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 coverage is 100% so the baseline is 3, and the description goes slightly beyond by tying 'limit' to newest-activity-first ordering and restating the perChat default of 10 alongside 'most recent messages'. It still doesn't explain interaction between the two limits or whether paging exists, so the gain over the schema is modest.

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?

Names a specific verb+resource ('one-shot unread digest') and immediately scopes it ('every LINE conversation with unread messages'), which cleanly separates it from list_conversations and get_chat_messages, both of which it partially replaces. An agent can tell what it returns without opening the schema.

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?

Explicitly frames the use case by saying it 'saves calling list_conversations then get_chat_messages per chat', so the agent knows the alternative workflow it replaces. It does not state when NOT to use it (e.g. for read/archived chats, or when the agent needs full history), and it doesn't route to mark_read for the follow-up action, so it falls short of a full 5.

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