mcp-telegram-claudecode

Server Quality Checklist

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

Latest release: v1.5.0
Disambiguation4/5
The tools are mostly distinct: send_message, send_photo, send_video, and send_document are clearly separated by content type, and start/stop_polling are unique. However, get_messages and check_new could cause slight confusion, as both relate to retrieving new messages, though their descriptions differentiate by urgency and scope.
Naming Consistency4/5
All tools follow a consistent telegram_ + verb_noun pattern (send_message, get_messages, send_photo, start_polling). The only slight deviation is telegram_check_new, where 'new' is an adjective rather than a noun, but it remains understandable and consistent with the overall style.
Tool Count5/5
With 8 tools, the server is well-scoped for its purpose: messaging, media sending, message retrieval, and polling control. Each tool serves a distinct function without redundancy.
Completeness4/5
The tool set covers the core Telegram operations needed for a Claude Code integration: sending text, photos, videos, documents, retrieving messages, and managing polling. Missing features like editing or deleting messages are not critical for this use case.
Average 3.9/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
- Last stable release on February 4, 2026
- 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses no behavioral traits beyond the action itself. It does not mention permissions, file validation, failure behavior, or what happens if the chat is not configured. The agent is left to infer side effects.
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?
One sentence, front-loaded, and every word earns its place. There is no redundancy or irrelevant information.
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, the description provides the core purpose and the schema fills in parameter details. However, it lacks any mention of return values or error conditions, which would be useful since there is no output schema. Still, it is mostly complete for a basic send action.
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 clear descriptions for both parameters. The tool description adds no extra meaning beyond the schema, such as file format restrictions, size limits, or path resolution details.
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 it sends a photo/image to the configured Telegram chat, distinguishing it from sibling tools such as telegram_send_message, telegram_send_video, and telegram_send_document. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like telegram_send_document or telegram_send_message. The description only states the action without any context for selection, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers minimal behavioral disclosure. It implies a read operation ('Get') but does not state side effects (e.g., whether messages are marked as read), rate limits, authentication requirements, or the return format. The description carries little beyond the basic action.
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 two sentences with no wasted words. It is front-loaded with the primary action and immediately provides the practical use case.
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 read tool with one optional parameter and no output schema, the description is mostly complete. It explains what the tool retrieves and when to use it. However, it does not describe the structure of the returned messages, which would be helpful but is not critical for this simple tool.
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 fully documents the only parameter 'limit' with its default value and purpose. The description adds no additional parameter semantics, so the baseline of 3 is appropriate given 100% schema coverage.
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 uses the specific verb 'Get' with a clear resource 'recent messages from Telegram'. It states exactly what the tool does and even frames it for a common use case (checking for new user messages), distinguishing it from the send-type sibling tools.
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 states when to use this tool: 'Use this to check for new messages from the user.' It gives a clear context but does not mention exclusions or alternative tools like telegram_check_new.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions that new messages are 'automatically injected into the terminal as user input', a key effect. However, it omits details about the continuous nature of polling, potential side effects, or how to stop it, leaving some behavioral transparency gaps.
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 two sentences, both informative. The first sentence states purpose and typical usage cadence; the second explains the behavioral consequence. No redundant or verbose language is present.
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 1-parameter tool with no output schema, the description covers the essential aspects: what it does, when it's needed, and what happens when enabled. It lacks explicit mention of the companion stop_polling tool, but sibling tool names partially fill that gap.
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 already fully documents the single parameter 'interval' with its description and default value (2000 ms). The tool description adds no additional meaning to this parameter, so the baseline score of 3 is appropriate.
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?
The description clearly states the tool's purpose: 'Manually start auto-polling for Telegram messages'. It also adds context that polling starts automatically on MCP load, clarifying that this is a manual override. However, it does not explicitly compare to sibling tools like telegram_check_new, so it lacks explicit sibling differentiation.
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 phrase 'polling starts automatically on MCP load, so this is usually not needed' provides direct guidance on when not to use the tool. It implies usage only when manual restart is required, but does not mention alternative tools for checking messages, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Stop auto-polling') but does not disclose potential side effects, idempotency, whether polling must already be active, or any impact on existing messages. This is a mutation tool, so more transparency would be expected.
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 a single, clean sentence that is front-loaded with the verb and object. Every word serves a purpose, and there is no redundant or extraneous information.
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 (0 parameters, no output schema), the description covers the core functionality. It does not mention behavioral nuances like return values or prerequisites, but the description is arguably sufficient for a stop command. Minor gaps prevent a perfect score.
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?
This tool has zero parameters, so the description does not need to elaborate on parameter meanings. Per the rubric, the baseline for 0 parameters is 4, and the description correctly avoids irrelevant parameter details.
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 uses a specific verb 'Stop' and a distinct resource 'auto-polling for Telegram messages.' It clearly differentiates from the sibling tools, particularly telegram_start_polling.
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 as the counterpart to telegram_start_polling, but it does not explicitly state when to use it vs. alternatives, nor does it mention any exclusions or conditions. It provides only implied usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some transparency by indicating the tool is a quick check and does not retrieve all messages, implying a lightweight, likely read-only operation. However, it does not specify the return type (e.g., boolean, count) or whether any side effects occur (e.g., marking messages as read), leaving important behavioral details undefined.
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 a single, concise sentence that front-loads the core purpose. Every word earns its place, with no redundancy or extraneous detail.
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?
The tool has no output schema and no annotations, so the description must compensate by explaining what the tool returns or how to interpret its result. It does not state whether the result is a boolean, message count, etc. Given the low complexity (0 params), the missing return-value information is a significant gap that limits the agent's ability to use the tool effectively.
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 tool has zero parameters, and the schema is empty with 100% coverage. Per the rubric, a baseline of 4 is appropriate since the description does not need to explain parameters that do not exist, and there is no ambiguity about inputs.
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 a specific verb ('check') and resource ('new messages from Telegram'), and distinguishes itself from the sibling tool telegram_get_messages by explicitly noting it does not retrieve all messages. This makes it immediately clear what the tool does and how it differs from similar tools.
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 phrase 'Quick check... without retrieving all of them' provides clear context for when to use this tool—when a lightweight presence check is needed rather than full message retrieval. However, it does not explicitly name alternatives or state when not to use it, though the contrast with 'retrieving all' strongly implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It transparently mentions the 50MB constraint and supported formats, but does not detail behavior like error handling, upload mechanics, or whether the destination chat is fixed. It adds some useful context but leaves gaps.
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 concise sentences deliver the purpose, supported formats, and size limit without redundancy. Every word earns its place, and the key action 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 simple two-parameter tool with full schema coverage and no output schema, the description covers the essential operational constraints (path, optional caption, formats, size limit). It does not explain response behavior or errors, but this is not critical 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?
The input schema already fully documents both parameters (video_path and caption) with clear descriptions, so the schema coverage is high at 100%. The description adds only the file format and size context, not additional parameter-level semantics, so the baseline of 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 uses a specific verb ('Send') and resource ('video file to the configured Telegram chat'), and clearly distinguishes itself from sibling tools like telegram_send_photo and telegram_send_document by specifying video file types and the 50MB size limit.
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?
It clearly indicates this tool is for sending video files, listing supported formats and a size cap, which gives clear usage context. It does not explicitly name alternatives or exclusions, but the intent is unambiguous for the stated file type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key constraint of 50MB max file size, but does not mention permissions, side effects, or return behavior. For a simple send operation, this 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 concise sentences that front-load the core purpose ('Send any file/document') and immediately follow with usage guidance. No wasted words, every sentence contributes.
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 straightforward send tool with two parameters, the description fully covers what the tool does, when to use it, and a critical size constraint. No output schema exists, but none is needed for this simple action.
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?
Input schema covers both parameters with clear descriptions, achieving 100% coverage. The description adds value by specifying the 50MB max file size, which applies to the document_path parameter and is not present in 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 ('Send any file/document') and the target resource ('configured Telegram chat'). It explicitly distinguishes from sibling photo/video tools by specifying 'for files that are not photos or videos', making its purpose 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 provides an explicit when-to-use condition: 'Use this for files that are not photos or videos', which implies exclusions for photo/video senders. However, it doesn't name the alternative sibling tools directly, so it lacks full explicit alternatie guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the message goes to a 'configured Telegram chat' and emphasizes it as the required reply channel, but it does not mention potential failures, rate limits, or delivery confirmation. The key behavior is clear but operational details are sparse.
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 two sentences: the first is a clear functional definition, and the second is a critical usage rule. There is no redundancy or filler; 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?
For a simple one-parameter tool with no output schema, the description is quite complete. It includes the essential context that this tool is the mandatory channel for all replies, which is critical for an agent. It falls short of a 5 only because it does not describe any error behavior or success indications.
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%: the only parameter 'message' is described as 'The message text to send'. The description adds no further parameter-level detail, so the baseline of 3 is appropriate since the schema already provides sufficient semantics.
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: 'Send a text message to the configured Telegram chat.' It specifies the verb 'send' and the resource 'text message to Telegram chat', effectively distinguishing it from sibling tools like telegram_send_photo and telegram_send_document.
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 gives explicit usage guidance: 'You MUST use this tool to reply to the user regardless of whether they sent their message via terminal or Telegram. Always respond through Telegram.' This clarifies when to use this tool over alternatives and provides a strong directive for agent behavior.
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:

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

Score Badge

Copy to your README.md:

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

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/EthanSky2986/mcp-telegram-claudecode'

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