Limzo Telegram Group Stats
Server Details
Read-only public Telegram group stats from Limzo: leaderboards, activity, levels. No API key.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- LimzoCom/limzo-mcp
- GitHub Stars
- 0
- Server Listing
- limzo-mcp
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: global network stats, specific group stats, and group discovery. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (get_global_stats, get_group_stats, list_groups). Predictable and clear.
Only 3 tools, but they cover the core functionality of a stats server. Slightly minimal but not insufficient for the stated purpose.
Covers global stats, per-group stats, and group listing. Minor gap is lack of comparative analytics, but core retrieval needs are met.
Available Tools
3 toolsget_global_statsGet network-wide Limzo totalsARead-onlyInspect
Call this for network-wide numbers across all public Telegram groups tracked by Limzo (group count, messages, active users, replies, reactions, karma — 7-day and all-time) plus the current top groups by Limzo Score. For finding a specific group, prefer list_groups.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| docs | No | Human-readable API documentation. |
| stats | Yes | |
| openapi | No | Machine-readable OpenAPI document for the REST API. |
| top_groups | No | Current top public groups by Limzo Score. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true. The description adds value by specifying that it returns 7-day and all-time metrics plus top groups. No destructive behavior mentioned, aligning 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one for purpose and one for usage guideline. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, existing output schema, and annotations, the description fully covers what the tool does and when to use alternatives. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema coverage. Description is not required to add parameter details, and it efficiently omits any unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides network-wide numbers across all public Telegram groups, listing specific metrics (group count, messages, active users, etc.) and top groups. It also distinguishes from sibling tool list_groups, which is for finding a specific group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this for network-wide numbers' and 'For finding a specific group, prefer list_groups.' This provides clear when-to-use and when-not-to-use guidance, though it does not explicitly contrast with get_group_stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_group_statsGet public stats for one Telegram groupARead-onlyInspect
Call this when the user asks about the activity, health, leaderboard, mood, or trends of a specific Telegram group tracked by Limzo. slug is the last part of the group's public page URL, limzo.com/s/ (e.g. "hipo"). Returns the curated limzo.public_stats/v1 JSON: messages, replies, active members, daily series, top members, mood, and reactions. Optional range: 7d (default), 30d, all — the wider ranges only serve real data for groups on a paid plan and otherwise silently fall back to 7d, so check range.key in the result. Never includes verbatim member messages.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The group's public slug — the last part of its limzo.com/s/<slug> URL. | |
| range | No | Stats window. Defaults to 7d. 30d/all require the group's paid plan; free groups silently fall back to 7d. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| docs | No | Human-readable API documentation. |
| group | Yes | |
| range | Yes | The range actually served — compare `key` with what you requested to detect the plan fallback. |
| stats | Yes | |
| schema | Yes | |
| openapi | No | Machine-readable OpenAPI document for the REST API. |
| generated_at | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool never includes verbatim member messages (privacy) and explains the silent fallback behavior for range on free groups, adding value beyond the readOnlyHint annotation. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at ~100 words, well-structured with logical flow: usage trigger, slug explanation, return shape, optional parameter with caveat. Every sentence contributes meaning—no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and an output schema, the description provides sufficient context: when to use, parameter details, return fields summary, and edge-case behavior (fallback). No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context for slug (URL format with example) and range (default, fallback, and need to check returned key), enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: retrieving stats for a specific Telegram group when the user asks about activity, health, leaderboard, mood, or trends. It also differentiates from siblings get_global_stats and list_groups, making it clear which tool to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to call (user asks about group stats), explains the slug and range parameters with examples and caveats (fallback for free groups). No ambiguity about prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_groupsList or search public Telegram groupsARead-onlyInspect
Call this to discover Telegram groups tracked by Limzo — to browse the directory or find a group's slug for get_group_stats. Optional query filters case-insensitively over group title, username, slug, and description; omit it to list the top groups by Limzo Score. Returns compact rows (slug, title, username, plan, member_count, 7-day messages and active members, score, page URLs) plus total_matches so you can tell when more groups matched than were returned.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum groups to return. Defaults to 20, capped at 50. | |
| query | No | Keyword matched case-insensitively against group title, username, slug, and description. Omit to list the top groups by Limzo Score. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| docs | No | Human-readable API documentation. |
| query | No | The normalized search keyword, or null when listing top groups. |
| groups | Yes | |
| openapi | No | Machine-readable OpenAPI document for the REST API. |
| total_matches | Yes | Groups that matched, before the limit was applied. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: it mentions case-insensitive filtering, default listing by Limzo Score, and the inclusion of total_matches. No annotation contradictions. Annotations already indicate read-only, so the description supplements appropriately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every sentence adds value without repetition. It is concise and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description covers the tool's behavior completely: it explains the optional parameters, default behavior, and what the return contains (compact rows, total_matches). No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds meaning by explaining how query filters (case-insensitive over specific fields) and the default behavior when omitted. This exceeds the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists or searches public Telegram groups, and distinguishes it from siblings by mentioning it can find a group's slug for get_group_stats. The verb 'discover' and the purpose 'browse the directory' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: to explore groups or get a slug for another tool. It does not explicitly state when not to use, but the context is clear given the sibling tools are for stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.