telemost-mcp-server

telemost_stats_subscribers

telemost_stats_subscribers

Read-onlyIdempotent

Analyze subscriber growth or decline for any Telegram channel over daily, weekly, monthly, or yearly periods. Get clear audience analytics to inform your strategy.

Instructions

Telegram audience analytics: subscriber growth chart for a channel, track audience growth or decline over time (day/week/month/year). Paid per call in USDC from your wallet (see telemost_catalog for the price).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "channel": "<channel>"
    },
    "name": "telemost_stats_subscribers"
  }
}

Input Schema

Name	Required	Description	Default
`region`	No
`channel`	Yes
`aggregation`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.2Aug 10, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already establish read-only and non-destructive behavior, lowering the bar. The description adds a key non-obvious behavioral trait: 'Paid per call in USDC from your wallet (see telemost_catalog for the price),' which is critical for an agent to know. This goes beyond the structured 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 two sentences with no filler. The first sentence front-loads the primary purpose and scope, while the second adds essential cost information. Every word earns its place.

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 tool with a simple schema (one required, two optional parameters), the description covers the core purpose, time aggregation, and cost. It omits details like region semantics, but those are self-explanatory from the schema enums, and no output schema is present so return format is not required.

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 0%, and the description partially compensates by enumerating time granularities ('day/week/month/year'), which maps to the aggregation parameter, and implying 'channel' in 'for a channel.' However, the 'region' parameter is not explained, so the description doesn't fully compensate for the lack of schema documentation.

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 with a specific verb ('track') and resource ('subscriber growth chart for a channel'), and it distinguishes itself from sibling telemost_stats_* tools by focusing specifically on subscriber growth rather than engagement, reach, or mentions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool ('Telegram audience analytics: subscriber growth chart'), implying it's for tracking audience growth or decline over time. It doesn't explicitly mention alternatives or exclusions, but the use case is unambiguous enough without them.

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