Skip to main content
Glama
harnyk

Telegram Notifier MCP Server

by harnyk

Send Telegram Message in Markdown format

send_markdown_message_as_telegram_bot

Send formatted Telegram messages using Markdown, MarkdownV2, or HTML parsing for bold, italic, code, links, and more.

Instructions

Send a message using Telegram bot in Markdown format

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageTextYesMessage text with formatting. Examples: HTML: <b>bold</b>, <i>italic</i>, <u>underline</u>, <s>strike</s>, <code>code</code> Markdown: *bold*, _italic_, `code`, [link](url) MarkdownV2: *bold*, _italic_, __underline__, ~strike~, ||spoiler||, `code` Prefer MarkdownV2. Read the documentation on MarkdownV2 formatting below: MarkdownV2 style To use this mode, pass MarkdownV2 in the parse_mode field. Use the following syntax in your message: *bold \*text* _italic \*text_ __underline__ ~strikethrough~ ||spoiler|| *bold _italic bold ~italic bold strikethrough ||italic bold strikethrough spoiler||~ __underline italic bold___ bold* [inline URL](http://www.example.com/) [inline mention of a user](tg://user?id=123456789) `inline fixed-width code` ``` pre-formatted fixed-width code block ``` ```python pre-formatted fixed-width code block written in the Python programming language ``` >Block quotation started >Block quotation continued >The last line of the block quotation **>The expandable block quotation started right after the previous block quotation >It is separated from the previous block quotation by an empty bold entity >Expandable block quotation continued >Hidden by default part of the expandable block quotation started >Expandable block quotation continued >The last line of the expandable block quotation with the expandability mark|| Please note: Any character with code between 1 and 126 inclusively can be escaped anywhere with a preceding '\' character, in which case it is treated as an ordinary character and not a part of the markup. This implies that '\' character usually must be escaped with a preceding '\' character. Inside pre and code entities, all '`' and '\' characters must be escaped with a preceding '\' character. Inside the (...) part of the inline link and custom emoji definition, all ')' and '\' must be escaped with a preceding '\' character. In all other places characters '_', '*', '[', ']', '(', ')', '~', '`', '>', '#', '+', '-', '=', '|', '{', '}', '.', '!' must be escaped with the preceding character '\'. In case of ambiguity between italic and underline entities __ is always greadily treated from left to right as beginning or end of an underline entity, so instead of ___italic underline___ use ___italic underline_**__, adding an empty bold entity as a separator.
parseModeNoMessage formatting mode: Markdown (legacy), MarkdownV2 (comprehensive), or HTML (tag-based)MarkdownV2
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only says 'send a message' without mentioning authentication, rate limits, error handling, or what happens on failure. The minimal description does not adequately inform the agent of behavioral traits.

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 description is a single concise sentence that efficiently conveys the core function. It is front-loaded and wastes no words, though it could benefit from a bit more context without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the two parameters and no output schema or annotations, the description is incomplete. It does not explain return values, error messages, or prerequisites like bot token setup. A simple send message tool still needs basic behavioral context for safe usage.

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%, with detailed descriptions for both parameters, especially messageText with extensive formatting examples. The tool description adds no additional meaning beyond the schema, achieving the baseline of 3.

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?

The description clearly states the tool sends a message using a Telegram bot in Markdown format. It distinguishes from siblings like sending documents, photos, or videos by specifying 'message' and 'Markdown format'.

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 implies usage for sending formatted text messages, but lacks explicit guidance on when to use it vs. siblings or which parse mode to prefer. No alternatives or exclusions are mentioned.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/harnyk/mcp-telegram-notifier'

If you have feedback or need assistance with the MCP directory API, please join our Discord server