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

secure-telegram-mcp

by antonorlov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Edit message

edit_message

Update the text of one of your own messages in a scoped chat by peer and message ID; other or out-of-scope messages are rejected.

Instructions

Edit the text of one of your own messages in a chat within this endpoint scope. Addressed by { peer, messageId }; the new text replaces the old. Out-of-scope peers and messages you did not send 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>",
      "messageId": "<messageId>",
      "text": "<text>"
    },
    "name": "edit_message"
  }
}

Input Schema

NameRequiredDescriptionDefault
peerYesChat reference: { kind:'id', value:'<decimal id>' } | { kind:'username', value:'@name' } | { kind:'me' }.
textYesMessage body, 1..4096 characters.
messageIdYesA positive per-chat message id.

Output Schema

NameRequiredDescriptionDefault
chatIdYesChat containing the edited message.
messageIdYesId of the edited message.
editedDateIsoYesServer-acknowledged edit instant.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the description's job is to add context beyond that, and it does add the key effect ('the new text replaces the old') and the rejection rules. It omits behaviorally important facts for an edit operation — whether an edit window applies, whether the peer is notified of the edit, and why idempotentHint is false — so it is adequate but not rich.

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?

Two tightly written sentences with zero filler; the core action and the silent-replacement semantics are front-loaded before the rejection constraints. Every clause carries information an agent needs.

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, return values need not be described, and all three required parameters are fully documented in-schema with annotations covering the safety profile, so the definition is nearly sufficient. The remaining gap is the absence of any note on edit-window or permission limits, which materially affects whether a call succeeds.

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 description coverage is 100% (peer variants, text length bounds, positive per-chat message id are all documented in-schema), so the baseline is 3. The description adds only the framing that {peer, messageId} address the message and that 'text' replaces existing content, which is modest added meaning rather than new syntax or format detail.

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?

States a specific verb and resource ('Edit the text of one of your own messages in a chat') plus the addressing key {peer, messageId}, which is far more precise than the title 'Edit message'. It implicitly separates itself from send_message/delete_message via 'the text of ... your own messages', but never names a sibling tool or an alternative route, so it falls short of a 5.

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?

The description supplies a real exclusion ('Out-of-scope peers and messages you did not send are rejected'), which tells the agent a precondition for successful use. However, it gives no positive when-to-use guidance and no comparison against sibling tools such as delete_message (for removal) or send_message (for new content), leaving the routing decision largely implied.

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