Local MCP

Telegram Delete Message

telegram_delete_message

Destructive

Deletes ONE message you sent in a Telegram private chat or basic group, for everyone, only after the receiver acknowledged it: the receiver must have replied to that exact message with the text ACK (a human in the Telegram app, or an agent with telegram_send_message reply_to_message_id). DESTRUCTIVE, with a preview: confirm=false (the default) checks the ACK and deletes NOTHING; show the preview to the user and call again with confirm=true and the same account only after they approve. The confirm checks everything again. Reading the chat, unread=0 or any text never count as an ACK. The ACK proves that another Telegram account replied, not that it is another person; an account linked in this LMCP is never accepted as the receiver, so each computer with agents needs its own Telegram account. In a basic group the ACK proves that the user you named as receiver replied, not that the message was meant for them: the receiver is whoever you name. Supergroups and channels are not supported. state deleted means the message no longer exists in this account (requested for everyone); unknown means it may have been deleted, so call again and the answer will be deleted or not_found.

Input Schema

Name	Required	Description
`account`	No	Which linked Telegram account to use: its label or id from telegram_list_accounts. Leave it out to use the default account.
`chat_id`	Yes	Chat id from telegram_list_chats: user:… (private) or chat:… (basic group).
`confirm`	No	Must be true to delete. Without it, returns a preview and deletes nothing.
`receiver`	Yes	The receiver's user:<id>:<hash> id from telegram_list_chats. Only this user's ACK counts.
`remember`	No	With confirm: true, also stop asking for this kind of action from now on. Only when the person said so ("don't ask again"). The person can revoke it in LMCP or with set_always_allowed.
`message_id`	Yes	Id of your own message to delete (from telegram_read_messages).
`ack_message_id`	Yes	Id of the receiver's reply ACK to that message (from telegram_read_messages).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026

addedInput schema / properties / remember

Added value: +{
+  "description": "With confirm: true, also stop asking for this kind of action from now on. Only when the person said so (\"don't ask again\"). The person can revoke it in LMCP or with set_always_allowed.",
+  "type": "boolean"
+}

AddedOct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Far beyond the annotations: it explains the preview-only default, that confirm re-validates everything, the security semantics of the ACK ('proves another account replied, not another person'), the account-linking constraint, and the meaning of the returned states deleted/unknown. This is unusually rich disclosure for a destructive operation.

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 the ACK rule are front-loaded, and every sentence carries semantic weight (ACK definition, confirm flow, non-ACK cases). It is dense and long, but the length is justified by the destructive/security-sensitive nature; minor room to tighten the group-ACK sentence.

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?

An output schema exists, yet the description still explains the ambiguous 'unknown' state and instructs a retry, closing the only real gap. Given seven parameters, a destructive operation, and linked-account constraints, an agent has everything needed to call it 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 100%, so baseline is 3, but the description genuinely adds meaning: the ACK requirement clarifies why ack_message_id and receiver must be supplied, and it notes 'the receiver is whoever you name' in a basic group — nuance not captured by the schema alone.

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?

Specific verb and resource (delete ONE message you sent), explicit scope (private chat or basic group, for everyone), and a hard precondition (receiver ACK). It is clearly distinguishable from telegram_send_message and telegram_read_messages, which it names.

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 (ACK present), when-not (supergroups and channels unsupported; reading the chat or any text never counts as an ACK), and a named alternative (telegram_send_message with reply_to_message_id to produce the ACK). The confirm=false/confirm=true flow is spelled out step by step.

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

All Local MCP 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.