telegram-mcp-cli

by thenavidm

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation5/5
Each tool has a clear, distinct purpose: send, send_file, and forward are differentiated by payload type and behavior; list_chats, get_chat, history, and search cover different levels of querying. No obvious overlaps or ambiguities.
Naming Consistency4/5
Most tools follow a verb_noun pattern (send_file, list_chats, mark_read, download_media), but 'whoami' and 'history' deviate as standalone nouns. Overall the naming is consistent and predictable, with minor exceptions.
Tool Count5/5
13 tools is within the typical 3-15 range and feels well-scoped for a messaging client. Each tool addresses a distinct part of the workflow without unnecessary bloat.
Completeness4/5
The core messaging lifecycle is covered: retrieving (list, get, history, search), sending (send, send_file, forward), mutating (edit, delete, mark_read), and identity (whoami). Some advanced features like pinning or archiving are absent, but the essential operations are complete.
Average 4.1/5 across 13 of 13 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on September 7, 2026
- 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states that it sends a file, providing no additional context about side effects, error conditions, or file handling. The annotations (readOnlyHint=false) already signal a write operation, so the description adds no extra behavioral information.
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 action and object. It is efficient and free of unnecessary details.
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 description covers the core intent and mentions the optional caption. It lacks explicit differentiation from the sibling 'send' tool, but for a simple file-sending operation, it provides sufficient context for an agent to understand the 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?
The description repeats the parameter explanations from the schema verbatim. Since the schema covers all parameters at 100%, the description adds no new meaning beyond what the schema already provides, resulting in a baseline score.
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 verb 'Send' and the resource 'a local file to a chat', distinguishing it from the sibling 'send' tool which likely sends text messages. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly indicate when to use this tool versus the sibling 'send' tool, nor does it mention any conditions or exclusions. The distinction is only implied by the name and the word 'file'.
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?
Annotations already cover idempotency, read-only, and destructive nature. The description adds the basic action but does not mention side effects like read receipts or notification updates, which would be extra context 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 a single, direct sentence with no unnecessary fluff. It is concise and clearly states the 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, single-action tool with no output schema, the description is sufficient. It fully captures the purpose and leaves little ambiguity about the intended effect.
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 parameter 'peer' has a clear description in the schema. The tool description does not add additional meaning beyond the schema, and schema coverage is high (100%), so 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 uses the specific verb 'Clear' with the resource 'unread count on a chat', clearly distinguishing it from sibling operations like send, forward, edit, and delete.
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 is provided on when to use this tool instead of alternatives (e.g., get_chat, history, send). The description only states what the tool does, not when it should be chosen.
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?
Annotations indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false, which provide some behavioral context. The description adds little beyond stating the action; it does not clarify side effects like whether messages are copied or moved, but this is typical for forward operations.
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 with no redundant information. It is well-structured and directly conveys the tool's 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?
For a simple side-effect operation, the description is sufficient given the clear schema and annotations. It does not explain return values, but no output schema exists and the operation is straightforward, so this omission is acceptable.
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 schema covers all parameters (from, to, message_ids) with clear descriptions (e.g., 'Chat to forward from.'). Since schema coverage is 100% and the description adds nothing beyond the schema, 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 clearly states the specific action (forward) and resource (messages from one chat to another). It distinguishes itself from sibling tools like send, edit, and delete by describing a unique operation.
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 (when you need to copy existing messages to another chat), but it does not explicitly mention alternatives or conditions for choosing this tool over others. The guidance is minimal and relies on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful details about the output structure (compact rows, fields parameter), aligning with 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, uses two short sentences, and front-loads the core purpose (recent conversations) followed by output details and a tip about the 'fields' parameter. No fluff or redundancy.
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 simple list operation and lack of an output schema, the description provides sufficient context (sort order, returned fields, field filtering) for an agent to understand the tool's functionality and expected results.
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 schema provides complete descriptions for all four parameters (kind, limit, fields, unread_only), so the description adds no additional parameter semantics. Per the rule, a baseline score of 3 applies when schema coverage is 100%.
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 lists recent conversations with a compact row per chat, including fields like id, name, kind, unread count, and preview. This distinguishes it from siblings like get_chat (single chat) and search (query-based).
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 retrieving recent chats but does not explicitly compare with alternatives like search or get_chat, nor state when not to use this tool. The 'newest first' ordering provides some context, but explicit guidance is absent.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds that the result is a 'chat you can act on', which hints at the return type. However, it doesn't disclose edge cases (e.g., unresolved identifiers) or any limitations beyond annotations. Since the description carries minimal extra behavioral info, a 3 is appropriate.
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, no filler, and the core purpose is front-loaded. Every word earns its place, and it's easily scannable for an agent.
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 single-parameter, read-only, idempotent resolver with no output schema, the description covers the use case and hints at the return value ('chat you can act on'). It doesn't mention error handling or fallback behavior, but given the simplicity and annotation coverage, it's sufficiently complete.
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 schema provides 100% coverage for the single parameter 'peer' with its own description listing accepted formats including 'me'. The tool description merely repeats the same formats without adding new meaning. With full schema coverage, the baseline is 3, and the description adds no extra value here.
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 verb 'resolve' and the resource (username/phone/id into a chat), and explicitly positions it as a step before sending. It distinguishes itself from siblings like get_chat or search by focusing on converting a handle into an actionable chat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear when-to-use: 'Use it before sending to someone you only know by handle.' It doesn't name alternatives explicitly, but the context implies that if you already have a chat reference, you wouldn't need this. This is adequate guidance for an agent.
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 readOnlyHint=false and destructiveHint=false, but the description adds important behavioral context: the message is visible immediately and posts as the user. This goes beyond the annotations by clarifying the side effects (permanent, attributed, immediate) and implies a need for caution. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-constructed sentence that front-loads the core purpose and appends a necessary caution. Every word earns its place; there is no fluff or redundancy.
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—four parameters, two required, no output schema—the description covers the essential behavior: it sends a message that is immediately visible and attributed. It does not mention return values, but those are not required for correct invocation. It could be improved by naming siblings for differentiation, but that falls under usage guidelines.
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% description coverage for all four parameters, so the schema already fully documents them. The description adds nothing about parameter meaning beyond what the schema provides, so it earns the baseline of 3.
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 to a chat.' It specifies the resource (a chat message) and the verb (send), and adds the key distinction that it posts as the caller, separating it from forwarding or file-sending siblings. The immediate visibility note further sharpens what this tool does.
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 gives a clear context—send when you need to deliver a message that is immediately visible and attributed to the user—but it does not explicitly mention alternatives like send_file or forward, nor does it state when not to use it. The warning 'only send what was actually asked for' is a usage guideline but not a routing guide to other tools.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds the scoping behavior (peer vs no peer), which is consistent with annotations. It does not disclose additional behavioral traits beyond that, but with annotations covering safety, a 3 is appropriate.
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 concise sentence that front-loads the action and resource ('Search message text') and includes the scope qualifier. 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?
The tool is simple, all parameters are documented in the schema, and annotations cover safety. The description provides the necessary purpose and scope, making it complete for an agent to invoke 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?
Schema coverage is 100%, so all four parameters are documented in the schema. The description adds minimal value, only reinforcing the peer omission behavior already stated in the schema ('Omit to search everywhere'). It does not compensate with extra semantic 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 clearly states 'Search message text' with a specific verb and resource, and distinguishes scope: 'inside one chat or across the whole account when no peer is given.' This differentiates it from sibling tools like history or list_chats.
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 two usage modes: with a peer (limit to a chat) or without (search across the account). It gives clear context for when to use the tool, though it does not explicitly name alternatives or exclusions.
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?
The description adds the nuance 'where the chat has them', indicating that optional fields may be absent, which is useful behavioral context. The readOnly and idempotent annotations already cover side effects, and the description does not contradict them.
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 sentence that is direct and to the point, with no unnecessary content. It conveys the essential purpose and returned data efficiently.
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 description provides enough detail about the return fields for a simple tool, and the annotations cover safety attributes. It does not mention error handling or the format of the response, but given the tool's simplicity and lack of an output schema, this is acceptable.
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 defines the 'peer' parameter with a clear description ('@username, numeric id, or 'me''), so the description does not need to add more. The schema coverage is 100%, giving a baseline score of 3.
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 returns details of a single chat and enumerates the fields (name, kind, username, member count, description). It is distinct from sibling tools like list_chats, which handle multiple chats, and history, which deals with messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a single chat's details are needed, but it does not explicitly contrast with sibling tools or state when not to use it. The context is clear enough, but a more direct comparison would improve clarity.
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 non-readonly, non-destructive, and idempotent behavior. The description adds that Telegram marks the message as edited, which is a useful side effect, and clarifies that only messages you sent can be edited.
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 succinct and direct, conveying the essential action in one sentence without unnecessary elaboration. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three required parameters and no output schema. The description provides enough context for an agent to understand the operation and its side effect, making it complete for typical usage scenarios.
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 schema covers 100% of parameters with brief descriptions. The tool description adds no further semantic detail beyond the schema, so a 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 clearly states the tool's purpose: to change the text of a message you sent. It uses a specific verb (change) and resource (message), and distinguishes from siblings like send (new message) and delete (removal).
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 context—use it when you want to modify a message you sent—but does not explicitly contrast with alternatives or state when not to use it. The context is clear enough for an agent to infer appropriate usage.
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?
Discloses non-obvious behavior: message bodies are truncated to previews unless `full` is set, and explains the rationale. This goes beyond the annotations, which only state read-only and idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. It front-loads the core purpose and then explains the truncated-body behavior efficiently.
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 schema fully describes parameters and there is no output schema to explain, the description sufficiently covers all necessary context for invoking 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?
Schema descriptions cover all parameters, so the baseline is 3. The description adds no extra meaning for individual parameters beyond what the schema already provides, though it indirectly ties `full` to truncation.
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?
States a specific action (reading messages), a specific scope (one chat), and a key ordering detail (newest first). It clearly distinguishes from siblings like search or get_chat.
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?
Implies usage for retrieving a chat's message history, and the truncation note hints at when to set `full`. However, it doesn't explicitly compare with sibling tools like get_chat or search.
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 the annotations by explicitly stating that deletion cannot be undone, that revoke affects all chat members, and that a confirm flag is required. This adds crucial behavioral details not present in the annotation flags (destructiveHint, idempotentHint).
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, two sentences, with no redundant words. It front-loads the primary action and then explains key side effects and requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive operation, the description provides sufficient context: what it does, irreversible nature, the revoke effect, and the confirm requirement. No output schema is needed given the 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 covers all parameters with clear descriptions (peer, message_ids, revoke, confirm). The description does not add additional parameter semantics beyond what is already provided, keeping the baseline at 3.
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 ('Delete one or more messages') and the resource (messages). It distinguishes from siblings like 'edit' and 'send' by focusing on removal, which is unique among the listed 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 provides context about the revoke option and the confirm requirement, implying when deletion is appropriate (e.g., permanent removal vs. local removal). However, it does not explicitly mention alternative tools or conditions for choosing delete over others, though none of the siblings directly compete.
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 adds behavioral details beyond the annotations: it explicitly states the file is written to disk, returns a local path, and explains the rationale for not returning inline. This complements the readOnlyHint (which concerns system state) and idempotentHint by clarifying the side effect of creating a local file.
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, front-loading the primary action and resource, and providing a concise rationale for the design choice. There is no redundant information, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description fully specifies what the tool does (saves media), what it returns (local path), and why it behaves that way. It is complete for an agent to decide when to invoke it and what to expect.
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 tool description does not significantly enhance parameter understanding; it only lists media types and implies that peer and message_id identify the message. The parameter descriptions in the schema already cover the meaning adequately.
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 (save media) and the resource (photo, video, document, or voice note attached to a message), and specifies the output (local path). It distinguishes the tool from siblings like send_file or forward by focusing on downloading media from a 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 clear context for when to use this tool (when media needs to be saved locally) and explains why it is used instead of returning inline (base64 is enormous and unreadable). However, it does not explicitly name alternative sibling tools, so it falls short of the highest 'explicit alternatives' level.
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; the description reinforces that it simply reports the session's account without contradicting 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?
Two concise sentences deliver the purpose and usage guidance without unnecessary detail or repetition.
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 no-parameter identity lookup, the description sufficiently conveys what the tool returns and when to use it, even without an output schema.
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?
There are no parameters, so the baseline applies; the description adds no parameter-specific detail but none is needed.
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 identifies the tool as returning the current Telegram account identity, and distinguishes it from message-oriented sibling tools by focusing on the session account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this tool first when account identity matters before reading or sending messages, providing a concrete usage condition.
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-cli MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/thenavidm/telegram-mcp-cli/badges/card.svg)](https://glama.ai/mcp/servers/thenavidm/telegram-mcp-cli)

Score Badge

Copy to your README.md:

[![telegram-mcp-cli MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/thenavidm/telegram-mcp-cli/badges/score.svg)](https://glama.ai/mcp/servers/thenavidm/telegram-mcp-cli)

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/thenavidm/telegram-mcp-cli'

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