Skip to main content
Glama
Sign In
secure-telegram-mcp

secure-telegram-mcp

by antonorlov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Send a text message

send_message

Send plain-text Telegram messages only to allow-listed chats; optionally target a forum topic or reply, with quota and confirmation safeguards.

Instructions

Send a plain-text message to a single in-scope chat. The chat must be inside this endpoint’s allow-list; out-of-scope targets are rejected. For a forum supergroup, set topicId (from list_topics) to post into that topic. Subject to the per-endpoint anti-ban quota and, when enabled, human confirmation. An optional idempotency key gives BEST-EFFORT retry de-dup (in-memory, per-process; reset on restart/policy change and NOT covering a send Telegram accepted but reported as failed) — do not assume a retry is safe.

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>",
      "text": "<text>"
    },
    "name": "send_message"
  }
}

Input Schema

NameRequiredDescriptionDefault
peerYesChat reference: { kind:'id', value:'<decimal id>' } | { kind:'username', value:'@name' } | { kind:'me' }.
textYesMessage body, 1..4096 characters.
topicIdNoPost into this forum topic of a forum supergroup (see list_topics).
idempotencyKeyNoOptional caller-supplied idempotency key (url-safe). Reusing it on a retry gives BEST-EFFORT, in-memory de-dup only (not guaranteed across restarts, policy changes, or a send Telegram accepted but reported as failed).
replyToMessageIdNoOptional id of a message to reply to (same chat).

Output Schema

NameRequiredDescriptionDefault
chat_idYesChat the message was sent to.
sent_atYesServer-acknowledged send instant.
message_idYesId of the newly created message.
idempotency_keyYesThe random_id used for idempotent dedup; echoed for traceability.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations it discloses real operational traits: allow-list enforcement, per-endpoint anti-ban quota, possible human confirmation, and that idempotency de-dup is in-memory, per-process, reset on restart/policy change, and does not cover sends Telegram accepted but reported as failed. The "do not assume a retry is safe" warning is exactly the behavioral context an agent needs before retrying.

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 core action and scope constraint are front-loaded, and each subsequent clause carries distinct operational information. The final parenthetical is dense and slightly hard to parse, but it is not padding.

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 5-parameter write tool with an output schema and full annotations, the description covers scope, quota, confirmation, and retry caveats well. It omits what happens on quota exhaustion or what a rejection looks like, which is minor since the output schema and annotations carry safety signaling.

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%, so all five parameters are already documented in structured data. The description adds the relationship of topicId to forum supergroups and clarifies retry semantics of idempotencyKey, but those points largely restate the schema text, so the baseline 3 applies.

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?

"Send a plain-text message to a single in-scope chat" gives a specific verb plus a scoped resource, and "plain-text" implicitly separates it from send_media and forward_message. It stops short of naming a sibling outright, so an agent must infer that media/forwards have their own tools.

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?

It states the prerequisite that the chat must be on the endpoint allow-list and that out-of-scope targets are rejected, plus the forum-topic case requiring topicId sourced from list_topics. There is clear use context but no explicit when-not to use it versus edit_message, forward_message, or save_draft.

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

Other Tools