telegram-mcp-server

by KYONY

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation3/5
Multiple tools overlap in purpose (scrape_channel, scrape_channel_authenticated, api_scrape_channel) but descriptions differentiate by authentication method. Still, an agent may struggle to choose the right one at a glance.
Naming Consistency2/5
Naming is inconsistent: snake_case verbs (scrape_channel) mixed with prefixed styles (telegram_login, api_scrape_channel). No uniform verb_noun pattern across the suite.
Tool Count4/5
15 tools is on the higher end but acceptable for the range of authentication methods and scraping modes. Each tool adds some functionality, though redundancy inflates the count.
Completeness4/5
Covers channel/group scraping, date ranges, full exports, search, info retrieval, and authentication. Minor gaps like batch operations or message sending are outside the core scraping purpose.
Average 3.2/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for disclosing behavior. It only says 'Login' and 'fast, efficient scraping', providing no information about session persistence, authentication checks, rate limits, error handling, or the effect of repeated logins. The tool's behavior is entirely opaque.
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 a single, front-loaded sentence that clearly states the action. It is concise, though the phrase 'fast, efficient scraping' adds a subjective flourish without functional value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a login tool with no output schema and no annotations, the description fails to explain what happens on success/failure, what the returned data looks like, or why both parameters are optional. It is incomplete for an agent to confidently invoke and interpret the result.
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%, with both api_id and api_hash having descriptions. The tool description itself adds nothing beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool logs into Telegram using API credentials, which is a specific verb+resource action. It distinguishes somewhat from sibling tools like telegram_login by emphasizing 'API credentials', but doesn't fully disambiguate between the two login-related tools.
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 versus telegram_login or other authentication tools. The phrase 'for scraping' implies a use case, but there is no explicit when-to-use or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says only 'Get detailed information', which implies a read operation, but no annotations are provided. It does not disclose output format, authentication needs, rate limits, potential errors, or what 'detailed information' includes. The tool's behavioral profile is largely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the core purpose, making it appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and only one parameter, the description carries a heavy burden for context, yet it fails to explain the return value, authentication requirements, or how this tool differs from its sibling 'get_channel_info'. The tool's minimal footprint in a crowded sibling set makes this lack of context problematic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the single parameter (url) with a description, and the tool description does not add any additional meaning beyond that. The baseline of 3 is appropriate since the schema handles the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and resource (detailed information about a Telegram channel), but it does not differentiate from the sibling tool 'get_channel_info' which likely serves the same purpose. The phrase 'using the API' hints at a specific backend but is not sufficiently distinguishing.
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 versus alternatives such as 'scrape_channel' or 'get_channel_info'. There are no explicit conditions, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'scrape' and 'fast and efficient', providing no information about rate limits, authentication requirements, whether it is read-only, or what data is returned. This is a significant gap for a tool that interacts with an external service.
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 a single short sentence of eight words, making it concise and front-loaded. However, the phrase 'fast and efficient' is vague and does not add actionable value, so it is not as tight as it could be. Still, it avoids unnecessary length and gets to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must provide essential context about return values and behavior. It does not mention what the scrape returns (e.g., posts as JSON), nor does it explain how date filters or max_posts affect the output. Given the complexity of a scraping tool, this description is insufficient.
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 provides complete descriptions for all four parameters (100% coverage), so the baseline is 3. The description adds no parameter-level details, but the schema already explains url, date range, and max_posts. Therefore, the description does not need to compensate, and a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('scrape') and the resource ('Telegram channel'), and mentions 'using the API' which differentiates it from manual scraping tools. However, it does not specify the exact scope or output, nor does it contrast with all siblings. The phrase 'fast and efficient' is a general trait rather than a precise differentiator.
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 is provided about when to use this tool over alternatives like scrape_channel, scrape_channel_full, or api_search_channel. The only implied hint is 'fast and efficient', but this is not a clear recommendation, and there is no mention of exclusions or specific use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It does not mention authentication requirements, rate limits, return format, or any side effects. The only implicit behavior is that it performs a read-only search.
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 very short and to the point, with no unnecessary words. However, it is so minimal that it sacrifices substance for brevity, though it remains a single clear sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should explain what the search returns and when to use it. It does neither. The description is sufficient for a basic understanding but lacks critical context for an AI agent to select it correctly among many similar 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 input schema fully describes the parameters (url, query, limit), so the description adds no additional meaning. The baseline score of 3 applies, and the description does not elaborate on query syntax or url format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (search) and target (messages within a Telegram channel), which distinguishes it from scraping or info tools. However, it could be more explicit about the scope (e.g., search across all messages in the channel) and does not mention any limitations.
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 about when to use this tool instead of siblings like scrape_channel or api_scrape_channel. The description only states the action, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states intent and does not explain side effects such as session creation, potential manual confirmation (e.g., OTP), or impact on other tools.
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 unnecessary words. It front-loads the verb and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits key context such as whether authentication requires manual steps, how login state affects other tools, or what the agent should expect after successful authentication. No output schema mitigates this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no additional parameter semantics. According to the baseline for high coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Authenticate'), resource ('Telegram Web'), and purpose ('to access restricted content'). It suggests a web-based method, which hints at distinction from 'telegram_api_login', though it does not explicitly name the alternative.
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 versus siblings like 'telegram_api_login' or 'scrape_channel_authenticated'. It does not mention prerequisites, context, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does note that it uses an authenticated session if logged in, which is a useful behavioral trait. However, it lacks details about error behavior, rate limits, output structure beyond 'markdown', or what happens when not authenticated. This is a minimal disclosure.
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 and highly concise. It front-loads the core action ('Scrape a Telegram channel') and immediately adds the return format and an important behavioral condition (authenticated session). Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description does mention the return format (markdown). There are three well-described parameters and no nested objects, so the core usage is covered. However, the absence of usage guidelines relative to many sibling tools and limited behavioral context makes the description only minimally complete for an agent to select this tool appropriately.
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 description does not add any additional meaning to the parameters themselves. Since each parameter already has a clear schema description, the tool description does not need to compensate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: scrape a Telegram channel and return posts in markdown format. It uses a specific verb ('scrape') and resource ('Telegram channel'), which differentiates it from siblings like get_channel_info. However, it does not distinguish itself from closely related tools such as scrape_channel_full or scrape_channel_authenticated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the authenticated session condition but does not specify when to choose scrape_channel over scrape_channel_full, scrape_channel_authenticated, or api_scrape_channel. There are no exclusions or explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states the action (clearing cookies) but does not mention whether this invalidates the session, requires re-authentication, or has irreversible effects. This is insufficient for a security-related mutation.
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, focused phrase with no filler or redundancy. It is appropriately sized for a parameterless tool and immediately front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and multiple related auth tools, the description is incomplete. It does not clarify the relationship to telegram_login or api_logout, nor what the expected state is after execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this (100% coverage). There is nothing to document, so the absence of parameter details is appropriate and does not reduce usefulness.
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 states a specific verb ('Clear') and resource ('Telegram authentication cookies'), making the tool's purpose clear. It is distinct from query tools like scrape_channel, but does not explicitly distinguish from api_logout or telegram_login.
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 versus alternatives such as api_logout or telegram_auth_status. There is no mention of prerequisites, side effects, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action 'Disconnect' but does not explain effects (e.g., session termination, reversibility, whether login is required, or side effects on other sessions). This is minimal and insufficient for a state-changing operation.
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 phrase with no wasted words. It is fully front-loaded and efficient, conveying the core action without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter logout tool, the description is minimally adequate but lacks context about the consequences of disconnecting or how it relates to other logout/login tools. The absence of an output schema also means the description should hint at what happens after the call, which it does not.
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 no parameters, and the schema is trivially 100% covered. The baseline for 0 parameters is 4, and there is nothing for the description to add about parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (disconnect) and the resource (Telegram API), making the purpose understandable. However, it does not distinguish itself from the sibling tool 'telegram_logout', which likely performs the same function, so it misses the opportunity for differentiation.
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?
There is no guidance on when to use this tool versus the similar 'telegram_logout' or other authentication-related siblings. The description simply states the action without context, prerequisites, or exclusions, leaving the agent to guess which logout tool to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that posts are returned in markdown format and that it uses an authenticated session if logged in, which is useful. However, it omits other behavioral traits such as whether login is required, failure behavior without a session, or read-only nature, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, directly states the action and output format, and contains no redundant or irrelevant information. It is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters, but it sits among many related scraping tools with no differentiation. The description does not explain when to use this tool versus siblings, nor does it cover authentication failure scenarios. For a tool with no annotations or output schema, this leaves important context missing.
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 documents both parameters (url and max_posts) with descriptions, achieving 100% coverage. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline score of 3 applies.
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 uses the verb 'Scrape' with resource 'Telegram group' and specifies output as 'posts in markdown format', making the core function clear. However, it does not explicitly distinguish from sibling tools like scrape_channel or scrape_channel_authenticated beyond the word 'group', so it is clear but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like scrape_channel, scrape_channel_full, or scrape_manual. The only contextual hint is 'Uses authenticated session if logged in', which implies auth behavior but does not explain selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only states 'Check if authenticated with Telegram' without revealing what the tool actually does when called, what it returns, or whether it makes a network request. This is a significant transparency gap.
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, focused sentence with no redundant words. It states the exact purpose without elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but the description lacks context that would help an agent understand the behavior and result. There is no output schema, so the description should indicate what 'authenticated' means or what kind of response to expect, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. There is nothing to document, so the description does not need to add parameter semantics. The baseline of 4 applies because the schema already covers everything.
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 clear verb 'Check' with the resource 'authenticated with Telegram,' defining exactly what the tool does. Among sibling tools like telegram_login and telegram_logout, this status check is distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as telegram_login or telegram_logout. It does not mention prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions the authenticated session and restricted access but omits prerequisites (e.g., needing to be logged in), potential failures, rate limits, or output behavior common in scraping tools.
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 that front-loads the action and the distinguishing feature. It contains no redundant words and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is concise but leaves gaps regarding when to use this tool among many siblings and what behavioral expectations come with authenticated scraping. With no output schema, a bit more context about the scraping behavior or return format would have improved 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 provides full descriptions for both parameters (url and max_posts), covering 100% of the schema. The tool description adds no parameter-specific details, but since the schema is sufficient, 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 uses a specific verb 'Scrape' with a resource 'Telegram channel' and distinguishes the tool by its authenticated session capability, which differentiates it from sibling tools like scrape_channel. The added note about accessing restricted content clarifies its unique value.
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 restricted content requiring authentication, but it does not explicitly state when to use this tool over alternatives or provide exclusions. No mention of prerequisites like prior login is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It mentions 'Uses authenticated session if logged in', which is useful, but it doesn't explain the behavior when not logged in, what happens with private channels, rate limits, or the return structure. This is minimal disclosure for a scraping tool that may have significant side effects or constraints.
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 concise sentences with no redundancy. The first sentence front-loads the primary function, and the second adds relevant authentication context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks annotations and an output schema, so the description must compensate. It does not clarify whether date_to is optional and what happens if omitted, what the output format is, or how it interacts with sibling tools. This leaves significant gaps for an agent to correctly invoke and interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with clear descriptions for all three parameters (url, date_from, date_to, including format examples). The tool description adds no additional parameter-level meaning beyond restating the date-range concept, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrapes posts within a specified date range, using a specific verb ('scrape') and resource ('posts'). This distinctly differentiates it from sibling tools that scrape entire channels/groups without date filtering (e.g., scrape_channel, scrape_channel_full).
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 scraping posts in a date range but provides no explicit guidance on when to choose it over alternatives like scrape_channel_full or scrape_manual. It also doesn't mention prerequisites such as login requirements for private channels, leaving the selection criteria to inference from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds a useful behavioral note that it 'Uses authenticated session if logged in' and clarifies it's a read-only style operation ('Get only'). It does not, however, disclose what happens when not logged in, return format, or any rate-limiting/error behavior, leaving room for ambiguity.
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 short, front-loaded sentences. The first sentence immediately states purpose and distinguishes from scraping, the second adds relevant authentication context. No word is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the essential aspects: purpose, scope, and an authentication nuance. It lacks explicit return-value details, but given the low complexity and clear purpose, the description is reasonably 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?
Schema description coverage is 100% for the single 'url' parameter, so the schema already clearly defines it. The tool description adds no additional meaning to the parameter, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get only the channel/group information') and a specific scope ('without scraping posts'), which distinguishes it from the many scraping tools in the sibling list. However, it does not explicitly differentiate from the similarly named 'api_get_channel_info' sibling, so it falls short of a perfect 5.
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 context: use this when you need just channel/group info rather than posts, and it notes the authenticated session behavior. However, it neither explicitly names alternative tools nor provides clear when-not-to-use guidance, leaving the usage guidance at an implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It mentions using an authenticated session if logged in and returning the file location, which adds context. However, it omits side effects like file creation details, rate limits, or whether authentication is required, so transparency is partial.
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 concise sentences, front-loaded with the main action and resource, and contains no redundant or extraneous information.
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 the tool's scale (scraping all posts) and the lack of an output schema or annotations, the description provides the core action and return value but misses important context such as potential volume, prerequisites, limitations, and what 'ALL' includes. It is adequate but not fully 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?
Schema coverage is 100% with both parameters having descriptions. The tool description adds limited extra meaning—chiefly clarifying that 'ALL posts' means the full history and that saving is involved—but does not substantially enhance 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 the action ('Scrape ALL posts') and the resource ('Telegram channel'), and the inclusion of 'ALL' distinguishes it from date-range or limited scrape tools. It also specifies the output behavior (save to file), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'ALL' implies use when a full archive is needed, but there is no explicit guidance on when to choose this tool over alternatives like scrape_date_range or scrape_channel. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does mention the interactive browser session and user-driven login/navigation. However, it does not mention output format, side effects like file saving, or any limitations, leaving some behavioral aspects undisclosed.
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, front-loaded with the tool's purpose, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple interactive tool but lacks explicit details about what 'scrapes' returns, whether files are saved by default, and what happens after interaction. Given no output schema, a bit more detail would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions, so the description need not add parameter details. It adds no extra semantics beyond the schema, meeting the baseline.
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 function: manually scraping a channel by opening a browser for login and navigation. The phrase 'Manual scraping mode' distinguishes it from sibling tools like scrape_channel which likely automate the process.
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 when to use it (when manual login/navigation is needed) but does not explicitly reference alternatives or when not to use automated tools. The context is clear but not fully exclusive.
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-server MCP server](https://glama.ai/mcp/servers/KYONY/telegram-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/KYONY/telegram-mcp-server)

Score Badge

Copy to your README.md:

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

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/KYONY/telegram-mcp-server'

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