Skip to main content
Glama

Search Telegram messages

telegram_search_messages
Read-onlyIdempotent

Find a topic, decision, link or mention in available Telegram messages. Archive search covers text, captions and saved transcripts, with all terms required and a prefix match on the last word. Connected Session uses Telegram cloud search; it does not search bot-archive transcripts for extra matches, although returned media may include a ready archive transcript. Neither path searches attachment bytes or filenames. Use a few distinctive words, not a full natural-language question. To search a person's or channel's conversation, resolve its name/@username/link with telegram_find_chat and pass chat_id; query searches message content, not contact names. Default 30 matches; archive maximum 200, Session maximum 50. Read effective_limit, source, coverage and partial; a full page is not an exhaustive search. Use since inclusively and before exclusively for a precise date interval. When has_more=true, pass next_cursor as cursor with the same query, chat_id and date filters to continue. Never construct or edit cursors. A repeated query without cursor starts again. Request another page only when needed for the user's question; stop when enough context is found, has_more=false, or a cursor fails/makes no progress. A filtered Session page can be empty with continuation; has_more means continuation is available, not guaranteed visible matches. Cursors expire after 15 minutes and may expire on restart or cache eviction: explain and restart explicitly, never claim complete history. Search reflects changing live data, not a fixed snapshot. For a conversation summary use telegram_get_messages. Use the user's known timezone; if unknown, silently use UTC without asking or adding a timezone caveat. Do not infer it from language. For calendar days pass since at inclusive midnight and before at the exclusive next midnight as ISO 8601 timestamps with the correct offsets; distinguish calendar days from rolling 24h windows. Do not silently broaden the requested period. Distinguish errors from successful zero matches. Read empty_reason, chat_found, history_notice and setup_required when present. chat_not_in_archive means this ID is absent from the saved archive, not from Telegram: resolve the chat again and follow telegram_find_chat recovery guidance. For no_matches, consider fewer distinctive words and verify the intended chat/time range; no_searchable_terms needs a word or number. Do not loop on unchanged searches or claim the conversation never happened. For limited archive history offer /import in https://t.me/lemma_telepath_bot or accessible older history through Session: send /session to that bot, tap Connect Telegram and sign in there. Never ask for login codes/passwords here. Do not prescribe reconnection from zero matches alone or reconnect a working Session. Errors need the reported cause and an appropriate next step; respect retry delays and never call a timeout missing history or lost permission. If unknown, say so and offer support at https://t.me/hellolemma. Use telegram_get_file with returned chat_id/message_id to read supported archive or Session attachments; photos use telegram_get_photo. 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.

Input Schema

NameRequiredDescriptionDefault
limitNoPage size. Default 30; archive maximum 200, Session maximum 50. Use next_cursor to continue when has_more is true.
queryYesDistinctive words in message content, not a contact lookup. Session supports up to 200 characters.
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; exclusive end of the search interval. Accepts an ISO 8601 timestamp, unix seconds, 'today', 'yesterday', or a relative window like '24h' / '7d'.
cursorNoOpaque next_cursor from the preceding search page. Keep query, chat_id, since and before unchanged; do not invent a cursor.
chat_idNoRestrict to this chat, resolved with telegram_find_chat.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / before
      Added value: +{
      +  "description": "Only messages strictly older than this time; exclusive end of the search interval. Accepts an ISO 8601 timestamp, unix seconds, 'today', 'yesterday', or a relative window like '24h' / '7d'.",
      +  "type": "string"
      +}
    • addedInput schema / properties / cursor
      Added value: +{
      +  "description": "Opaque next_cursor from the preceding search page. Keep query, chat_id, since and before unchanged; do not invent a cursor.",
      +  "maxLength": 4096,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • changedInput schema / properties / limit / description
      Previous value: -"How many matches to return. Default 30; archive maximum 200, Session maximum 50. This tool currently has no pagination."New value: +"Page size. Default 30; archive maximum 200, Session maximum 50. Use next_cursor to continue when has_more is true."
  2. Changed3 schema fields changed
    • changedInput schema / properties / chat_id / description
      Previous value: -"Restrict the search to this chat."New value: +"Restrict to this chat, resolved with telegram_find_chat."
    • changedInput schema / properties / limit / description
      Previous value: -"How many matches to return. Default 30."New value: +"How many matches to return. Default 30; archive maximum 200, Session maximum 50. This tool currently has no pagination."
    • changedInput schema / properties / query / description
      Previous value: -"Words to search for."New value: +"Distinctive words in message content, not a contact lookup. Session supports up to 200 characters."
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint/idempotentHint annotations, it discloses backend-dependent coverage differences (Archive vs Connected Session), that attachment bytes and filenames are not searched, cursor expiry after 15 minutes and on restart, that results reflect live changing data, and the response fields to inspect (effective_limit, source, coverage, partial, has_more, empty_reason). It also explains the forwarding semantics of from vs forward_origin, which is non-obvious behavior an agent would otherwise misread.

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

Conciseness3/5

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

The critical information (what it searches, archive vs Session, pagination) is front-loaded, but the description runs to roughly 450 words of dense prose mixing selection guidance, error policy, reconnect instructions and authorship caveats. Much of the recovery/support/escalation material would fit better in error payloads, and the lack of any structure makes it hard to scan.

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 compensates by naming the response fields that govern correct follow-up (coverage, partial, has_more, next_cursor, empty_reason, chat_found, history_notice, setup_required) and by explaining what each continuation signal means. For a six-parameter search tool with two backends and cursor pagination, nothing an agent needs to call it correctly appears to be missing.

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 semantics: all terms are required with prefix matching on the last word, since is inclusive and before exclusive, calendar days should be passed as inclusive-midnight/exclusive-next-midnight ISO intervals, and cursors must never be constructed or edited. That meaningfully extends what the schema itself conveys.

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?

The opening sentence names a specific verb and resource ('Find a topic, decision, link or mention in available Telegram messages') and immediately scopes what is searched: text, captions and saved transcripts. It also differentiates itself from the nearest sibling by naming telegram_get_messages for conversation summaries and telegram_find_chat for chat resolution.

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 routing rules are given: use telegram_get_messages for a conversation summary, resolve a chat with telegram_find_chat and pass chat_id, and use a few distinctive words rather than a natural-language question. It also states when to stop paging (enough context, has_more=false, cursor failure) and what to do for empty results or missing archive history.

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