Skip to main content
Glama
egor-fedorov

Telegram Context MCP

by egor-fedorov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_messages

Read-only

Fetch Telegram posts by URL or chat/message ID, including authors, replies, attachments, reactions, polls, and previews while preserving input order and reporting missing messages.

Instructions

Fetch posts by Telegram URL, 'chat_id:message_id', or {chat_id, message_id}.

    Includes authors, reply references, attachments, original links, available counters,
    aggregate reactions, polls and available web-page previews. Unknown metadata is omitted;
    previews come from the message payload without fetching external URLs. has_link is
    independent of content_type. No extra requests are made for metadata or voter/reactor
    identities. Polls retain content_type="other".
    Missing messages produce individual issues with zero-based input_index. Input order and
    duplicates are preserved. For truncated text call again with next_text_offset.
    Public channels outside the allowlist require allow_public_channel_reads;
    linked discussions need ordinary access.

Input Schema

NameRequiredDescriptionDefault
refsYes
text_limitNo
text_offsetNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/openWorldHint, and the description adds substantial behavior beyond them: metadata is pulled from the payload without extra requests, previews are not fetched externally, voter/reactor identities are not resolved, missing messages surface as per-item issues, and order/duplicates are preserved. This is exactly the kind of side-effect and access detail an agent needs.

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 call signature and accepted inputs, followed by return contents and then edge cases. Dense but nearly every sentence carries a distinct fact; the telegraphic 'has_link is independent of content_type' and 'Polls retain content_type="other"' lines are cryptic out of context.

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 steps in to enumerate return contents (authors, reply refs, attachments, links, counters, reactions, polls, previews) and error shape (per-item issues with zero-based input_index). Combined with truncation and permission notes, an agent can call and interpret this 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 0%, so the description must carry the load; it does well by explaining the non-obvious string forms of 'refs' that the schema leaves untyped. However, text_limit is never mentioned and the offset parameter is referred to as 'next_text_offset' rather than the actual name 'text_offset', creating a slight naming mismatch.

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 ('Fetch') and resource ('posts'), and immediately enumerates the three accepted reference forms (URL, 'chat_id:message_id', {chat_id, message_id}). This exact-reference retrieval is clearly separable from the sibling search_messages 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear situational guidance: 'For truncated text call again with next_text_offset', and access conditions for public channels outside the allowlist and linked discussions. It never names search_messages as the alternative for discovery-type queries, so there are no explicit exclusions.

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

Deploy Server

Other Tools