Skip to main content
Glama

dialogbrain

by com.dialogbrain
OverviewDiscussionsAdmin

messages_read_history

Read-onlyIdempotent

Read messages from a conversation thread. Use text_contains to find specific messages by content. text_contains searches the loaded part of the conversation and, when that is not all of it, asks the channel's own server (Telegram) to search the rest and stores the hits with their neighbouring messages. search_coverage says which: complete = true with a source, or complete = false with the reason, in which case an empty list is not proof the text is absent. Returns the most recent messages, including sender info and timestamps.

Voice calls: each row carries a meta object with allowlisted keys (event_type ∈ 'call_started'|'call_ended'|null, source ∈ 'voice_transcript'|null, call_id, speaker_display_name, duration_seconds, outcome, direction) plus per-message channel. To find calls without scanning every row, use calls.list_history instead.

Usage:

  1. Get thread_id from threads.list first, OR

  2. Use contact_name to auto-resolve thread_id

Examples:

  • User: 'show me messages from chat with [contact]' → read_history(contact_name='[contact]', limit=10)

  • User: 'last 5 messages from thread 571' → read_history(thread_id=571, limit=5)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of messages to return (default: 10, max: 100)
offsetNoNumber of messages to skip (for pagination, default: 0)
thread_idNoThread ID from threads.list (e.g. '571'), or a channel_ref (e.g. 'telegram:1306644770'). Optional if contact_name provided.
contact_nameNoContact/thread name to search for (optional if thread_id provided). Example: 'Jane Smith', 'John Doe'
in_workspaceNoRun this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.
text_containsNoFilter: only return messages containing this text (case-insensitive substring match)
include_outgoingNoInclude messages sent by you (default: true)
channel_account_idNoConnected account the conversation must belong to, when you know it (from channels.list). Scopes the lookup to that account, so the same person reached on two connected accounts cannot be confused for one, and a chat that does not exist on this account is 'not found' instead of someone else's thread with a matching id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / channel_account_id
      Added value: +{
+  "description": "Connected account the conversation must belong to, when you know it (from channels.list). Scopes the lookup to that account, so the same person reached on two connected accounts cannot be confused for one, and a chat that does not exist on this account is 'not found' instead of someone else's thread with a matching id.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / in_workspace
      Added value: +{
+  "description": "Run this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.",
+  "type": "integer"
+}
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the server-side Telegram search triggered by text_contains, the search_coverage complete/source/reason contract, and the meta object shape for voice-call rows. The only slightly opaque point is that hits are 'stored' with neighbouring messages, an internal caching behavior that is not fully explained relative to readOnlyHint.

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 purpose and constraint, then organized into search semantics, voice-call metadata, and usage. The voice-call allowlist and duplicate usage/example blocks are somewhat verbose, but nearly every sentence carries operational value.

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 tool with no output schema, the description still covers the return shape ('most recent messages, including sender info and timestamps') and the nested meta/channel fields for call rows. Combined with usage routing, coverage caveats, and the calls alternative, an agent has everything needed to call 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 coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: text_contains is explained as a loaded-history filter with server fallback, and contact_name is framed as an auto-resolver for thread_id. Remaining parameters (limit, offset, in_workspace) carry no extra context, keeping it short of 5.

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

Purpose4/5

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

The description opens with a specific verb+resource ('Read messages from a conversation thread') and clearly states the scope is one thread. It differentiates itself from calls.list_history but never contrasts itself with the sibling search_messages/search_threads, which an agent could plausibly confuse with a text_contains lookup.

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 numbered usage ('Get thread_id from threads.list first, OR use contact_name to auto-resolve') plus two concrete request→call examples. It also states when to prefer a different tool (calls.list_history for calls) and warns that an empty list is not proof of absence when search coverage is incomplete.

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

All dialogbrain toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources