This server provides tools for analyzing Telegram channels and posts via the TGStat API. Here's what you can do:
Search Telegram channels — Find channels by keyword with optional filters for category, language, and country
Get channel info — Retrieve a channel's profile data including subscriber count, average views, and engagement rate (ERR)
Get channel posts — Fetch recent posts from a channel with view metrics, supporting pagination
Get post details — Access detailed info on a specific post including views, reposts, and reactions
Get channel statistics — View subscriber growth trends and view dynamics over time
Search posts — Full-text search across posts with filters for date range and specific channels
Get channel mentions — Discover where a channel is being mentioned or reposted by other channels and chats
Compare channels — Side-by-side comparison of 2–10 channels by subscribers, reach, and engagement rate
Provides access to TGStat API for Telegram channel analytics, including search, channel information, posts, statistics, mentions, and comparison.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@theyahia/tgstat-mcp compare Telegram channels @rbc_news and @kommersant"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
🌍 Часть WWmcp — коллекции из 114 MCP-серверов для развивающихся рынков (Россия, СНГ, MENA, Gulf, SE Asia, Africa). Единственная коллекция MCP, покрывающая не-западные API.
MCP-сервер для TGStat API — аналитика Telegram-каналов: поиск каналов и постов, статистика, динамика подписчиков и охватов, ERR, упоминания, тренды ключевых слов, сравнение каналов. 20 инструментов.
TGSTAT_TOKEN — API-ключ TGStat. Зарегистрируйтесь и получите токен на api.tgstat.ru (нужен доступ к Stat API и/или Search API — разные инструменты требуют разных пакетов). Текущую квоту и срок пакета смотрите инструментом get_usage.
Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"tgstat": {
"command": "npx",
"args": ["-y", "@theyahia/tgstat-mcp"],
"env": {
"TGSTAT_TOKEN": "ваш_токен"
}
}
}
}Claude Code:
claude mcp add tgstat -e TGSTAT_TOKEN=ваш_токен -- npx -y @theyahia/tgstat-mcpRelated MCP server: lolzteam-mcp
Инструмент | Описание |
| Поиск каналов по запросу с фильтрами категории / языка / страны / типа |
| Профиль канала: подписчики, категория, индекс цитирования (ci_index), отметка РКН |
| Статистика: средний охват поста, ERR%, дневной охват |
| Где канал упоминают / репостят другие каналы и чаты |
| Сравнение каналов (2–10) по подписчикам, охвату и ERR — таблицей |
Инструмент | Описание |
| Последние посты канала с просмотрами; фильтр по датам и пагинация |
| Детали поста: просмотры, репосты, реакции, текст |
| Полнотекстовый поиск постов с фильтрами типа / категории / языка / страны / дат |
| Динамика вовлечённости поста во времени |
Инструмент | Описание |
| История числа подписчиков (group: hour/day/week/month) |
| История суммарных просмотров постов |
| История среднего охвата поста |
| История ERR (engagement rate by reach) |
| Посты других каналов, репостнувшие контент канала |
Инструмент | Описание |
| Динамика упоминаний слова/фразы по периодам (упоминания + просмотры) |
| Разбивка упоминаний слова по каналам |
Инструмент | Описание |
| Коды категорий каналов (для фильтра |
| Коды стран (для фильтра |
| Коды языков (для фильтра |
Инструмент | Описание |
| Квота и лимиты API: израсходовано запросов / каналов / слов, срок пакета |
Ответы курируются: возвращаются только релевантные поля (подписчики, охваты, ERR, текст-сниппет, ссылки), даты — в ISO. Это экономит токены контекста и упрощает ответы модели. Даты в фильтрах указываются как YYYY-MM-DD и автоматически конвертируются в Unix-таймстемпы, которых требует API.
Найди Telegram-каналы про маркетинг на русском
Какая статистика у @durov — подписчики, средний охват, ERR?
Покажи рост подписчиков @vc_ru по неделям за последние 3 месяца
Сравни каналы @rbc_news, @kommersant и @vedomosti по охвату и ERR
Найди посты про AI за январь 2026
Построй динамику упоминаний слова «нейросети» по месяцам
Кто упоминает канал @thebell_io?
Сколько у меня осталось запросов в TGStat API?TGStat закрывает аналитику; соседние серверы из WWmcp — действие:
vk-ads-mcp — рекламные кампании VK Ads
sendpulse-mcp · unisender-mcp — email-рассылки
Пример сценария: «Найди топ финтех-каналы в Telegram (tgstat), оцени их ERR, выбери три с лучшим охватом и подготовь email-анонс через unisender».
npm install
npm run build # компиляция в dist/
npm run typecheck # проверка типов, включая тесты
npm test # vitestЕсли сервер полезен — поставьте звезду этому репозиторию и WWmcp. Это помогает другим найти коллекцию серверов для не-западных API.
MIT
Сравнение нескольких Telegram-каналов по подписчикам, просмотрам, ERR.
| Name | Required | Description | Default |
|---|---|---|---|
| channel_ids | Yes | Массив ID/username каналов для сравнения |
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 only states the comparison metrics but does not disclose whether the operation is read-only, authentication requirements, error handling, or output format. The agent lacks cues about 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. However, the use of Russian may reduce clarity for some agents, and additional detail could help without sacrificing conciseness.
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 tool has one parameter and no output schema, the description should provide more context about how the comparison is presented (e.g., output format, sorting). It lacks examples or expected input formats, making it incomplete for effective use.
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 description coverage is 100% (the only parameter 'channel_ids' is described as an array of channel IDs/usernames). The tool description adds no further meaning beyond the schema, so it meets the baseline but does not enhance understanding.
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 compares multiple Telegram channels by subscribers, views, and ERR. The verb 'Сравнение' (comparison) and resource 'Telegram-каналов' are specific. It distinguishes from sibling tools like get_channel or get_channel_stats which focus on single channels.
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 provides no guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest scenarios where other tools might be more appropriate. The context siblings exist but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Информация о Telegram-канале: подписчики, средние просмотры, ERR.
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | ID или username канала (например @channel или t.me/channel) |
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 only states what the tool returns but does not mention read-only nature, authentication requirements, rate limits, or any side effects. The name implies read-only, but that is not explicit.
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 a single, concise sentence that conveys the core purpose without unnecessary words. It is front-loaded and efficient.
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 tool's low complexity (one parameter, no output schema), the description covers the basic return information but lacks behavioral context and does not specify the output structure. It is adequate but not comprehensive.
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 100% coverage for the single parameter, describing it as channel ID or username. The description adds no further meaning beyond what the schema provides, so it meets the baseline but does not enhance understanding.
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 that the tool provides information about a Telegram channel, listing specific metrics (subscribers, average views, ERR). This distinguishes it from sibling tools like compare_channels or search_channels, though it could explicitly differentiate from get_channel_stats.
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 offers no guidance on when to use this tool vs alternatives. It does not specify prerequisites, context, or when not to use it, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Упоминания канала в других каналах и чатах.
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | ID или username канала | |
| limit | No | Максимум результатов (по умолчанию 50) |
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 not disclose pagination, rate limits, authorization needs, or what the response contains, leaving significant gaps for a read tool.
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 a single concise sentence with no wasted words, but it is under-specified and could benefit from additional details without losing conciseness.
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 output schema, the description should hint at what is returned, but it does not. It also lacks behavioral context, making the tool less complete for an AI agent despite simple parameters.
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 the schema already documents both parameters. The description adds no additional meaning beyond the schema, resulting in a baseline score 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 retrieves channel mentions in other channels and chats, distinguishing it from sibling tools like get_channel_posts or get_channel_stats.
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 the tool is for finding external references to a channel, but does not explicitly state when to use it versus alternatives or mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Последние посты Telegram-канала с метриками просмотров.
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | ID или username канала | |
| limit | No | Количество постов (по умолчанию 20) | |
| offset | No | Смещение для пагинации |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral transparency. It mentions 'latest posts with view metrics' but does not clarify ordering, pagination behavior, error handling (e.g., invalid channel), or that it is a read-only operation. This is insufficient for a tool with no 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 a single concise sentence that front-loads the core functionality. It could be improved by adding more useful details (e.g., default limit value) without increasing length significantly.
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 absence of an output schema, the description should at least hint at the return structure (e.g., fields like post text, view count). It mentions 'view metrics' but does not specify what metrics or how they are presented. For a simple tool with 3 parameters, the description is somewhat incomplete.
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 already provides descriptions for all three parameters (channel_id, limit, offset), achieving 100% schema description coverage. The tool description adds no additional meaning beyond the schema, so 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the latest posts of a Telegram channel with view metrics. It uses a specific verb (get) and resource (channel posts), and implicitly distinguishes from siblings like get_post (single post) and search_posts (search).
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?
No explicit usage guidelines or when-not-to-use scenarios are provided. The description implies basic usage for fetching recent posts, but does not discuss alternatives or contexts where other tools (e.g., get_channel_stats or search_posts) might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Статистика канала: рост подписчиков, динамика просмотров.
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | ID или username канала |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the output type (subscriber growth, view dynamics) but does not disclose read-only nature, authentication needs, rate limits, or any side effects. Minimal behavioral context.
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 a single short sentence in Russian, which is concise and front-loaded. However, it omits important details that could be included without significantly increasing length.
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 tool's simplicity (one parameter, no output schema, no nested objects), the description covers the basic function. However, it lacks information about the format, time range, or any limitations of the statistics. It is adequate but has clear 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?
Schema coverage is 100% for the single parameter channel_id, with a description provided in the schema. The tool description adds no additional meaning to the parameter beyond what is already in the schema, so baseline score of 3 is appropriate.
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 returns channel statistics, specifically subscriber growth and view dynamics. It identifies the resource (channel) and the kind of data (statistics), but does not differentiate from siblings like get_channel or compare_channels.
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?
No guidance on when to use this tool versus siblings. There is no mention of appropriate contexts, prerequisites, or alternative tools. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Детальная информация о посте: просмотры, репосты, реакции.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | ID поста (формат channelId/messageId) |
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 mentions returned fields (views, reposts, reactions) but does not disclose whether the tool is a read operation, requires authentication, or how errors (e.g., missing post) are handled.
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 a single, efficient sentence that conveys core functionality without excess. It is front-loaded with the key purpose.
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?
No output schema exists, so the description should explain return values. It mentions views, reposts, reactions, but likely omits other fields (e.g., content, author, timestamp). Given the tool's simplicity, this is adequate but not fully comprehensive.
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 description coverage is 100% for the single parameter (post_id with format described). The description adds context about the tool's output but not about parameter usage beyond what the schema already provides. Baseline 3 is appropriate.
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 returns detailed information about a post, specifically views, reposts, and reactions. It identifies the resource (post) and action (getting details), and distinguishes from siblings like get_channel_posts (list posts) or search_posts (query posts).
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?
No explicit guidance on when to use this tool versus alternatives. The description implies it's for obtaining detailed info on a single post, but does not define prerequisites, exclusions, or compare with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Поиск Telegram-каналов по запросу с фильтрацией по категории, языку, стране.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Поисковый запрос | |
| category | No | Категория канала | |
| language | No | Язык: ru, en, etc. | |
| country | No | Страна: ru, ua, by, etc. | |
| limit | No | Максимум результатов (по умолчанию 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool 'search' and 'filtering', but lacks details on pagination, rate limits, result scoping, or authentication needs. This is insufficient for a search tool.
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 a single sentence with no superfluous words. It is front-loaded and efficient, providing essential information immediately.
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 5 parameters, no output schema, and no behavioral transparency, the description is too brief. It fails to explain search mechanisms, result structure, or any constraints on filter combinations, leaving the agent insufficiently informed.
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 descriptions cover 100% of parameters, so baseline is 3. The description adds marginal value by grouping filters together, but does not clarify format constraints or value ranges beyond what the schema already states.
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 verb 'search' and resource 'Telegram channels', and mentions filtering by category, language, country. It effectively distinguishes from siblings like 'get_channel' and 'search_posts'.
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 the tool is for searching channels with filters, but provides no explicit guidance on when to use it versus alternative tools, no exclusions, and no context on query syntax or default behaviors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Поиск постов по ключевым словам с фильтрацией по каналам и датам.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Поисковый запрос по постам | |
| channels | No | Ограничить поиск каналами | |
| date_from | No | Дата начала YYYY-MM-DD | |
| date_to | No | Дата окончания YYYY-MM-DD | |
| limit | No | Максимум результатов (по умолчанию 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as read-only nature, pagination behavior, or any side effects. It only states 'search' which implies reading, but this is minimal and insufficient for full transparency.
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?
Single sentence, front-loaded with the key action ('Поиск постов'), and no redundant information. Extremely concise.
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 output schema, the description does not explain what the tool returns (e.g., list of posts, fields). It mentions filtering capabilities but omits sorting, pagination, or result format. It is adequate for a simple search tool but could be more complete.
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 description coverage is 100%, so baseline is 3. The description adds summary context (filtering by channels and dates) which matches the schema, but does not provide additional meaning beyond the parameter descriptions already in 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 clearly states the tool searches posts by keywords with filtering by channels and dates. It specifies the resource and action, but does not explicitly differentiate from sibling tools like search_channels, though the resource difference is implied.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for keyword search in posts, but lacks when-not-to-use or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose, covering channel info, stats, posts, mentions, searches, and comparison. No two tools overlap in functionality.
All tools follow a consistent verb_noun pattern using snake_case (e.g., get_channel, search_channels, compare_channels), making naming predictable and intuitive.
With 8 tools, the server is well-scoped for a Telegram statistics domain, covering essential operations without unnecessary clutter.
The tool surface covers core CRUD and search operations for channels, posts, and mentions. Minor gaps exist (e.g., no tool for subscriber growth history), but agents can accomplish common tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
MCP server for meme generation, template search, caption rendering, and AI meme creation.
SEO MCP server — backlinks, domain authority, tech stack, and 18+ tools via Common Crawl.
MCP server: 447 pay-as-you-go research tools (SEO, ads, SERP) + verified prowl_analyze reports
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/theYahia/tgstat-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
