secure-telegram-mcp

Overview Schema Source Related Servers Discussions Admin

Mark chat read

mark_read

Idempotent

Marks an authorized Telegram chat as read and emits read receipts, with optional message ID or forum topic ID to control what is marked.

Instructions

Mark an in-scope chat read, emitting read receipts. Provide maxMessageId to mark read up to a specific message, or omit it to mark the whole dialog read. For a forum supergroup, add topicId (with maxMessageId) to mark a single topic read. Out-of-scope chats are rejected.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "peer": "<peer>"
    },
    "name": "mark_read"
  }
}

Input Schema

Name	Required	Description
`peer`	Yes	Chat reference: { kind:'id', value:'<decimal id>' } \| { kind:'username', value:'@name' } \| { kind:'me' }.
`topicId`	No	Mark one forum topic read instead of the whole chat; requires maxMessageId (Telegram has no whole-topic form).
`maxMessageId`	No	Mark read up to and including this message id; omit to mark the entire dialog read.

Output Schema

Name	Required	Description	Default
`chat_id`	Yes	Chat that was marked read.
`max_read_message_id`	Yes	High-water-mark message id marked read (0 when the whole dialog was marked).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Adds real value beyond annotations by disclosing that read receipts are emitted, which explains why readOnlyHint is false despite the read framing, and warns that out-of-scope chats fail. It still doesn't cover rate limits or who exactly sees the receipt, so not a 5.

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

Conciseness5/5

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

Three short sentences, front-loaded with the action and side effect, then the parameter decision tree, then the failure constraint. Nothing is redundant.

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?

With an output schema present and full schema coverage, the description covers what an agent needs to invoke it correctly. The only gap is that 'in-scope' is never defined, leaving the agent unsure what determines scope before the call is rejected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents peer forms, topicId's maxMessageId dependency, and the inclusive bound. The description restates those relationships coherently but adds no syntax or format detail beyond the structured fields.

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 and resource ('Mark an in-scope chat read') plus the non-obvious side effect ('emitting read receipts'). It is unmistakable against siblings like get_messages, send_message, or edit_message, none of which mutate read state.

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 explicit branching guidance: supply maxMessageId to mark up to a message, omit it to mark the whole dialog, or add topicId with maxMessageId for a forum topic. It also states the exclusion condition ('Out-of-scope chats are rejected'), though no alternative sibling tool is named as a fallback.

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

This server cannot be deployed