whisper-telegram-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: check_backends verifies setup, list_models shows model options, speak_text converts text to speech, transcribe_audio processes local audio files, and transcribe_telegram_voice handles Telegram-specific downloads. The descriptions reinforce these distinct roles, making misselection unlikely.
Naming Consistency4/5
Tools follow a consistent snake_case pattern throughout (e.g., check_backends, list_models, speak_text). However, there is a minor deviation in verb style: 'check' and 'list' are informational, while 'speak' and 'transcribe' are action-oriented, but this is reasonable given their distinct functions. The naming remains highly readable and predictable.
Tool Count5/5
With 5 tools, the set is well-scoped for a server focused on Whisper transcription and Telegram integration. Each tool earns its place by covering essential aspects: setup verification, model configuration, text-to-speech, audio transcription, and Telegram-specific handling. This count avoids bloat while providing complete functionality.
Completeness5/5
The tool surface offers complete coverage for the domain of audio transcription and synthesis with Telegram integration. It includes setup checks (check_backends), configuration (list_models), core operations (speak_text, transcribe_audio), and platform-specific handling (transcribe_telegram_voice). There are no obvious gaps; agents can perform end-to-end workflows without dead ends.
Average 4.3/5 across 5 of 5 tools scored. Lowest: 3.4/5.
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 is passing
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

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. It discloses that the tool lists models with performance characteristics, which implies read-only behavior, and mentions environment variable configuration context. However, it doesn't detail behavioral traits like whether it requires authentication, rate limits, error conditions, or the format of returned data. It adds some context but lacks comprehensive behavioral disclosure.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by two sentences providing useful context. There's minimal waste, though the second sentence about environment variable configuration could be more tightly integrated. Overall, it's efficient and well-structured.
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 low complexity (0 parameters, no annotations, but has an output schema), the description is reasonably complete. It explains what the tool does and provides context about model configuration. With an output schema present, it doesn't need to detail return values. However, it could better address usage scenarios or integration with sibling tools to be fully complete.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and context. This meets the baseline of 4 for zero-parameter tools, as it adds value without redundant information.
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: 'List available Whisper model sizes with performance characteristics.' It specifies the verb ('List') and resource ('Whisper model sizes'), but doesn't explicitly differentiate from sibling tools like 'check_backends' or 'transcribe_audio'. The purpose is specific but lacks sibling comparison.
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?
The description provides no guidance on when to use this tool versus alternatives. It mentions configuring the active model via an environment variable and the default, but doesn't explain when an agent should call list_models (e.g., before transcription to choose a model, for system setup, etc.) or how it relates to sibling tools like transcribe_audio. No explicit when/when-not or alternatives are provided.
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 provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: downloading from Telegram, transcribing, and deleting temp files. However, it does not cover aspects like error handling, rate limits, or authentication needs beyond the bot token fallback.
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 and front-loaded with the core purpose. Each sentence adds value: the first states the action, the second details the process, and the parameter/return sections are clear and necessary. No wasted words.
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 no annotations, 0% schema coverage, and an output schema present, the description is mostly complete. It covers the tool's purpose, process, parameters, and return reference. However, it lacks details on error cases or performance expectations, which could be useful for a tool involving external services.
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 0%, so the description must compensate. It adds meaningful semantics for all parameters: 'file_id' is explained as from a Telegram Message object, 'bot_token' has a fallback, 'language' specifies auto-detect behavior, and 'word_timestamps' clarifies its effect. This goes beyond the basic schema titles.
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 specific action: 'Download and transcribe a Telegram voice message.' It distinguishes from sibling tools like 'transcribe_audio' by specifying the Telegram source and mentions the cleanup step of deleting temp files, which adds unique context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Telegram voice messages but does not explicitly state when to use this tool versus alternatives like 'transcribe_audio'. It mentions the fallback to an environment variable for the bot token, which provides some context, but lacks clear guidance on prerequisites or comparisons with siblings.
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 burden. It describes the tool's purpose (checking backend availability) and suggests it's a verification step, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns structured data, or what 'available and configured' entails. The description adds basic context but lacks operational details.
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 highly concise and well-structured: two sentences that front-load the purpose and follow with clear usage guidance. Every sentence earns its place by providing essential information without redundancy or filler.
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, output schema exists), the description is reasonably complete. It explains what the tool does and when to use it, which is sufficient for a no-parameter verification tool. However, it could be more complete by hinting at what the output contains (e.g., list of backends, status) despite the output schema existing.
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 0 parameters with 100% schema description coverage. The description doesn't need to add parameter details, so it appropriately focuses on tool purpose and usage. A baseline of 4 is applied since no parameters exist, and the description doesn't attempt to explain nonexistent parameters.
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 with specific verbs ('check which transcription backends are available and configured') and distinguishes it from siblings like transcribe_audio or list_models by focusing on backend availability verification rather than transcription or model listing.
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?
Explicit guidance is provided: 'Call this first to verify your setup before transcribing.' This clearly indicates when to use this tool (as an initial setup check) versus when to use sibling tools like transcribe_audio (for actual transcription).
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 provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's core functionality, supported formats, and return structure. It mentions the backend ('Whisper') and outlines the return dictionary fields, which adds valuable context beyond basic operation. However, it doesn't cover potential limitations like file size constraints, processing time, or error conditions beyond the 'error' field.
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 efficiently structured with a clear purpose statement, format support list, parameter explanations, and return value documentation—all in minimal sentences. Each section adds value without redundancy, and information is front-loaded with the core functionality stated first.
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 tool with 3 parameters, 0% schema coverage, no annotations, but an output schema, the description provides complete context. It explains what the tool does, parameter meanings, return structure, and supported formats. The presence of an output schema means the description doesn't need to detail return value types, and it adequately covers the tool's scope and usage.
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?
Given 0% schema description coverage, the description fully compensates by providing detailed semantic explanations for all three parameters: 'file_path' (absolute path), 'language' (ISO-639-1 code with auto-detect default), and 'word_timestamps' (boolean for segment inclusion). Each parameter's purpose and format are clearly documented beyond what the bare 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 clearly states the specific action ('Transcribe an audio file to text') and technology used ('using Whisper'), distinguishing it from sibling tools like 'speak_text' (text-to-speech) and 'transcribe_telegram_voice' (specific format). The verb+resource combination is precise 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about supported audio formats (OGG, WAV, MP3, FLAC) and mentions 'most common audio formats,' which helps determine when this tool is appropriate. However, it doesn't explicitly contrast when to use this versus the sibling 'transcribe_telegram_voice' tool or provide exclusion criteria.
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?
With no annotations provided, the description carries the full burden and excels by detailing multiple behavioral aspects: it lists TTS backends with priority order, cost implications (OpenAI TTS pricing), platform dependencies (macOS fallback), configuration via environment variables, and return format specifics. This goes well beyond basic function description.
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 clear sections (purpose, use case, backends, configuration, args, returns) and efficiently conveys essential information. It could be slightly more concise by integrating some details (e.g., backend priorities) more tightly, but overall it's front-loaded and wastes no sentences.
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 tool with 3 parameters, no annotations, 0% schema coverage, but an output schema, the description is highly complete. It covers purpose, usage, behavioral details, parameter semantics, and return values, making the output schema redundant for understanding. No gaps remain given the complexity.
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?
Given 0% schema description coverage, the description fully compensates by explaining all three parameters: 'text' (text to synthesise), 'voice' (with specific voice names for each backend and default configuration), and 'output_path' (optional absolute path). It adds crucial context like default values and backend-specific options not 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 tool's purpose: 'Convert text to speech and return an OGG/Opus audio file path.' It specifies the exact action (convert text to speech), output format (OGG/Opus audio file), and distinguishes it from siblings like transcription tools by focusing on speech synthesis rather than recognition.
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 clear context for when to use this tool (for text-to-speech conversion) and mentions a practical use case ('Plays as a native voice note in Telegram when sent as an attachment'). However, it does not explicitly contrast with sibling tools like 'check_backends' or 'list_models', nor does it specify when not to use it (e.g., vs. transcription tools).
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:

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

Score Badge

Copy to your README.md:

[![whisper-telegram-mcp MCP server](https://glama.ai/mcp/servers/abid-mahdi/whisper-telegram-mcp/badges/score.svg)](https://glama.ai/mcp/servers/abid-mahdi/whisper-telegram-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/abid-mahdi/whisper-telegram-mcp'

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