Skip to main content
Glama

get_unanswered_chats

Read-only

Lists one-to-one chats whose last message came from the other person within the last hours_ago hours (default 24, max 72), so the user may owe them a reply. Groups aren't included. Checks the 50 most recent active chats in that window, newest first; an empty list means none of them is waiting for a reply. Each chat has its chat_jid, the time and sender of the last message, a preview, and the contact fields (name; name_source: address_book, push_name, group_subject, business, phone or unresolved; canonical_jid: the JID to pass to send_message and read_chat_history; phone_jid and lid_jid: the chat's phone-number and LID forms, null when unknown or for groups; phone_display: the number as +). Use it for "who do I need to reply to?". For a general look at recent activity, including groups and chats where the user wrote last, use get_recent_chats instead.

Input Schema

NameRequiredDescriptionDefault
hours_agoNoFetch unanswered chats active within this many hours (default 24, max 72).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / hours_ago / description
      Previous value: -"Mandatory. Fetch unanswered chats active within this many hours (e.g. 24)."New value: +"Fetch unanswered chats active within this many hours (default 24, max 72)."
    • removedInput schema / required
      Removed value: -[
      -  "hours_ago"
      -]
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), yet the description still adds genuinely new behavior: a hard scan limit of the 50 most recent active chats, newest-first ordering, and the meaning of an empty result. It doesn't say what happens when the 50-chat cap is hit and matches are truncated, which is the one operational caveat left unstated.

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 and window are front-loaded, then the scan behavior, then the return fields, then the alternative — a sensible ordering. The long parenthetical enumerating every return field is dense and reads as a run-on, but it is load-bearing because no output schema exists.

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?

With no output schema, the description carries the return-shape burden and does so: chat_jid, last-message time/sender, preview, and the contact fields with their value semantics (name_source enumerations, canonical_jid usage, null conditions for phone_jid/lid_jid). An agent has enough to call the tool and interpret results.

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?

With 100% schema description coverage and a single optional parameter, the schema already carries the default and max, and the description's restatement of "default 24, max 72" is largely duplicative. Baseline 3 applies; no additional semantics such as how the window interacts with the 50-chat cap are given.

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 (lists one-to-one chats) plus the defining filter: last message from the other person within the hours_ago window. It explicitly excludes groups and names the sibling get_recent_chats as the contrasting scope, so an agent can distinguish the two without opening either schema.

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 an explicit triggering intent ("Use it for 'who do I need to reply to?'") and a named alternative with the condition that selects it ("For a general look at recent activity, including groups and chats where the user wrote last, use get_recent_chats instead"). Both when-to-use and when-not-to-use are covered.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources