Telegram MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct action: getting bot info, sending messages, editing, deleting, pinning, unpinning, sending photos, sending documents, getting chat details, and fetching updates. No two tools have overlapping purposes.
Naming Consistency5/5
All tools follow the pattern 'telegram_verb_noun' (e.g., telegram_send_message, telegram_get_chat). The naming is uniform and predictable, with clear verb-object relationships.
Tool Count5/5
With 10 tools, the set is well-scoped for a Telegram bot server. It covers essential operations without being bloated or too sparse, fitting the typical use cases of message management and information retrieval.
Completeness4/5
The tool set covers core CRUD operations for messages (send, edit, delete, pin/unpin), media sending, and chat/update retrieval. Minor gaps exist (e.g., no forward_message, sticker, or inline query support), but the essential workflow is complete.
Average 4.4/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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 idempotent and non-destructive nature. The description adds behavior for omitting message_id and states the return value ('Confirmation of unpinning'). No contradictions.
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 extremely concise: a single line plus an args section. All sentences are necessary and information-dense. Front-loaded with the primary action.
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?
For a simple tool with 2 parameters and no output schema, the description covers the purpose, parameter behavior, and return value. It could mention error cases but is adequate given the tool's simplicity.
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 parameter descriptions. The tool description provides a concise summary but does not add significant new semantic information 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 clearly states the action ('Unpin a message') and the resource ('in a chat'). It distinguishes from siblings like 'telegram_pin_chat_message' and 'telegram_delete_message' by its specific purpose.
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 explains the optional message_id and default behavior (unpins most recent if omitted). However, it does not explicitly state when not to use this tool or mention alternatives beyond the sibling list.
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 indicate read-only, idempotent, and non-destructive behavior. The description adds value by specifying return fields and error cases, enhancing transparency beyond annotations 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?
The description is concise, well-structured with clear sections (purpose, args, returns, error handling). Every sentence is informative and earns its place, with no fluff.
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 simplicity, strong annotations, and full schema coverage, the description is complete: it explains what is returned, how to supply input, and common errors. No gaps remain.
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% and the property description is already clear. The description's 'Args' section restates the parameter format, adding no new semantics. Baseline 3 is appropriate as schema does the heavy lifting.
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 purpose: to look up details about a chat, listing specific returned fields (title/name, type, description, invite link). This distinctively identifies the tool from its siblings (send, delete, pin, etc.) which perform different actions.
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 provides error handling conditions ('chat not found' scenarios) that implicitly guide when the tool can be used: only for chats the bot has interacted with. It doesn't explicitly compare with alternatives, but the context is clear given sibling tools.
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 set readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: calling consumes updates (non-idempotent behavior and long-polling semantics). This goes beyond the 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 a clear summary and labeled Args/Returns sections. Every sentence adds value, and there is no redundancy or fluff.
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 low complexity and complete schema coverage, the description covers all necessary aspects: purpose, usage, behavioral traits, and return format. No missing information.
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% with both parameters fully described (limit range and offset semantics). The description repeats this information and adds no new parameter-level details beyond the schema. Baseline 3 is appropriate.
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 it fetches recent incoming updates and identifies it as the primary way to discover a chat_id. It distinguishes itself from sibling tools like telegram_send_message by emphasizing its role in obtaining updates.
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 provides explicit when-to-use guidance: 'ask the user to send any message to the bot (or add it to a group), then call this tool to read the resulting update and find the chat.id'. It also notes that calling consumes updates. However, it lacks explicit exclusions or alternatives for scenarios where updates are not needed.
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?
Description goes beyond annotations by disclosing the 48-hour time constraint, the bot-ownership requirement, and error handling details. Annotations indicate idempotentHint=true but description explains the 'message is not modified' error, adding behavioral context.
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?
Description is well-structured with a clear overview, constraints, Args list, Returns, and Error Handling sections. Every sentence provides value, no fluff, and the most critical info is front-loaded.
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?
For a 4-parameter tool with no output schema, description covers purpose, constraints, and error handling. Not specifying exact return fields is a minor gap, but 'Confirmation that the message was updated' is adequate given simplicity.
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?
With 100% schema description coverage, the baseline is 3. The description partly repeats schema but adds minor value, such as character limits for text and formatting explanations for parse_mode. No significant new meaning beyond 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?
Description clearly states 'Edit the text of a previously sent bot message.' The verb 'edit' and resource 'text of a previously sent bot message' are specific. It distinguishes from siblings like telegram_send_message (send new) and telegram_delete_message (delete).
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?
Description specifies that only messages sent by this bot and younger than 48 hours can be edited, providing clear context. Error handling gives situations when it won't work. However, it does not explicitly name alternative tools for when not to use this tool.
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, destructiveHint=false, idempotentHint=true. The description adds context by confirming that pinning is a mutation that returns a confirmation, and includes error handling for permission issues. It does not contradict 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 extremely concise with no wasted words. It is front-loaded with the purpose, followed by a structured Args section and error handling. Every sentence adds value.
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?
Given that the tool has 3 parameters, no output schema, and comprehensive annotations, the description covers the essential behavioral aspects: permission preconditions, parameter defaults, and known error cases. It could mention return structure (e.g., 'returns a message object'), but the current level is sufficient 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by including error handling context ('can_pin_messages' permission) and specifying the default for disable_notification. This goes beyond the schema's parameter descriptions.
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 'Pin a message at the top of a chat.' It uses a specific verb ('Pin') and resource ('message at the top of a chat'), and distinguishes from sibling tools like telegram_unpin_chat_message.
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 provides guidance on when the tool can be used by specifying permission requirements: 'Requires the bot to have pin permissions in groups/channels (not required for private chats with the bot).' It also gives an error handling example that helps agents diagnose issues. However, it does not explicitly compare usage against alternatives.
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 indicate read-only, idempotent, non-destructive behavior. Description adds value by specifying the return shape (JSON with id, username, first_name, is_bot). No contradictions.
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?
Extremely concise: two sentences plus 'Args: none' and 'Returns:' line. Front-loaded with purpose, no wasted words.
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?
Completes all needs: purpose, usage, return structure, and no parameters. Annotations cover behavioral traits. No gaps remain.
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?
No parameters exist, so schema coverage is 100%. Description adds 'Args: none' which is clear. Baseline 4 for zero-parameter case.
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?
Description clearly states it returns basic info about the bot itself (username, ID, display name). This distinguishes it from sibling tools that deal with messages, chats, or updates.
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 states two use cases: verifying TELEGRAM_BOT_TOKEN validity and retrieving the bot's @username to start a chat. Does not mention when not to use, but context with siblings provides implicit 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 indicate this is not read-only or destructive, and the description adds context: Telegram fetches the file server-side, returns a confirmation with message_id, and describes common errors. These details go beyond annotations 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?
The description is concise, well-structured with clear sections (main purpose, Args, Returns, Error Handling), and front-loaded with the most important information. Every sentence adds meaningful content.
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 lack of an output schema, the description adequately explains the return value (confirmation with message_id) and common errors. All parameters are documented, and the tool's behavior regarding file size and accessibility is covered. It is complete for the tool's complexity.
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?
The schema has 100% coverage with descriptions, so baseline is 3. The description adds value by listing parameters in a structured 'Args' block and clarifying that the document URL must be public HTTPS and that caption has a 1024-character limit, which slightly exceeds the schema's own descriptions.
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 file (PDF, CSV, ZIP, etc.) to a Telegram chat via URL with an optional caption. It provides a specific verb-resource pair ('send a file') and distinguishes from siblings like telegram_send_photo and telegram_send_message.
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 implicitly indicates when to use (sending documents by URL) but does not explicitly exclude cases like sending local files or when to use alternatives. It includes helpful error handling guidance and a size limit, which aids in correct usage.
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 goes beyond annotations by detailing the return value (confirmation with message_id), error scenarios (chat not found, 403 Forbidden), prerequisites (user must start chat), and effects (message sent). This comprehensively discloses the behavioral traits of the tool.
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 clear sections (purpose, args, returns, errors). It is concise, front-loaded with the purpose, and every sentence adds value. No redundancy or fluff.
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 (5 params, 2 required, no output schema), the description covers usage, parameter details, return value, error handling, and prerequisites (user must start chat). It is fully adequate for an agent to invoke the tool correctly.
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?
The input schema has 100% coverage with detailed descriptions for all 5 parameters. The description largely repeats this information without adding significant extra meaning beyond clarifying usage via examples (e.g., 'from a scheduled routine'). Baseline 3 is appropriate.
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 'Send a text message to a Telegram chat, group, channel, or user via the bot.' It uses a specific verb+resource and distinguishes from sibling tools like telegram_send_photo and telegram_send_document by focusing on text messages and positioning itself as the primary tool for notifications.
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 provides context: 'primary tool for pushing notifications, alerts, or updates into Telegram — e.g. from a scheduled routine or automation.' It implicitly suggests when to use this tool but does not explicitly exclude alternatives or mention when to use siblings. Error handling offers guidance on recovery, strengthening usage advice.
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?
Discloses that deletion is permanent and irreversible, aligns with destructiveHint annotation. Adds details on permissions, time limits (48h), and error responses, going beyond the annotation's binary flag.
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?
Well-structured with clear sections (Args, Returns, Error Handling). Every sentence is informative; no fluff. Front-loaded with the core purpose.
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 main behavioral aspects (permanence, permissions, errors). Minor gap: the return format is only 'Confirmation of deletion' without specifics, but given the tool's simplicity and lack of output schema, this is acceptable.
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 3. The description adds value with examples for chat_id (numeric vs. @username) and suggests how to discover the chat ID, which is helpful beyond the schema's description.
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 'Permanently delete a message from a chat' with a specific verb (delete) and resource (message from a chat). It distinguishes from sibling tools like edit, pin, unpin, send 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?
Provides clear context on when to use: bots can always delete their own messages, deleting others requires admin rights. Includes error handling for common failures. Does not explicitly contrast with alternatives, but the usage conditions are well explained.
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 important behavioral details beyond annotations, including the server-side fetching of the URL, specific error messages (wrong file identifier, IMAGE_PROCESS_FAILED), file size limit (10 MB), and format hints. This adds significant context for the agent.
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 Args, Returns, and Error Handling sections. It is concise (no unnecessary information) and front-loaded with the main purpose. Every sentence earns its place.
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?
Given the tool's simplicity (3 parameters, no output schema) and good annotations, the description covers the main use case, constraints, and error scenarios. It lacks explicit mention of what happens if chat_id is invalid, but the schema already covers parameter formats.
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 3. The description adds value by clarifying that the photo URL is fetched server-side and by specifying error handling for the photo parameter, which is not in the schema. The parameter descriptions in the docstring largely mirror the schema but with added context.
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 an image to a Telegram chat by URL with an optional caption. It distinguishes from siblings like telegram_send_message (text) and telegram_send_document (file) by specifying 'send an image' and 'by URL'.
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 implies usage for sending images from public HTTPS URLs, but does not explicitly contrast with alternatives like telegram_send_document for files. The purpose is clear, but no 'when not to use' or direct sibling comparison is provided.
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-mcp-server MCP server](https://glama.ai/mcp/servers/germankingerman-byte/telegram-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/germankingerman-byte/telegram-mcp-server)

Score Badge

Copy to your README.md:

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

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/germankingerman-byte/telegram-mcp-server'

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