telemost-mcp-server

Server Quality Checklist

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

Latest release: v0.2.2
Disambiguation2/5
Several tools overlap in scope; telemost_stats_channel already includes engagement, reach, and subscriber metrics, making telemost_stats_engagement, telemost_stats_reach, and telemost_stats_subscribers partially redundant. Similarly, telemost_search and telemost_posts_search both search posts, and telemost_ads_posts adds another ambiguous post search. The boundaries between search tools and stats tools are not clear enough for reliable tool selection.
Naming Consistency3/5
All tools share the telemost_ prefix and use snake_case, but the pattern is inconsistent: some are noun-only (catalog, entities, sentiment), some use feature prefixes (stats_*, ads_*, sentiment_*), and some mix noun+verb (posts_search). The naming is readable and groups exist, but there is no uniform verb_noun structure.
Tool Count3/5
With 20 tools, the server is on the heavy side for a single-purpose API. While the domain spans analytics, ads, and search, several tools overlap and could be consolidated (e.g., stats tools). The count is not extreme but feels inflated by redundant endpoints.
Completeness4/5
The tool set covers the core Telegram data access needs: channel stats, posts, search, sentiment, entities, ads, and discovery. Minor gaps exist, such as no ability to list channels by category or country beyond keyword search, and some historical data is limited to 14 days. Overall, the domain is well covered with only small missing features.
Average 4/5 across 20 of 20 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable context: the pay-per-call pricing (in USDC from the wallet) and the fact that individual metrics are populated only when the channel exposes them. This is useful but not extensive, so a 3 is appropriate.
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 concise (three sentences) and front-loaded with the core purpose. The first sentence lists the metrics, the second clarifies scope and data availability, and the third adds pricing. No unnecessary repetition or fluff; it earns its place.
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 provides a decent overview of what metrics are included, the public-channel constraint, and cost, but it lacks explanation of the region parameter, input format for the channel, and return structure (no output schema exists). Given the tool's moderate complexity and absent schema descriptions, this is a minimal viable description but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description needed to explain the parameters. It does imply the 'channel' parameter means any public channel, but it entirely omits the 'region' parameter (cis/worldwide), which has an enum but no explanation. The description adds minimal meaning beyond the schema's raw property names, so it fails to compensate for the lack of schema descriptions.
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 identifies the tool as a channel analytics/stats provider, enumerating specific metrics (subscribers, growth, views, reach, engagement, ERR, mentions, forwards). This distinguishes it from sibling tools like telemost_stats_subscribers or telemost_stats_reach, which focus on individual metrics. However, it lacks an explicit action verb like 'retrieve' or 'get', so it's not 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 phrase 'quick stats and health check of any public channel' implies a general-purpose overview use case, and the caveat that individual metrics populate only where exposed hints at limitations. However, there is no explicit mention of when to use this aggregate tool versus the specialized sibling stats tools, nor any exclusion criteria. Guidance is implied but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds meaningful context: the catalog is free, machine-readable, and contains prices/schemas/examples, which goes beyond the annotations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. Front-loaded with purpose and cost, making it concise and well-structured.
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 simple catalog with one optional parameter, the description covers content and cost. However, missing parameter semantics and no mention of output format leave some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'block' has no description in the schema or the tool description. Enum values (data, statistics, ads, reference) are suggestive but the description doesn't explain how to use them to filter the catalog.
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 identifies this as a catalog of paid Telemost tools with prices, schemas, and examples, distinguishing it from sibling tools that return specific data. However, it uses a noun phrase rather than an explicit verb like 'list' or 'get', making it slightly less action-oriented.
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 this is a free way to browse paid tool metadata, but it never explicitly states when to choose this over sibling tools, nor does it mention the optional 'block' filter as a way to narrow results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive. The description adds crucial behavioral context: it is paid per call in USDC from the wallet and references the catalog for pricing, which is not covered by 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?
Two sentences pack the purpose, the alternative, and the cost/pricing pointer. Every word earns its place, and the key information is front-loaded.
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 tool has no output schema, and the description does not state the return format. It covers the main use case and cost, but parameter ambiguity and lack of output details create meaningful gaps for an agent deciding whether and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It mentions 'recent posts and reactions for a channel, group or topic', hinting at 'topic' and 'source', but does not explain 'period' (despite an enum), 'source' format, or how parameters relate. This leaves the agent guessing about required values.
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 identifies the tool as 'Telegram sentiment analysis' with raw inputs for custom mood/opinion analysis, and distinguishes it from the LLM verdict variant by name. Though lacking a direct verb, the resource and intent are unambiguous.
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?
Explicitly contrasts with the LLM alternative ('For a ready LLM verdict use /v1/data/sentiment/llm') and states the use case ('to run your own mood or opinion analysis'). It also mentions the paid nature and how to find pricing, providing context for 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds valuable context beyond annotations: it notes the tool is paid per call in USDC (pointing to telemost_catalog for pricing) and clarifies that it extracts formatting-level entities rather than semantic NER. This provides behavioral insight not captured by 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, leading with a clear purpose statement and then detailing entity types and distinctive traits. The phrase 'at scale' adds little value, but overall the text is efficient and front-loaded without excessive fluff.
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 simple one-parameter schema and strong annotations, the description covers purpose, entity types, and cost, which is adequate. However, it omits any information about the response format or output structure (no output schema exists), and 'recent posts' is vague regarding time range or pagination. Moderate completeness for a straightforward extraction 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 schema has only one parameter ('source' as a string) with zero description coverage. The description implies that 'source' refers to a channel (e.g., 'from a channel's recent posts'), adding meaning beyond the bare schema. However, it does not specify the expected format (like username, URL, or ID), leaving some ambiguity.
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 a specific verb ('pull') and resource ('structured entities from a channel's recent posts'), enumerating the entity types (links, mentions, hashtags, etc.). It also distinguishes itself from semantic NER and related tools by specifying 'Formatting-level entities, not semantic NER', which helps separate it from sibling analytics tools.
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 by describing the extraction task, but it does not explicitly state when to use this tool versus alternatives like telemost_messages or telemost_posts_search. There is no mention of exclusions or preferred scenarios, leaving the decision to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds key behavioral context beyond that: the call is paid per use in USDC, and the data is curated and organized by theme. This is valuable and does not contradict 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 a single, front-loaded sentence that conveys purpose, use case, and cost structure without wasted words. The parenthetical about pricing is useful and concisely integrated.
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 no parameters and good annotations, the description covers purpose, usage context, and cost. However, it does not describe what a 'compilation' looks like in the response (e.g., list of channel names, metadata), and there is no output schema to fill that gap.
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 0 parameters, so the baseline is 4. There is no parameter information needed; the schema already covers 100% of the (empty) parameter set, and the description adds nothing that would conflict with it.
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 provides curated compilations of Telegram channels for discovery and research, which distinguishes it from sibling tools like telemost_search or telemost_catalog. However, it does not use a verb like 'get' or 'list' and the differentiation is implicit rather than explicit.
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 market mapping and research, giving a clear context. It does not explicitly say when not to use it or name an alternative tool for related tasks, and the mention of telemost_catalog is only for pricing, not for choosing the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context: the tool is paid per call and outputs specific components (label, score, trend, summary). This enriches the behavioral profile beyond what annotations provide.
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 compact, with two sentences that pack essential information without excess. The first sentence is dense but efficient, and the second adds cost context. It is appropriately sized for the tool's complexity.
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 covers the output (label, score, trend, summary) and the use case, but leaves parameter semantics vague and does not mention alternatives. With no output schema, more detail about expected results would be helpful, yet the core purpose is sufficiently clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'period' or 'source' parameters. The only hint is that the tool works for a 'channel, group or topic', which roughly maps to 'topic' but leaves the other parameters undefined, failing to compensate for the missing schema descriptions.
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 it performs sentiment analysis using an LLM, returning a label, score, trend, and summary for a channel, group, or topic. The explicit mention of 'LLM verdict' distinguishes it from the sibling tool 'telemost_sentiment', providing clear differentiation.
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 phrase 'Gauge audience mood or brand perception before acting' gives a concrete use case, and the note about being paid per call with a pointer to telemost_catalog offers practical guidance. However, there is no explicit when-not-to-use or comparison with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive traits. The description adds key behavioral context: the tool is 'Paid per call in USDC from your wallet' and references telemost_catalog for the price, which is crucial for an agent to know before invoking. It also clarifies the resource scope (a channel).
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?
Two sentences, front-loaded with the core purpose ('Telegram reach analytics'). The second sentence adds a necessary cost warning and cross-reference to telemost_catalog. No redundant or filler content.
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 two-parameter tool with no output schema, the description conveys the tool's purpose, target metric, and cost model. However, it does not explain the aggregation parameter's meaning or return format, which would make it more complete. Overall, it is fairly complete for an agent to decide on invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions 'for a channel' which gives some context to the required 'channel' parameter, but it omits any explanation of the 'aggregation' parameter (day/week/month/year). The description adds little meaning beyond the schema for aggregation and does not specify input formats or examples.
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: 'average post reach chart for a channel' with a specific metric (reach) and resource (channel). It distinguishes from siblings like telemost_stats_engagement and telemost_stats_subscribers by focusing on 'reach' specifically.
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 analyzing post reach over time but does not explicitly state when to use this tool versus alternatives. It mentions the paid nature and directs to telemost_catalog for pricing, giving an operational guideline, but lacks 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context beyond this by specifying public-channel scope, the optional `since` date filter, and payment via USDC (billing behavior). This goes beyond simply restating 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 compact and front-loaded: the first sentence states the core function. The second sentence gives use cases, and the third covers filtering and payment. Every sentence earns its place with no fluff or repetition.
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 tool has 3 parameters with no descriptions and no output schema. The description covers purpose, use cases, `since`, and pricing, but omits semantics for `source` and `region`, and does not describe return format or pagination. This 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does clarify `since` ('filters by date'), but it gives no guidance on `source` (format, required, what counts as a channel/group) or `region` (meaning of 'cis' vs 'worldwide'). Description only compensates for one of three parameters.
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: 'fetch recent messages and posts from any public Telegram channel or group.' This uses a specific verb ('fetch') and resource ('Telegram channel/group'), and it distinguishes itself from siblings like telemost_post (single post) and telemost_posts_search (search) by emphasizing recency and monitoring.
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 use contexts: 'Monitor news sources, track updates, or feed content into downstream analysis.' This implies when to use the tool, but it does not explicitly mention alternatives or when-not-to-use, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds meaningful behavior: 'Paid per call in USDC from your wallet (see telemost_catalog for the price).' This cost disclosure is valuable and 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?
Two sentences, front-loaded with the core purpose, followed by a cost warning. Every sentence adds value; there is no fluff or repetition.
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 covers the main function and cost, but lacks parameter semantics and expected response format. With no output schema and two parameters (one with an enum), the agent needs more details on how to specify the post and region. 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for parameter meaning. It does not explain what 'post' expects (URL, ID, username) nor what 'region' ('cis' vs 'worldwide') means. The mention of 'a single post' in the description gives minimal context, but not enough for correct invocation.
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 ('Measure') and resource ('a single post') with clear scope: 'statistics over time, views, forwards and reactions.' This distinguishes it from siblings like telemost_posts_search or telemost_stats_engagement, which focus on discovery or broader engagement metrics.
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?
It provides clear context: 'Measure how a specific post performed.' This implies use when you need post-level analytics. However, it does not explicitly exclude alternatives or name sibling tools for other use cases, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, non-destructive, and idempotent. The description adds the key cost fact ('Paid per call in USDC from your wallet') and clarifies it only covers public content. It doesn't contradict 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: the first declares the core purpose, the second adds use cases and pricing. No filler words; every sentence earns its place.
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?
No output schema exists, and the description doesn't describe the return format or how results are structured. It also doesn't explain how scope/region filters work, leaving the agent to infer from parameter names. However, the payment note and public-scope clarification provide useful operational context, giving partial completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the four parameters; schema coverage is 0%. While the schema shows enums for scope and region, the description adds no meaning to query, limit, scope, or region, so it fails to compensate for the lack of parameter 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 opens with 'Telegram search and discovery' and specifies 'find public Telegram channels, groups and posts by keyword', giving a clear verb+resource+scope. It differentiates from siblings like telemost_posts_search by covering all content types.
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?
It provides practical use cases: 'Discover sources, communities, competitors or content on any topic.' However, it does not explicitly mention when not to use it or name alternatives, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds critical context: the tool is paid per call in USDC and references telemost_catalog for pricing. It also indicates time-series output ('over time'), which is not in 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 three concise sentences, front-loaded with the core metrics, followed by use case and payment note. Every sentence adds value with no redundancy or fluff.
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 no output schema, the description should explain return values more explicitly. It names the metrics but not their format or the effect of the aggregation parameter. The payment and benchmark context are helpful, but the lack of parameter guidance leaves the tool only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain the 'channel' or 'aggregation' parameters. 'Over time' weakly hints at aggregation, and 'channel performance' implies the channel parameter, but this is insufficient for an agent to know how to set these parameters correctly.
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 specifies exactly what the tool provides: engagement rate (ER), engagement rate by reach (ERR), and 24-hour reach engagement (ERR24) over time. This clearly differentiates it from sibling tools like telemost_stats_channel or telemost_stats_reach, which focus on different metrics.
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 phrase 'Benchmark audience activity and channel performance' gives a clear use case, but it does not explicitly mention alternatives or when not to use this tool. It implies usage context without direct comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds important economic behavior: 'Paid per call in USDC from your wallet (see telemost_catalog for the price),' which is beyond the annotations. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first front-loads the core function and data fields, the second gives use cases and cost. Every word adds value; no fluff or repetition.
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?
With no output schema, the description lists the returned fields, which addresses return value expectations. It also covers cost and use cases. However, it omits potential error conditions or parameter effects (e.g., how 'region' changes results), leaving minor gaps for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'channel' or 'region' parameters. While 'channel' is intuitive and 'region' has an enum, the description does not clarify what 'region' affects or the expected format of 'channel', leaving the agent to infer semantics from field names alone.
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 explicitly states the tool provides 'Telegram channel analytics and profile data' and enumerates the specific fields returned: 'title, description, subscribers, category, country, language, links and verified flag.' It further clarifies use cases ('Vet a channel, enrich a dataset, or look up channel data in one call'), making the purpose unmistakable and distinct from siblings like telemost_stats_engagement or telemost_search.
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 usage contexts ('Vet a channel, enrich a dataset, or look up channel data in one call') and implies this is the all-in-one channel info tool. It does not explicitly name alternative tools for specific use cases, but the detailed field list allows an agent to infer when this tool is appropriate versus siblings like telemost_stats_channel.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe, idempotent read-only behavior. The description adds valuable behavioral context: the tool is 'Paid per call in USDC from your wallet,' searches only posts from the last 14 days, and supports extended query syntax. These details go beyond the structured annotation flags and inform the agent about cost and time constraints, though it still omits specifics like pagination or result format.
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 concise and front-loaded, with the primary purpose in the first clause. It packs essential information (use case, post window, payment, pricing reference) into two sentences with no filler. Every sentence adds value.
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?
Given the tool has 4 parameters and no output schema, the description covers the main use case, search scope, time limit, and cost model, which are the most critical contextual points. However, it lacks explanation of return structure and parameter behaviors like defaults or region selection, making it not fully complete for a complex search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must clarify parameters, but it only vaguely references 'extended query syntax' which likely maps to the 'extended' parameter. It does not explain 'query', 'limit', 'region', or 'extended' directly. While some parameter names are self-explanatory, the description does not compensate for the lack of schema-level documentation, leaving the agent without enough guidance for parameter values.
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 purpose with a specific verb and resource: 'Telegram post search and social listening: full-text search over posts across public channels.' It also specifies the scope (keywords, brand or topic) and differentiates itself by mentioning 'extended query syntax' and the 14-day post window, which helps distinguish it from sibling tools like telemost_messages or telemost_search.
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: 'Brand monitoring and market research.' It also mentions the 14-day window as a temporal constraint. However, it does not explicitly name alternatives or say when not to use it, though it does reference telemost_catalog for pricing, implying a cost consideration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context: it is 'Paid per call in USDC from your wallet', which is not captured in annotations. It also explains the basis of similarity (topic and audience), enriching understanding 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 two sentences, each earning its place: the first sentence states the core purpose and use cases, and the second adds cost information. It is concise and front-loaded with the primary action.
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 tool has no output schema, so the description should explain what is returned. It implies a list of similar channels but does not specify output format, limits, or whether it returns names, IDs, or stats. Annotations cover safety, and the cost is mentioned, but the missing return details and parameter format reduce 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 schema has one required param 'channel' with 0% description coverage. The description implies 'channel' is the seed channel for finding similar ones, which adds some meaning. However, it does not specify expected format (e.g., channel ID, username) or any constraints, leaving a gap that could cause invocation errors.
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: 'find channels similar to a given one by topic and audience'. It specifies the resource (channels) and the action (find similar), and distinguishes it from siblings like telemost_search (general search) and telemost_channel_info (specific channel info) by focusing on similarity and competitor discovery.
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 it: 'discover competitors, alternatives or expansion targets'. However, it does not explicitly exclude alternatives or mention when to prefer a different tool, such as telemost_search for broader discovery. The mention of pricing via telemost_catalog is a cross-reference but not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral details: paid per call in USDC and the one-year history limit. It does not describe return format, but the safety profile is well covered by annotations, so this is a solid score above baseline.
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 three sentences long, front-loads the main purpose, and includes an alternative and cost without fluff. It is slightly denser than strictly necessary, but every sentence contributes useful 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?
For a read-only stats tool with two parameters and no output schema, the description gives purpose, alternatives, cost, and history scope. However, it lacks parameter semantics (especially period) and does not describe what the response looks like, leaving some gaps. 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly covers 'channel' via '@channel', but it does not explain the 'period' parameter or its enum values (7d, 30d, 90d, all). The mention of 'Up to a full year of history' hints at the 'all' option but does not clarify the ranges, leaving period semantics ambiguous.
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 tracks mentions and citations of a given channel across other channels, who references it, and its share of voice. It distinguishes itself from sibling tools by explicitly contrasting with word tracker and post search for keyword tracking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool (mention tracking for a channel) and when not to use it ('For keyword or brand tracking across posts, use the word tracker or post search'). It also mentions paid-per-call cost and up to a year of history as contextual usage factors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds valuable context beyond annotations: it searches only the last 14 days (a time constraint), and it's paid per call in USDC, which is critical for the agent to know. The mention of 'creatives' clarifies return content. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. Every clause earns its place: purpose, data scope, recency limit, and cost model. No fluff or repetition of the schema.
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 search/read tool with good annotations, the description covers: what it does, freshness window, cost, and output type (creatives). It lacks explicit return structure, but no output schema is expected for such tools, and the description gives enough context for an agent to decide. The 14-day limit is a notable constraint. One gap is lack of clarification on how 'all' period works, but that's minor.
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 0%, so the description carries the burden for params. It mentions 'query' implicitly via 'discover ad posts' and 'what and where competitors advertised', but does not explicitly explain the 'query' param or the 'period' enum. The period values (7d, 14d, all) are self-explanatory from schema, but the description adds no details on formatting or semantics beyond that. Baseline 3 is appropriate given the schema's explicit enum for period.
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 purpose: discovering Telegram ad posts and performing competitor analysis, with a specific verb ('discover') and resource ('ad posts on channels'). It also distinguishes itself from siblings by focusing on ads and creatives, which none of the sibling names suggest.
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 context for when to use it: for ad intelligence and competitor analysis, searching posts from the last 14 days. It doesn't explicitly name alternatives, but its unique focus on ads vs. general post search (e.g., telemost_posts_search) makes the use case clear. The description could benefit from explicit exclusions but is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive. The description adds important behavioral information: the tool is paid per call in USDC from the user's wallet, and that it provides reference data. This goes beyond what annotations provide.
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?
Two concise sentences cover the purpose and cost, front-loaded with the main function. No wasted words.
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?
Given the simple two-parameter schema and strong annotations, the description covers the core purpose and cost. However, it does not describe the response format or the role of 'region', which would be helpful given there is no output schema.
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%, so the description must compensate. It explicitly lists 'countries, categories and languages' which maps to the 'kind' enum, but it does not explain the 'region' parameter at all. The description adds some meaning for one parameter but leaves the other undocumented.
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 provides reference data (countries, categories, languages) for the Telegram analytics API, used in filters/targeting. It distinguishes itself from siblings by focusing on static dictionaries and pointing to telemost_catalog for pricing.
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?
It gives a clear context for when to use this tool (when you need reference data for filters/targeting) and adds a cost warning with a pointer to telemost_catalog for price. It lacks explicit exclusions, but the use context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description discloses billing behavior ('Paid per call in USDC from your wallet') and the time constraint ('searches posts from the last 14 days'). This adds meaningful operational context not present in 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?
Two sentences deliver purpose, modes, use case, time window, and cost. No filler or redundancy; information is front-loaded and each clause earns its place.
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 covers purpose, modes, use case, time window, and cost, but does not explain all parameters nor describe the return value (no output schema). Given the tool's moderate complexity and missing param semantics, 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the 'mode' parameter via 'by-period' and 'by-channels' and implies 'word' is the keyword/brand. However, 'period' and 'extended' are not explained at all, leaving half the parameters ambiguous.
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 purpose: 'Telegram keyword and brand tracking' with clear modes ('by-period' vs 'by-channels'). It distinguishes this tool from sibling stats tools by focusing on keyword/brand volume rather than engagement, reach, or subscribers.
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?
It provides clear context: 'Social listening and market research' and notes the 14-day search window. It does not explicitly name alternative tools, but the context implies when this tool is appropriate for tracking specific terms across channels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds valuable business context about costs per call, which is not in the annotations. It also clarifies the data domain. While it doesn't detail return formatting or pagination, the combination is sufficient for this read-only tool.
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?
Two concise, front-loaded sentences: the first defines the tool's core value, the second adds a cost caveat and pointer to related resource. No wasted words, and the structure is easy to parse.
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 no parameters, no output schema, but strong annotations, the description fully covers what the tool returns (ad networks, minimum deposits), its purpose (comparison), and cost implications. It is contextually complete for a simple read-only informational tool.
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 (schema shows an empty properties object), so the baseline is 4. There is no need for parameter explanations, and the description correctly omits them.
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 provides 'Telegram advertising data: available ad networks and their minimum deposits' and explicitly distinguishes its purpose from siblings like telemost_ads_posts by focusing on comparing networks. The verb 'compare' and specific resources (ad networks, minimum deposits) make the intent unambiguous.
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 a clear use case: 'compare where to run campaigns.' It also adds a practical guideline with the 'Paid per call in USDC' warning and cross-reference to telemost_catalog for pricing. However, it does not explicitly state when not to use this tool or name alternative tools for different scenarios, so a minor gap remains.
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:

[![telemost-mcp-server MCP server](https://glama.ai/mcp/servers/slava01011910-ops/telemost-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/slava01011910-ops/telemost-mcp-server)

Score Badge

Copy to your README.md:

[![telemost-mcp-server MCP server](https://glama.ai/mcp/servers/slava01011910-ops/telemost-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/slava01011910-ops/telemost-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/slava01011910-ops/telemost-mcp-server'

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