claude-telegram-interactive-mcp

by makarworld

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a distinct purpose: sending different media types, sending text, asking for interactive input, and fetching updates. No overlapping functionality causes confusion; the boundaries are clear.
Naming Consistency5/5
All tools use snake_case with a verb-first pattern (send_*, ask_*, fetch_*). Even the longer 'send_markdown_message_as_telegram_bot' follows the same convention, making the set predictable and easy to scan.
Tool Count5/5
With 6 tools, the server is well-scoped for Telegram bot interaction. Each tool covers a core operation without redundancy, and the count is neither sparse nor overwhelming.
Completeness4/5
The set covers sending text, documents, photos, videos, interactive confirmations, and fetching updates. It lacks some capabilities like editing messages or sending audio, but the core lifecycle of sending and receiving is fully covered.
Average 3.8/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, but it only states the basic sending action and default parse mode. It does not disclose that this is a side-effecting network call, what prerequisites exist (bot token/configuration), what happens on invalid formatting, or what chat is used when the optional chatId is omitted.
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 front-loaded sentence that states the action, target, format options, and default. Every word earns its place and there is no redundant fluff.
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 schema covers parameter details, but the description omits important operational context: what happens when chatId is omitted, expected response or error behavior, and any authentication/config assumptions. For a side-effecting tool with no output schema and no annotations, the description is too thin to fully guide an agent.
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?
All three parameters already have rich descriptions in the JSON schema, including the enum for parseMode and its default. The description adds no meaning beyond restating the HTML default, so the baseline 3 for full schema coverage 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 the action ('Send a message'), the resource ('Telegram bot'), and the specific formatting modes (HTML/Markdown) with a default. This cleanly distinguishes it from sibling media-sending tools like send_telegram_document, send_telegram_photo, and send_telegram_video.
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 tool's intended use is implied by the name and the format mention—formatted text messages as opposed to media or confirmations—but no explicit when-to-use or when-not-to-use guidance is provided, and no alternatives are named. Sibling names offer only implicit contrast.
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 reveals that sending occurs but does not mention authentication requirements, failure behavior, external network effects, response shape, or any side effects. The path/URL support is input handling rather than behavioral transparency.
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, readable, front-loaded sentence with no filler. It communicates the core purpose and a key input constraint efficiently.
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?
For a tool with five parameters, no annotations, and no output schema, the description is too sparse. It omits guidance on optional parameters like chatId, caption, filename, and parseMode, as well as defaults, expected behavior, and prerequisites, leaving an agent without enough context to call it confidently.
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%, so the schema already documents all five parameters and their meanings. The description's mention of 'local Windows paths and HTTP URLs' repeats what the schema already states for the 'document' parameter, adding no new semantic value.
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 a specific verb ('Send'), a clear resource ('document/file'), and the channel ('via Telegram bot'), and it adds supported input forms (local Windows paths and HTTP URLs). This distinguishes it from sibling tools like send_telegram_photo, send_telegram_video, and send_markdown_message_as_telegram_bot.
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 use case is implied by the action: if you need to send a document or file via Telegram, use this tool. However, the description gives no explicit guidance on when to prefer this over alternatives, nor does it mention 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, so the description carries the full behavioral burden. It adds the useful detail about local Windows paths and HTTP URLs, but this largely duplicates the schema's photo parameter description and does not disclose authentication needs, default chat behavior, error cases, or other 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?
A single, front-loaded sentence states the action and the most important input constraint with no filler. Every word 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 send action with fully documented parameters, the description is largely sufficient to invoke the tool correctly. The main omissions are return-value expectations and failure behavior, but the schema covers all inputs and the purpose is unmistakable.
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%, so the baseline is 3; the schema already explains each parameter. The description does not add meaningful semantic value beyond what the input schema provides.
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 and resource ('Send a photo/image via Telegram bot') and adds the key transport constraint ('supports local Windows paths and HTTP URLs'). It is clearly distinguishable from sibling tools that send documents, videos, or Markdown messages.
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 intended use is implied: send a photo when you need to deliver an image through the Telegram bot. However, it does not explicitly state when not to use it or name alternatives like send_telegram_document or send_telegram_video.
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 must carry the behavioral burden. It does add useful context about accepted video sources (local Windows paths and HTTP URLs), but it does not disclose side effects, authentication requirements, default chatId behavior, or failure modes. This is a moderate disclosure for a send-type 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?
A single sentence that is front-loaded with the core action and resource, with the input constraint appended cleanly. There is no redundant wording, fluff, or repetition of schema 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?
The tool is relatively simple, all parameters are documented in the schema, and the description covers the main input constraint. The only gap is that there is no output schema and no mention of what the tool returns or how errors are reported, but this is not critical for a straightforward 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 description coverage is 100%, so the schema already explains all five parameters clearly. The description adds marginal value with 'local Windows paths' and 'HTTP URLs', but most of this is already present in the video parameter description. This matches the baseline for fully documented schemas.
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 names a specific verb ('Send'), a precise resource ('video via Telegram bot'), and adds the supported input forms ('local Windows paths and HTTP URLs'). This clearly distinguishes it from sibling tools like send_telegram_document and send_telegram_photo.
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 this tool is for sending video content rather than documents, photos, or plain messages, but it does not explicitly state when to prefer it over alternatives or mention any exclusions. Usage context is inferable from the resource type but not directly articulated.
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?
With no annotations, the description carries the disclosure burden and does disclose the key side effect: all media is automatically downloaded to local disk and paths are returned. It does not repeat the markAsRead offset behavior, but that is already fully documented in the schema, so no contradiction or major omission exists.
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 sentences with no filler. The primary polling action is front-loaded, followed by the important automatic media-download behavior and return-value statement. Every word 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?
The tool has four optional, well-documented parameters and no output schema. The description explains what is fetched, the side effect of downloading media, and what is returned (paths). It could be slightly more explicit about non-media update results, but overall it is complete enough for a low-to-moderate complexity 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 covers 100% of the four parameters with clear descriptions, types, and defaults. The description adds no parameter-level guidance beyond what the schema already provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation ('poll and retrieve') with a clear resource scope (recent messages, photos, error screenshots, files, and mediagroups), and it explicitly names the outcome (media downloaded and paths returned). This makes it easily distinguishable from the send_* and ask_* 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 clearly frames the tool as the inbound/polling counterpart to the outbound sibling tools (send_telegram_document, send_telegram_photo, ask_telegram_confirmation, etc.). It does not explicitly state 'use this instead of sending,' but the context is unmistakable and no exclusion scenarios are needed.
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?
There are no annotations, so the description carries the full behavioral burden. It discloses the significant side effect of automatically downloading received files to disk and returning local paths, while the 'wait' wording conveys the interactive blocking nature. It could be more explicit about timeout behavior, but the timeoutSeconds parameter partially covers that.
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 sentences with no filler, the primary action is front-loaded, and the file side-effect is stated immediately after. Every clause earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the input flow and file handling well, but because there is no output schema, it should clearly state what a normal response returns (e.g., selected button value or text) and what happens on timeout. These gaps are material for an agent deciding how to handle the result.
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 the baseline is 3; the description adds value by clarifying that 'options' correspond to interactive inline buttons and that responses can be text, file, photo, or media-group attachments. It also explains the file-download behavior, which is not apparent from parameter names or schema descriptions alone.
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 specific verbs ('Send a question', 'wait for user text or attached file/photo/mediagroup response') and clearly identifies the resource (Telegram). It distinguishes the tool from one-way send_* siblings and fetch_telegram_updates by emphasizing interactive response handling, so an agent can immediately see when this tool applies.
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 intended use case is clear: ask for confirmation or input and wait for a user response, which is exactly the interactive scenario this tool covers. It does not explicitly name alternatives or exclusions, but the sibling set makes the boundary obvious—send_* tools are one-way sends and fetch_telegram_updates is polling.
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:

[![claude-telegram-interactive-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/makarworld/claude-telegram-interactive-mcp/badges/card.svg)](https://glama.ai/mcp/servers/makarworld/claude-telegram-interactive-mcp)

Score Badge

Copy to your README.md:

[![claude-telegram-interactive-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/makarworld/claude-telegram-interactive-mcp/badges/score.svg)](https://glama.ai/mcp/servers/makarworld/claude-telegram-interactive-mcp)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![claude-telegram-interactive-mcp MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2Fmakarworld%2Fclaude-telegram-interactive-mcp%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/makarworld/claude-telegram-interactive-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/makarworld/claude-telegram-interactive-mcp'

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