Lemma Telepath

Send a Telegram message

telegram_send_message

Destructive

For channel comments use the discussion group chat_id and reply_to_message_id returned with the post. Never use this tool to publish channel posts; use telegram_create_post. Send confirmed text. Private Business replies send as the account; group messages and comments send as the bot; channel inbox replies send as the channel. Confirm the exact recipient, sender and wording. Resolve an unknown chat with telegram_find_chat; a chat found through Session may have no Bot API archive/connection. Bot API requires a known archive chat and private Business reply access. Telegram accepts a business reply only within 24 hours of that person's last message to you (incoming, not your own outgoing message). Missing history does not prove the window expired. BUSINESS_PEER_INVALID may also mean chat access or permissions. Choose transport=bot_api or session explicitly; default bot_api. Session can send to accessible private chats and groups as the account, without the Business 24-hour window. For missing Session: open https://t.me/lemma_telepath_bot, send /session, tap Connect Telegram, and sign in there; never request codes here. Session still respects Telegram restrictions and cannot automatically pay for messages. Use one stable request_id per exact confirmed action. Retrying that ID checks its receipt without sending again. Never use a new ID or switch transport after uncertain delivery. A definitive not_sent result permits a new confirmed attempt after fixing its cause. Only status=sent confirms Telegram acceptance, not human reading. archived=false means delivered but archive persistence failed: do not resend. Read error_code, next_step and retry_after_seconds; avoid polling or retry loops. Auto-reply may be paused immediately before dispatch; report auto_reply_paused even if the send fails. For channel inboxes reply_to_message_id must identify the customer's archived message; do not use message_thread_id. For group quotes/topics use IDs from that destination; never silently drop a requested quote or change topic.

Input Schema

Name	Required	Description	Default
`text`	Yes	Exactly the text to send.
`chat_id`	Yes	Recipient, from telegram_find_chat.
`confirmed`	No	True only after user authorization of exact recipient, sender and text. Required with request_id and for Session; older Bot API clients still require user confirmation through the conversation.
`transport`	No	Explicit sender route; never switch after an uncertain send.	bot_api
`request_id`	No	Provide a stable ID for this exact action; required for Session. Reuse to recover a receipt; never replace after uncertain delivery. Optional only for compatibility with older Bot API clients.
`message_thread_id`	No	Known forum topic in the destination group. For channel comments use reply_to_message_id from the post discussion metadata.
`reply_to_message_id`	No	Existing message in the same destination; required for channel inbox replies.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedNov 7, 2026

addedInput schema / properties / confirmed

Added value: +{
+  "const": true,
+  "description": "True only after user authorization of exact recipient, sender and text. Required with request_id and for Session; older Bot API clients still require user confirmation through the conversation.",
+  "type": "boolean"
+}

changedInput schema / properties / message_thread_id / description

Previous value: -"Known forum topic in the destination discussion group. For ordinary channel comments use reply_to_message_id from the post discussion metadata."New value: +"Known forum topic in the destination group. For channel comments use reply_to_message_id from the post discussion metadata."

addedInput schema / properties / message_thread_id / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / message_thread_id / minimum
```
Added value: +-9007199254740991
```

changedInput schema / properties / reply_to_message_id / description

Previous value: -"Quote this message_id in the reply."New value: +"Existing message in the same destination; required for channel inbox replies."

addedInput schema / properties / reply_to_message_id / exclusiveMinimum
```
Added value: +0
```
addedInput schema / properties / reply_to_message_id / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / reply_to_message_id / minimum
```
Added value: +-9007199254740991
```

addedInput schema / properties / request_id

Added value: +{
+  "description": "Provide a stable ID for this exact action; required for Session. Reuse to recover a receipt; never replace after uncertain delivery. Optional only for compatibility with older Bot API clients.",
+  "pattern": "^[a-zA-Z0-9_-]{8,100}$",
+  "type": "string"
+}

addedInput schema / properties / transport

Added value: +{
+  "default": "bot_api",
+  "description": "Explicit sender route; never switch after an uncertain send.",
+  "enum": [
+    "bot_api",
+    "session"
+  ],
+  "type": "string"
+}

Changed1 schema field changedOct 25, 2026

addedInput schema / properties / message_thread_id

Added value: +{
+  "description": "Known forum topic in the destination discussion group. For ordinary channel comments use reply_to_message_id from the post discussion metadata.",
+  "exclusiveMinimum": 0,
+  "type": "integer"
+}

First observedOct 3, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Far beyond the annotations it adds the real operational semantics: sender identity varies by destination (account for Business replies, bot for groups, channel for inbox), a stable request_id turns a retry into a receipt check rather than a resend, status=sent means Telegram acceptance only, and archived=false means delivered-but-unsaved so it must not be resent. It also documents error_code/next_step/retry_after_seconds and the BUSINESS_PEER_INVALID ambiguity, none of which the annotations convey.

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 content is nearly all substantive, but it arrives as an undifferentiated wall of sentences mixing transport selection, error handling, retry policy and threading rules, with no grouping or front-loaded purpose statement. A few points (transport stability, request_id reuse) are restated from the schema and could be consolidated for easier scanability.

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 destructive, non-idempotent outbound-send tool with no output schema, the description covers a remarkable amount: idempotency/receipt semantics, delivery-vs-read distinction, archived persistence failure, the Business 24-hour window and its false-negative traps, and channel-inbox threading. The one notable omission is what a successful response payload looks like beyond status and archived flags.

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 schema already defines all seven parameters; the description nevertheless adds routing meaning the schema cannot express – transport selects the sender identity and window constraints, reply_to_message_id must reference the customer's archived message for channel inboxes (and must not be replaced by message_thread_id), and message_thread_id is only for known forum topics/group quotes in that destination.

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 verb and resource are identifiable ('Send confirmed text' to a Telegram chat), and the negative routing to telegram_create_post makes clear this is for messages/replies rather than channel posts. However, the core purpose never appears as a clean, front-loaded statement – it is embedded among scoping rules about channel comments and transports, so the agent must assemble it from fragments.

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 when-to-use and when-not-to-use: 'Never use this tool to publish channel posts; use telegram_create_post', resolve unknown chats with telegram_find_chat, and choose transport=bot_api vs session deliberately with the tradeoff stated. It also names the preconditions (known archive chat, private Business reply access, 24-hour incoming window) that determine whether this tool can be used at all.

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

All Lemma Telepath tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?