Skip to main content
Glama
egor-fedorov

Telegram Context MCP

by egor-fedorov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_changes

Poll a selected Telegram chat for new messages and recent message revisions using checkpoints, returning completed passes and next checkpoints for safe change tracking.

Instructions

Poll one selected chat for new messages and available recent revisions.

    Supply chat_ref only to establish a baseline at the current head, without old
    history. Then supply checkpoint only. Rechecks the last 100 known messages;
    intermediate edits and all historical deletions cannot be recovered. complete
    means this pass finished; its next_checkpoint starts the next poll. Unavailable
    does not prove deletion. Retry old tokens safely, allowing duplicate revisions.
    Latest chain checkpoints survive 30 days; superseded versions may be evicted sooner.
    Inline text uses normal continuation offsets. output=jsonl/markdown returns a
    temporary file/resource with full records instead of inline changes. No binary
    attachment downloads. save=true retains the file in archive_directory.
    Respect retry delays and issues.

Input Schema

NameRequiredDescriptionDefault
saveNo
limitNo
outputNoinline
chat_refNo
checkpointNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A4/5.0
Behavior5/5

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

Annotations only give the coarse profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false); the description adds substantial context beyond that, including that only the last 100 messages are rechecked, that intermediate edits and deletions are unrecoverable, that 'unavailable' does not prove deletion, that retries may produce duplicate revisions, and that checkpoints expire after 30 days. It also discloses that non-inline output writes a temporary file/resource and that no binary attachments are downloaded.

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 first sentence front-loads purpose and the remainder is densely packed with operational facts, most of which earn their place. The fragmentary sentence-per-clause style is terse to the point of being choppy, but there is little outright filler.

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

Completeness4/5

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

For a polling tool with no output schema and five undocumented parameters, the description covers the important contract: the complete/next_checkpoint loop, token reuse safety, retention limits, and output modes. What is missing is the shape of the returned change records and the meaning of limit, so it is strong but not fully self-sufficient.

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 description coverage is 0%, so the description must carry parameter meaning, and it largely does: chat_ref as baseline establishment, checkpoint as the continuation token from next_checkpoint, output=jsonl/markdown as a file/resource mode, and save=true as retention in archive_directory. The limit parameter (1-100, default 30) is never explained, leaving one real gap.

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 and resource: 'Poll one selected chat for new messages and available recent revisions.' That is far more informative than the name alone and implies incremental/delta semantics. It doesn't name a sibling for contrast (e.g. get_watch_changes or get_messages), so differentiation is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

It gives a concrete operational sequence: 'Supply chat_ref only to establish a baseline... Then supply checkpoint only,' which is genuinely useful for correct invocation. However, it never states when to pick this tool over get_messages, get_history, or get_watch_changes, so tool selection against siblings remains implied.

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