Reply to a specific Telegram message by providing chat ID, message ID, and text. Confirm recipient and text with the user before calling, as this changes external state.
Reply to a specific Telegram message. This changes external state: call only after user confirmation of recipient and text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| chat_id | Yes | ||
| reply_to_message_id | Yes |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It explicitly states that the tool 'changes external state,' which complements the annotation readOnlyHint=false. It also adds a meaningful operational caution about user confirmation that is not present in the annotations. No contradiction with the annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, each earning its place. The core action is front-loaded, followed immediately by the critical usage caution. There is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter mutation tool with no output schema, the description provides purpose, external-state warning, and a clear invocation condition. It could add guidance on the relationship between chat_id and reply_to_message_id, but overall it is sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by mapping key concepts: 'recipient' hints at chat_id, 'text' maps to text, and 'specific Telegram message' maps to reply_to_message_id. However, it does not clarify that reply_to_message_id must belong to the same chat or explain how to obtain these IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Reply to a specific Telegram message.' This clearly distinguishes the tool from send_message, react_to_message, and other sibling tools, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit precondition: call only after user confirmation of recipient and text. It implies this is the correct tool for replying to an existing message rather than sending a new one, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.