Skip to main content
Glama

Limzo Telegram Group Stats

List or search public Telegram groups

list_groups
Read-only

Call this to discover Telegram groups tracked by Limzo — to browse the directory, filter by language, or find a group's slug for get_group_stats. Optional query filters case-insensitively over group title, username, slug, and description. Optional lang (ISO 639-1, e.g. "fa", "es") keeps only groups where that language is a meaningful share of what members write — the way to answer "find active Persian/Spanish groups". Omit both to list the top groups by Limzo Score. The directory covers PUBLIC groups only — a group with no t.me handle is never listed, though it may still have a /s/ page. Each row carries a language mix (primary language + top languages as percentages); rows also include slug, title, username, plan, member_count, 7-day messages and active members, score and page URLs, plus total_matches so you can tell when more groups matched than were returned.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
langNoISO 639-1 language code (e.g. "fa", "es", "en"). Keeps only groups where that language is a meaningful share of the group.
limitNoMaximum groups to return. Defaults to 20, capped at 50.
queryNoKeyword matched case-insensitively against group title, username, slug, and description. Omit to list the top groups by Limzo Score.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
docsNoHuman-readable API documentation.
langNoThe applied ISO 639-1 language filter, or null when not filtering by language.
queryNoThe normalized search keyword, or null when listing top groups.
groupsYes
openapiNoMachine-readable OpenAPI document for the REST API.
total_matchesYesGroups that matched, before the limit was applied.

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, and the description adds rich behavioral context: the directory only lists public groups with t.me handles, groups without handles may still have /s/ pages, language filtering uses 'meaningful share of what members write', and total_matches indicates when more results matched than were returned. This goes well beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence carries useful information. It is front-loaded with purpose, then filters, then key scope constraints, then return-row details. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, the description need not enumerate return values, but it still summarizes the row contents and total_matches behavior. It covers use cases, filter semantics, the public-only boundary, and interaction with a sibling tool, making it complete for an agent to select and call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining what 'meaningful share' means for lang, clarifying that query matches title/username/slug/description, and noting that omitting both query and lang lists top groups by Limzo Score. It does not address the limit parameter, but the schema already fully covers it.

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 states a specific verb and resource: discover Telegram groups tracked by Limzo. It enumerates concrete use cases (browse directory, filter by language, find a slug) and explicitly distinguishes itself from the sibling get_group_stats by positioning the tool as the way to obtain the slug for that tool.

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 usage context: call this to browse, filter, or find slugs, and explains the public-only scope. It does not explicitly state when not to use it or mention get_global_stats as an alternative, so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool targets a distinct concern: get_global_stats for network-wide numbers, get_group_stats for a specific group, and list_groups for discovery and lookup. There is no functional overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern: 'get_global_stats', 'get_group_stats', 'list_groups'. The naming is predictable and clear.

Tool Count4/5

With only 3 tools, the server is concise and focused. While minimal, it covers the core operations for a stats-viewing server without feeling incomplete. The count is appropriate for its narrow scope.

Completeness5/5

The tools fully cover the domain of querying Telegram group stats: global overview, per-group details, and group discovery. There are no obvious gaps; the surface supports typical user workflows end-to-end.

Resources