agent-telegram-mcp

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation5/5
Each tool targets a distinct operation: sending different media types, managing messages, retrieving info, etc. No two tools have overlapping purposes.
Naming Consistency5/5
All tools follow a consistent 'telegram_verb_noun' pattern (e.g., telegram_send_message, telegram_get_chat_info), making them predictable and easy to navigate.
Tool Count4/5
With 17 tools, the set is slightly large but still well-scoped for a Telegram bot covering messaging, media, and info retrieval. It covers the essentials without being excessive.
Completeness4/5
The tool set covers core Telegram bot operations (send, receive, manage messages, media, files). Minor gaps exist, such as no edit_message or webhook management, but it is functional for most use cases.
Average 4/5 across 17 of 17 tools scored. Lowest: 3/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 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, so the agent knows it's a mutating but non-destructive operation. The description adds no extra behavioral traits (e.g., rate limits, idempotency) beyond the annotation baseline, which is acceptable.
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 short and front-loaded with the core action. The 'Args:' and 'Returns:' sections are clear but slightly verbose for the minimal information. No redundant sentences.
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?
Given that an output schema exists, the description adequately covers the return value. It explains the input parameters sufficiently for a simple location tool, but lacks broader context like authentication requirements or error handling specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must compensate. It lists parameter names (chat_id, latitude, longitude) but adds no meaning beyond the schema field titles and descriptions that already exist. For example, it doesn't explain coordinate formats or chat identifier syntax.
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 'Send a geographic location (map pin) to a Telegram chat' with a specific verb and resource. It distinguishes from sibling send tools (e.g., send_message, send_photo) by highlighting the location aspect, though it does not explicitly contrast with alternatives.
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 other send tools (e.g., send_message for text, send_photo for images). The description lacks exclusion criteria or context about prerequisites like bot permissions.
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, destructiveHint=false, idempotentHint=true. Description adds that it returns chat info but no further behavioral traits (e.g., rate limits, authentication). Consistent 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?
Very concise: three short sentences covering purpose, return fields, and parameter usage. No fluff, 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?
Provides enough context given low complexity: one param, no nested objects, and output schema exists. Mentions specific return fields. Could improve by noting that it returns a JSON string.
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?
Single parameter 'chat_id' with description in schema as 'Chat ID or @username'. Description repeats this without added semantics. Schema description coverage is 0% per context, but param is straightforward.
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?
Clearly states it retrieves chat info for groups, channels, or users. Specifies returned fields like name, type, description, member count. Slightly vague with 'and more' but sufficiently descriptive.
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 explicit guidance on when to use this tool over sibling tools like telegram_get_chat_member_count or telegram_get_bot_info. Does not mention prerequisites or 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?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds that the tool uses a file_id or .webp URL and returns a JSON message object or error, which gives some insight into behavior but no additional side-effect details (e.g., that it sends a message to a chat publicly).
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 concise (two sentences plus Args/Returns block) and front-loaded with the tool's purpose. It omits unnecessary detail but could be slightly more structured with bullet points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with annotated schema and output schema, the description adequately explains purpose and parameters. However, it lacks usage guidance and behavioral nuance like error handling or rate limits, which are not critical but would enhance completeness.
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 contains descriptions for chat_id and sticker. The tool description merely restates 'chat_id and sticker file_id or URL', adding no new semantics beyond the schema. With schema description coverage effectively handled by schema, baseline is 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 sticker') and the resource ('Telegram chat') with specific input type (file_id or .webp URL). It distinguishes from sibling tools like telegram_send_photo or telegram_send_video by focusing on stickers.
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 provide any guidance on when to use this tool versus alternatives (e.g., send_photo, send_document) or when not to use it. No context about prerequisites or expected use cases.
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 indicate non-readonly, non-destructive, non-idempotent. The description adds the return format. No contradictions, but no extra behavioral context like error cases or rate limits.
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?
Three sentences, front-loaded with purpose, no wasted words. Efficiently communicates the core action and return type.
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 simplicity of forwarding a message and the presence of an output schema, the description is nearly complete. Could mention that the bot must be a member of the source chat, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema parameter descriptions exist, but context reports 0% coverage. The description only lists parameter names without adding meaning about formats, restrictions, or defaults. Does not compensate for low 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 clearly states the action ('Forward a message from one chat to another'), which is a verb+resource combination. It distinguishes from siblings like telegram_send_message and telegram_delete_message.
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?
No explicit guidance on when to use this tool versus alternatives like telegram_send_message. The purpose is implied but lacks context for selection among many sibling 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 indicate non-read-only, non-destructive, non-idempotent behavior. The description adds context on accepted audio sources (local file, URL, file_id) and return format. No contradictions, but no extra behavioral details like rate limits or auth.
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?
Four concise sentences with immediate purpose, then accepted inputs, then params, then return. No redundant 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 nested input schema and available output schema, the description sufficiently covers input types, required fields, and return format. It lacks details on error handling or size limits, but is adequate for the tool's complexity.
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 lists sub-properties (chat_id, audio source, optional caption/performer/title) but the schema already provides detailed descriptions for each. With schema coverage 0% at the top level, the description adds minimal value beyond what is 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 verb 'Send', the resource 'audio file', and adds context 'shown as music player'. This distinguishes it from sibling tools like telegram_send_voice or telegram_send_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 description implies usage for sending audio files but does not explicitly contrast with other media tools or provide when-to-use guidance. It lists accepted input types but lacks exclusions.
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?
The description mentions the return format (JSON with Message object or error), which adds some behavioral context. Annotations already indicate non-read-only and non-destructive behavior. However, the description does not disclose additional traits such as permission requirements, rate limits, or side effects beyond what annotations provide.
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 very concise, using a single sentence for purpose followed by a bullet-point-like summary. It is front-loaded with the core action and efficiently covers input types and return value without 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 the tool's moderate complexity (sending a video with optional parameters), the description covers the essentials: purpose, accepted input sources, parameter list, and return format. It is slightly incomplete in that it omits any mention of prerequisites (e.g., bot token, chat permissions), but those are likely implied by the context of Telegram tools.
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 summarizes parameters as 'chat_id, video source, optional caption, dimensions', but this adds minimal value over the input schema, which already contains detailed descriptions for each parameter. Since the schema coverage is effectively complete, the description does not significantly enhance parameter understanding.
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 video') and the target resource ('to a Telegram chat'), and distinguishes the tool from siblings by specifying 'video' as the media type. It also lists the accepted input sources (file path, URL, file_id), which adds further clarity.
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 implicitly indicates use for sending videos, but does not provide explicit guidance on when to use this tool versus alternatives like telegram_send_audio or telegram_send_document. No when-not-to-use information is given, and there is no contrast with sibling tools, which would be helpful given the many sibling send tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide strong safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=true). Description adds return format (JSON with member_count), which is useful behavioral info. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus args/returns. Front-loaded with purpose. No unnecessary 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?
For a simple read operation with good annotations, the description is fairly complete. It explains what it does and returns. Could mention permissions (e.g., bot must be member), but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning tool description adds no value beyond the schema. It merely repeats 'chat_id or @username' already present in the input schema. Does not compensate for low 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?
Description clearly states the tool gets the total number of members in a chat/channel/group, using precise verb and resource. This distinguishes it from sibling tools like telegram_get_chat_info.
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?
No explicit guidance on when to use this tool vs alternatives. The name is self-explanatory but lacks context 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?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds value by explaining the return format (JSON with File object including file_path, file_size, download_url) and how to use the file_path to construct the download URL. No contradictions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized and well-structured: a brief intro sentence, the URL construction pattern, then an Args and Returns section. It is front-loaded with the main purpose. Slightly verbose but without extraneous content.
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 simplicity of the tool (one required parameter) and the annotations providing safety and idempotency hints, the description covers the key aspects: purpose, return format, and URL usage. It is complete enough for an agent to understand what the tool returns and how to use the output. No output schema is provided, but the description compensates by describing the return value.
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 'params' containing 'file_id' is described in the input schema with the description 'Telegram file_id to get download info for'. The tool description adds little beyond the schema: it simply restates 'file_id of the Telegram file.' With schema coverage at 0% according to context, but the schema itself provides adequate description, 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 'Get metadata and download path for a file stored on Telegram servers.' It uses a specific verb and resource, and the purpose is distinct from sibling tools like telegram_download_file, telegram_get_chat_info, etc.
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 retrieving file metadata and constructing download URLs, but it does not explicitly state when to use this tool over alternatives or provide exclusion criteria. No explicit when-to-use or when-not-to-use guidance is given.
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 indicate this is not read-only (sends) and not destructive. The description adds details about formatting support and reply functionality, but does not disclose potential limitations like rate limits or required permissions.
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 concise and front-loaded with the main action. It includes a brief list of parameters and return value, which is helpful without being verbose.
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 complexity (5 parameters, output exists), the description covers key features like formatting and replying. Annotations provide safety context, and the output schema is mentioned. Some details like message length limits are left to the schema, which is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema itself has high description coverage (all parameters described). The description adds contextual meaning by noting 'Supports plain text, Markdown, and HTML formatting' and 'Can reply to an existing message using reply_to_message_id,' which enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send a text message to a Telegram chat,' which is a specific verb+resource. It distinguishes from sibling tools (e.g., send_photo, send_audio) by focusing on text 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 description implies usage for text messages but does not explicitly compare to alternatives or provide when-to-use/when-not-to-use guidance. No exclusions or alternative tool mentions are given.
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 indicate readOnlyHint=false and destructiveHint=false, so the agent knows this is a write operation without destruction. The description adds that the tool accepts local path, URL, or file_id, and returns a JSON with the sent Message object or error. This provides useful behavioral context beyond annotations, but no mention of permissions or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 4 sentences and front-loaded with purpose. The 'Args' line is somewhat redundant given the schema, but overall it is concise and does not waste words. Could be slightly more streamlined by removing the args 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?
Given the tool's moderate complexity, the description covers purpose, input sources, and return format. The output schema is implied by the description of the return value. No gaps remain for an agent to understand what the tool does and what it produces.
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 detailed descriptions for chat_id, document, caption, and parse_mode. The tool's description only mentions 'params (SendDocumentInput): chat_id, document source, optional caption,' which adds minimal semantic value beyond the schema. With high schema coverage, a 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 clearly states the action ('Send any file (document) to a Telegram chat') and specifies the resource (Telegram chat). It distinguishes from sibling tools like send_photo/send_video by saying 'any file type that doesn't fit photo/video/audio.' This provides specific verb+resource and 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 description gives clear context for when to use the tool (PDFs, ZIPs, code files, etc.) and implicitly when not to use it (photo/video/audio types). It does not explicitly name sibling alternatives, but the context is sufficient for an AI agent to decide.
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?
Description indicates a write operation consistent with readOnlyHint=false, and mentions return value. It adds context on photo source types but does not elaborate on side effects or permissions; annotations already cover non-destructive nature.
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?
Concise: one-line purpose, followed by bullet points on accepted sources and output. No redundant sentences, front-loaded with key 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?
Covers input and output sufficiently for a send tool; missing details like bot membership requirements or failure modes, but acceptable given annotations (openWorldHint) and output schema indication.
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 descriptions for sub-properties (chat_id, photo, etc.) exist but top-level param 'params' lacks description. The tool description compensates by summarizing required fields and noting 'caption/parse_mode' formatting, adding value over 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 explicitly states 'Send a photo to a Telegram chat' and details accepted photo sources (local file, URL, file_id) and optional caption, clearly differentiating from sibling send_* tools.
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?
No explicit guidance on when to use this tool versus alternatives like telegram_send_document or telegram_send_video; the description implies usage by name but lacks context on exclusions or prerequisites.
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, non-idempotent. The description adds valuable context: accepted source types (local path, URL, file_id) and return format (JSON with Message object or error). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a concise args/returns list. No filler, front-loaded with purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input format, required/optional params, accepted sources, and return type. Lacks size limits or encoding details but adequate for a simple send operation with 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?
Despite low schema description coverage (0%), the description explicitly mentions the required params (chat_id, voice) and optional ones (caption, duration) and adds detail about voice sources. This compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send a voice message (.ogg/Opus) to a Telegram chat', specifying the format and distinguishing it from siblings like send_audio or send_document. The verb 'send' and resource 'voice message' are specific.
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?
Usage is implied by the name and description but no explicit guidance on when to use versus alternative send tools (e.g., send_audio). No exclusions or conditions 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?
Annotations already provide idempotentHint=true and non-destructive/non-read-only hints. The description adds context about requiring admin permissions and the return format (JSON with success/error), which goes beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and efficient: two sentences plus a clear Args/Returns section. It front-loads the purpose and avoids unnecessary details, making it easy to scan.
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 simple nature of pinning a message, the description, annotations, and schema together provide everything needed: purpose, prerequisites, parameters with descriptions, return format, and idempotency. No gaps.
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 includes detailed descriptions for each parameter (e.g., 'Message ID to pin', 'Pin silently without notification'). The tool description merely lists the parameter names and types without adding new semantic information, so it adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Pin a message in a chat' with a specific verb and resource, and distinguishes it from siblings like send/delete/forward. It also includes the prerequisite that the bot must be an admin with pin_messages permission.
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 the prerequisite (bot must be admin with pin_messages permission), giving a clear condition for use. However, it does not directly contrast with sibling tools or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and idempotentHint=true. The description adds context by explaining that updates are marked as read and paginated via offset, which is a behavioral trait beyond the annotations. No contradiction, and the description enhances understanding of the tool's idempotent behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: four sentences plus essential Args/Returns sections. It front-loads the purpose and immediately follows with key usage guidance. No filler or redundant 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 complexity of a polling tool, the description covers the core mechanism (offset pagination) and filtering. It mentions the return format (JSON). With annotations providing safety cues and the presence of an output schema, the description is largely complete, though it could mention the default limit or rate limits (but not critical).
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 description adds meaning beyond the input schema by explaining how to use the 'offset' parameter for pagination and acknowledgment. Although the schema has descriptions (e.g., for offset), the tool description provides a usage pattern (last_update_id + 1) that is not in the schema. The 'allowed_updates' filter is mentioned briefly but not elaborated.
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 'Retrieve recent updates', specifying the verb (retrieve) and resource (updates). It differentiates from sibling tools like telegram_send_message or telegram_delete_message, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on using the 'offset' parameter for pagination and acknowledgment: 'Call with offset = (last_update_id + 1) to acknowledge processed messages.' It also mentions the 'allowed_updates' filter. However, it does not explicitly state when not to use this tool or compare with alternatives like telegram_get_chat_info.
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 destructiveHint=true and readOnlyHint=false, so description agrees. Additionally, it describes the return format (JSON with deleted true or error), adding transparency beyond annotations. No 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?
Three sentences conveying purpose, input, and output with no redundancy. Front-loaded with the core action, making it easy to parse quickly.
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 delete operation, the description covers all necessary aspects: what it does, permissions needed, how to specify the target, and what to expect in response. No gaps identified.
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?
Despite 0% schema description coverage on the top-level param, the description explains that 'params' is a DeleteMessageInput containing chat_id and message_id, providing essential context that the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action 'delete a message from a chat', specifying the resource and including a permission requirement. This distinguishes it from sibling tools like send, forward, or upload.
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 mentions the prerequisite 'bot must have delete permission' which guides the agent on when invocation is valid. It lacks explicit comparisons to siblings, but the context is sufficiently clear for this simple operation.
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 value beyond annotations by specifying that it returns a JSON User object, which clarifies the output. Annotations already declare readOnlyHint, destructiveHint, idempotentHint, so no contradiction. The description could mention that no side effects occur, but the annotations cover 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?
The description is extremely concise with two short sentences, front-loaded with the main action and purpose. Every sentence adds value: first states what it does, second explains utility and return format.
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 zero parameters and an existing output schema, the description is complete. It names the fields returned (name, username, capabilities) and states the output format (JSON User object). No additional information is needed for this simple read-only tool.
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, so baseline is 4. The description does not need to add parameter information since there are none. It correctly mentions no arguments required.
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 'Get information about the configured bot (name, username, capabilities)' and highlights its utility for verifying token validity and bot identity, distinguishing it from sibling tools that perform actions like sending messages or deleting 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 tells when to use the tool ('verify the bot token is valid and check bot identity'), providing clear context. It does not explicitly exclude alternative uses, but for a simple informational tool, this is adequate.
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?
Beyond annotations (readOnlyHint, destructiveHint, idempotentHint), the description discloses key behaviors: writing to disk vs returning base64, and the return JSON structure with saved_path or base64 content plus filename and size. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: clear first sentence, then usage note, then args and returns. However, it is somewhat verbose (e.g., repeating 'Args: params...' which is redundant given the schema). Minor improvements could make it more concise.
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 2-parameter tool with annotations covering safety, the description provides enough behavioral and return information. It omits error handling or size limits, but given the presence of an output schema (context indicates yes) and the clarity of the description, it is largely 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 already provides detailed descriptions for both parameters, but the description adds context by linking the save_path parameter to the behavioral change (write vs base64) and explicitly stating the return format. This adds value beyond the schema, though the schema itself is already good.
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 action: 'Download a file from Telegram using its file_id.' It distinguishes from sibling tool telegram_get_file_info, which only provides the download URL, making the purpose precise and specific.
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 given: 'Use telegram_get_file_info first if you only need the download URL.' This tells agents when not to use this tool. Additionally, it describes the two modes depending on whether save_path is provided, covering when to use each 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:

[![Agent_telegeam_mcp MCP server](https://glama.ai/mcp/servers/tharindumendis/Agent_telegeam_mcp/badges/card.svg)](https://glama.ai/mcp/servers/tharindumendis/Agent_telegeam_mcp)

Score Badge

Copy to your README.md:

[![Agent_telegeam_mcp MCP server](https://glama.ai/mcp/servers/tharindumendis/Agent_telegeam_mcp/badges/score.svg)](https://glama.ai/mcp/servers/tharindumendis/Agent_telegeam_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/tharindumendis/Agent_telegeam_mcp'

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