Telegram Bot MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.3
Disambiguation5/5
Each tool targets a distinct operation: publishing text, photos, albums; editing text vs captions; deleting; searching; and retrieving channel info. The overlap between edit_message and edit_message_caption is clearly resolved by their descriptions (text vs media). No two tools appear to do the same thing.
Naming Consistency5/5
All tool names follow the consistent telegram_verb_noun pattern (publish_photo, edit_message_caption, get_channel_info). The use of snake_case is uniform, and the verb accurately reflects the action, making the set predictable and easy to navigate.
Tool Count5/5
With 8 tools, the server is well-scoped for channel management: create (publish), read (get info, search), update (edit), and delete. The count is neither too thin nor too heavy, and each tool serves a clear purpose within the domain.
Completeness4/5
The server covers the core lifecycle for messages (publish, edit, delete, search) and channel info. However, it lacks support for other media types like video or documents, and search is limited to session-cached messages, which might be a notable gap for some use cases. Overall, the most essential operations are present.
Average 4.7/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only. The description adds context about permanent removal, required bot permissions, and the return format (dictionary/markdown). No contradiction with annotations.
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?
Description is front-loaded with a clear purpose sentence. The Args/Returns sections are structured and helpful, though the first two sentences slightly repeat the same idea. Overall efficient.
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?
Covers prerequisites (permissions), parameter details, and return values. Given it's a simple delete operation with an output schema, it is adequately complete. It does not address error scenarios, but that is not necessary at this level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no descriptions (0% coverage), but the description thoroughly explains each parameter: channel_id format (username or numeric ID), message_id as unique identifier, and response_format options with default. This fully compensates for schema gaps.
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?
Clearly states 'Delete a message from a Telegram channel' with a specific verb and resource. Distinguishes from sibling tools like publish and edit by focusing on deletion. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'Use this tool to permanently remove a message from a channel' and notes the required permission. However, it does not name alternative tools or explicitly state when not to use, so it lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal idempotence and non-destructiveness, so the description adds value by disclosing the media-only constraint, inability to change the photo, and the requirement that the bot be the original sender with edit permissions. These are important behavioral nuances beyond what annotations convey. No contradiction with annotations.
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 well-structured with an opening purpose, a short 'use this' paragraph, and clear Args/Returns sections. It is slightly longer than strictly necessary but every sentence provides useful information, so the verbosity is earned. The front-loading of purpose and constraints is effective.
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?
Given 5 parameters, no schema descriptions, and the presence of an output schema, the description covers all necessary aspects: prerequisites, limitations, parameter semantics, and return format. It even explains the response_format behavior. The tool is complex enough that this level of detail is warranted, and the description completes the picture beyond the annotated fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description fully compensates by detailing every parameter: channel_id is given with examples and a constraint, message_id source is explained, new_caption includes max length and formatting support, parse_mode lists options with a default, and response_format is clarified. This adds substantial meaning beyond the bare schema types.
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 opens with a specific verb+resource: 'Edit the caption of an existing photo message in a Telegram channel.' It clearly differentiates from siblings like telegram_publish_photo (publishing) and telegram_edit_message (likely editing message text) by focusing on captions of media messages. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool ('modify the caption text of a previously published photo message'), explicitly limits usage to media-containing messages, and notes that the bot must be the original sender with edit permissions. It does not explicitly name an alternative tool for non-media messages, but the 'only works for media' phrasing implies when not to use it. This provides solid context without being overly verbose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, which are not contradicted. The description adds meaningful context: album behavior ('Users can swipe through the photos'), per-photo captions, and the permission prerequisite. It lacks details like idempotency or rate limits, but given annotation coverage the added context is adequate.
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 longer than typical but well-organized with Args, Returns, and an Example. Every sentence contributes value, and the structure makes information easy to scan. It could be slightly trimmed without losing meaning, but it's justified for a complex multi-parameter tool.
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?
Given the absence of schema descriptions, the description is remarkably complete. It covers all parameters, return values, defaults, permission requirements, and provides a realistic example. No important aspect appears missing for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden. It compensates excellently: explains each parameter, including the photos array structure with required 'photo' and optional 'caption'/'parse_mode', their types, examples, defaults for disable_notification and response_format, and channel_id formats. Example usage clarifies photo sources (URL, path, file_id).
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's function: 'Publish multiple photos as an album (media group) to a Telegram channel.' It is distinct from siblings like telegram_publish_photo (single photo) and provides essential scope (2-10 photos).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this tool to post 2-10 photos in a single message as an album/gallery,' establishing when it applies. It also notes the bot permission requirement. It doesn't explicitly name alternatives (e.g., 'for single photo use telegram_publish_photo'), but the sibling list and clarifying phrase 'multiple photos' make the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: the bot membership/admin requirement and the response format behavior (json vs markdown). It does not cover error handling or rate limits, but for a read-only tool this is sufficient.
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?
The description is concise and well-structured with an 'Args' and 'Returns' section. It is front-loaded with the purpose, and every sentence adds value without fluff. The formatting is easy to parse for an agent.
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?
For a simple read-only tool with only two parameters, the description covers purpose, prerequisites, parameter semantics, and return format. It is complete enough for an agent to select and invoke the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining both parameters: channel_id accepts a username ('@mychannel') or numeric ID, and response_format accepts 'json' or 'markdown' with a default. This adds complete meaning beyond the bare schema definitions.
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 states exactly what the tool does: 'Get detailed information about a Telegram channel.' It uses a specific verb ('Get') and resource ('channel info'), and clearly distinguishes it from sibling publish/edit/delete/search tools by focusing on retrieval rather than mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Use this tool to retrieve metadata and statistics about a channel where the bot is a member or admin.' It implies the prerequisite (bot membership/admin) without explicitly naming alternatives, but the sibling tools are obviously for different operations, making the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover non-read-only and non-idempotent behavior. The description adds useful context: the bot must have admin permission, photo can be a path/URL/file_id, and return values include message_id and chat_id. It doesn't contradict annotations and enriches the behavioral model, though it omits details like error handling or rate limits.
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?
The description is appropriately sized and well-structured, starting with a one-sentence summary, followed by a short usage context, then an Args list, and a Returns section. Every sentence provides useful information without redundancy, earning its place.
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?
Given the tool's complexity (6 parameters, varied input types, response_format options) and the presence of annotations and an output schema, the description covers prerequisites, parameter nuances, and return structure. It is complete enough for an agent to select and invoke the tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining every parameter in the 'Args' section. It clarifies accepted formats for channel_id (username or numeric ID) and photo (path, URL, file_id), gives max caption length, lists parse_mode options, and explains response_format. This adds significant meaning beyond the bare schema.
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 opens with 'Publish a photo to a Telegram channel with an optional caption,' which is a specific verb+resource statement. It clearly distinguishes from sibling tools like telegram_publish_message (text) and telegram_publish_photo_album (multiple photos) by focusing on a single photo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use this tool: 'post photos to a Telegram channel where the bot is an admin' and notes the permission requirement. It does not explicitly name alternatives or provide 'when-not' guidance, but the context is clear enough to differentiate it from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write/non-idempotent operation, but the description adds valuable context: bot admin requirement, parse_mode formatting behavior, effects of disable_web_page_preview and disable_notification, and response format differences. No contradictions with annotations.
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?
The description is well-structured with an intro, usage note, Args section, and Returns section. Every sentence adds value, and there is no redundancy or fluff. It is appropriately sized for a 6-parameter tool.
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?
The tool is moderately complex and the schema provides no descriptions, yet the description covers purpose, prerequisites, every parameter, defaults, and return values. This makes the tool fully invocable without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains all 6 parameters, including types, options, defaults, and the meaning of channel_id formats. This fully compensates for the schema gaps.
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 first sentence clearly states the verb and resource: 'Publish a message to a Telegram channel.' It distinguishes from sibling tools like telegram_publish_photo by focusing on text messages and explicitly says 'post new messages.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use the tool ('Use this tool to post new messages to a Telegram channel where the bot is an admin') and gives a prerequisite (bot must have permission). It does not explicitly mention alternatives (e.g., for photos use telegram_publish_photo), but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the text-only limitation, original-sender permission requirement, and how response_format changes the return value. Annotations already note mutating but non-destructive and idempotent, and the description adds valuable context without contradiction.
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?
Structured sections with Args and Returns, front-loaded warning about text-only limitation. Each sentence adds necessary information without redundancy, making it appropriately sized and well-organized.
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?
Covers permissions, text-only scope, all parameters, and return values including the markdown/json difference. Sibling distinction further completes the picture, making the description self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully compensates by explaining each parameter: channel_id (username or ID, same channel), message_id (returned at publish), new_text (formatting based on parse_mode), parse_mode (options/default), and response_format (options/default). This goes beyond the schema.
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 opening sentence uses a specific verb and resource ('Edit an existing TEXT message in a Telegram channel') and immediately differentiates from the sibling tool by stating photo messages should use edit_message_caption instead. This makes the tool's scope unmistakable.
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?
Explicitly provides an alternative for photo messages (edit_message_caption) and states the bot must be the original sender with edit permissions. This gives clear when-to-use and when-not-to-use guidance, satisfying the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses extensive behavioral traits: session-only cache, cache clearing on restart, Bot API limitations, what is/isn't cached, and the ability to edit/delete with message_id. This goes far beyond the annotations, which only indicate read-only and idempotent.
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?
Although lengthy, the description is well-structured with bolded warnings, bullet points, and dedicated sections for Args, Returns, and Notes. Every sentence provides actionable information, and the critical limitations are front-loaded.
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?
The description covers all aspects: purpose, limitations, usage, parameters, return values, and practical notes. It is complete for a tool with complex caching constraints, and the output schema is described in sufficient detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema having 0% description coverage, the description thoroughly explains every parameter: channel_id, query (case-insensitive, None/empty returns all), limit, offset (pagination), and response_format (json/markdown). This adds essential meaning beyond the schema.
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 begins with 'Search for messages in a Telegram channel (from local cache ONLY)' which is a specific verb+resource+scope. It clearly distinguishes this tool from siblings by emphasizing the local cache limitation and stating it cannot retrieve historical messages.
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?
The description explicitly states when to use the tool (only for session-cached messages) and when not to (historical messages). It references sibling tools like publish_message and edit_message, and advises storing message_id for later operations, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![telegram-bot-mcp MCP server](https://glama.ai/mcp/servers/aggeentik/telegram-bot-mcp/badges/card.svg)](https://glama.ai/mcp/servers/aggeentik/telegram-bot-mcp)

Score Badge

Copy to your README.md:

[![telegram-bot-mcp MCP server](https://glama.ai/mcp/servers/aggeentik/telegram-bot-mcp/badges/score.svg)](https://glama.ai/mcp/servers/aggeentik/telegram-bot-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/aggeentik/telegram-bot-mcp'

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