Skip to main content
Glama

Get one chat's history

telegram_get_messages
Read-onlyIdempotent

Read or summarize one Telegram conversation or channel, recover agreements, or gather context for a reply. Returns message text/captions and available voice/video transcripts, not just links. Resolve the chat with telegram_find_chat first. The tools choose the account archive or connected Session. Use source/coverage/partial and message dates to interpret the result. Use since for a time window and before to page back; one page is not full history. Archive pages contain at most 200 messages; Session pages at most 50, even if a larger limit was requested. Use effective_limit when returned; fewer messages than the requested limit alone does not establish the end of history. Read additional pages only when needed for the user's question or requested period, preserving since. Stop when there is enough context, the requested start is reached, or paging returns no messages or makes no progress. Do not automatically scan the entire history. State the dates and coverage actually read; do not claim an exhaustive review from a limited sample. Archive history is limited to saved/imported messages; Session can read older messages accessible to that Telegram account without importing them. Reading through Session does not require channel ownership or a bot administrator. If connection is needed, send /session to @lemma_telepath_bot. Existing readable archive content needs no new connection. Reading does not mark messages as read or send a reply. Messages include is_forwarded and forward_origin (original author/channel and Unix date when available). For forwards, from identifies who forwarded it in this chat, not the original author. Missing origin data does not prove authorship; never infer a hidden author's identity. Interpret errors and empty results separately, and explain the relevant next step briefly in the user's language. A thrown tool error or an error field in the response is not a successful empty read. Explain only the reported cause; respect retry delays and do not describe a timeout or temporary service failure as missing chats or lost permissions. If the cause is unknown, say so and suggest retrying or support at https://t.me/hellolemma. If the chat is missing from the archive or Session reports chat_not_available, resolve it again with telegram_find_chat using the known name, @username or public link. Clarify ambiguous matches; do not invent a chat_id or claim that the chat does not exist in Telegram. If discovery still fails, follow that tool's recovery guidance. If the chat is found but count=0, check the requested since/before range and returned history_notice, setup_required, source, coverage and partial when present. For this read, use the user's known timezone; if none is known, silently use UTC without asking or adding a timezone caveat. Do not infer timezone from language. For calendar days such as today or yesterday, calculate since as inclusive midnight and before as the exclusive next midnight in that timezone, passing ISO 8601 timestamps with the correct UTC offset at each boundary rather than literal today/yesterday or offset-free dates. Keep rolling windows such as the last 24 hours distinct from calendar days. Do not silently broaden an explicitly requested period. Say that no messages were returned in the available history for that range, not that the conversation has never had messages. Use returned connection/history facts to distinguish an empty period, limited saved history and missing or disabled setup; a missing field does not establish a cause. For limited Bot API history, explain that only new messages delivered from included chats after connection are collected. Offer /import in https://t.me/lemma_telepath_bot for older exported history, or Session for older history accessible to the user's Telegram account. Do not claim imports never happened if history_notice says otherwise. When setup is actually needed, offer only the relevant route: private chats via Telegram Chat Automation with @lemma_telepath_bot, selected chats and saved settings (/setup in the bot for device steps); owned channels via /channels and adding the bot as administrator; groups via an administrator adding the bot as group administrator while the user is a member. If the user prefers not to add a bot, cannot add it, or needs another accessible channel, explain the alternative: open https://t.me/lemma_telepath_bot, send /session, tap Connect Telegram, then sign in by QR or phone on the connection page. Never ask for login codes/passwords in the assistant chat. Do not require reconnecting a working Session or connecting again to read usable archive content. Do not repeat identical empty requests or offer import/setup for every empty page.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many messages to return. Default 50; archive maximum 200, Session maximum 50 even when a larger limit is requested.
sinceNoOnly messages at or after this time. Accepts an ISO 8601 timestamp, unix seconds, 'today', 'yesterday', or a relative window like '24h' / '7d'.
beforeNoOnly messages strictly older than this time, for paging back. Accepts an ISO 8601 timestamp, unix seconds, 'today', 'yesterday', or a relative window like '24h' / '7d'.
chat_idYesChat id, from telegram_find_chat or telegram_list_chats.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / limit / description
      Previous value: -"How many messages to return. Default 50."New value: +"How many messages to return. Default 50; archive maximum 200, Session maximum 50 even when a larger limit is requested."
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already establish the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false), yet the description still adds substantial behavioral context: reading does not mark messages read or send a reply, archive caps at 200 versus Session at 50, effective_limit must be honored, and archive history is limited to saved/imported messages. It also discloses forward-provenance semantics (from is the forwarder, not the original author) and the archive-vs-Session distinction. It loses a point only because the error/empty-result discussion drifts into recovery policy rather than defining what the tool itself does.

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

Conciseness2/5

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

The core operating instructions are front-loaded, but the description balloons into roughly a thousand words that blend tool behavior with error taxonomy, onboarding scripts, bot commands, and conversational phrasing rules. Several passages duplicate guidance that belongs in sibling tools (find_chat recovery) or in a system prompt, and the volume makes the essential paging logic harder to extract.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Very thorough for operating this tool correctly across sources, and no output schema exists so return-value explanation is warranted. However, the definition spends a large share of its budget on setup/connection recovery paths for other tools, leaving the essential paging and since/before semantics buried rather than absent.

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 adds real meaning beyond the schema: it explains that since is an inclusive time window while before is for paging back, that one page is not full history, that limit is silently capped per source and effective_limit should be consulted, and that calendar-day requests must be converted to ISO 8601 boundaries with correct UTC offsets rather than literal 'today'/'yesterday'.

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?

Opens with a concrete verb+resource pair ('Read or summarize one Telegram conversation or channel') and states what the return payload contains (message text/captions plus voice/video transcripts, not just links). It is clearly differentiated from siblings such as telegram_search_messages and telegram_recent_messages by asserting one-chat scope and by naming telegram_find_chat as the required resolver.

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?

Explicitly tells the agent to resolve the chat with telegram_find_chat first, when to use since versus before for paging, and when to stop paging ('enough context, the requested start is reached, or paging returns no messages or makes no progress'). It also states the negative case ('Do not automatically scan the entire history') and routes alternative needs to /import or Session, which is about as complete as usage guidance gets.

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