TelegramLens

by Johnhyeon

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.5.2
Disambiguation5/5
Each tool targets a distinct aspect of Telegram stock monitoring: alias management, buzz analytics, channel management, data collection, etc. Even seemingly similar tools like trending, momentum, and velocity have clearly differentiated purposes (top mentions, surge detection, time-slot analysis).
Naming Consistency4/5
All tools use the 'telegram_' prefix with snake_case. Most follow a verb_noun pattern (e.g., 'add_alias', 'block_name'), though some are simple nouns (e.g., 'channels', 'status'). The pattern is clear and predictable, with only minor inconsistency.
Tool Count4/5
22 tools is slightly above the typical range (3-15) but justified by the breadth of functionality: data collection, alias management, multiple analytics views, channel diagnostics, and user interaction. Each tool covers a specific need without redundancy.
Completeness4/5
The tool set covers the full lifecycle: data ingestion (sync, collect_history), alias resolution (add, candidates, block), analysis (trending, momentum, velocity, buzz, timeline, stock_buzz, watchlist), channel management (classify, set_tier, channels), and output (briefing, send_me). Minor gaps (no alias deletion, no unblock tool) but core workflows are complete.
Average 4.1/5 across 22 of 22 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 97 commits in the last 12 weeks
- Last stable release on August 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are given, so the description must fully disclose behavior. It states the action but does not mention side effects, idempotency, authorization needs, or result format. Minimal disclosure for a state-changing operation.
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, well-structured sentence that is front-loaded and contains no fluff. Every word contributes meaning.
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 action and existence of an output schema, the description is minimally adequate but lacks context about preconditions or relationships to siblings (e.g., telegram_collect_history). Agent may need more cues for proper use.
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 has zero parameters with 100% coverage, baseline is 3. The description adds no parameter-specific information since none exist.
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's purpose: dismissing a backfill proposal and removing the proposal flag. While it closely mirrors the name, it adds the detail about flag removal. However, it does not explicitly distinguish from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., accepting the backfill or other actions). Agent must infer from context; lacks explicit when-to or when-not-to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose whether the operation is read-only, requires authentication, or has any side effects. Merely describes inputs.
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?
Brief and front-loaded with purpose. Parameter list is clear. Could be more structured with sentence-style descriptions, but still efficient.
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 0 required params and an output schema present, description covers core usage adequately. Lacks details on output format but output schema can fill that gap. Sufficient for a read 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?
Schema coverage is 0%, but description adds meaning for all three parameters (channel, hours, limit) including format hints (remove @). Explains defaults. However, no advanced semantics like pagination or ordering.
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?
Describes tool as retrieving original messages (drill-down), clearly indicating verb and resource. However, does not explicitly distinguish from siblings like telegram_search or telegram_timeline, which also deal with messages.
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?
Implies usage for retrieving raw messages but offers no explicit guidance on when to use this tool versus alternatives. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the action (adds to block list) but does not mention whether the operation is destructive, reversible, requires authentication, or has rate limits. This is insufficient for a mutation tool.
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 with two sentences and an args list, front-loading the purpose. It avoids unnecessary words but the note example could be simplified. Every sentence serves a purpose, so it earns a solid score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation, blocking) and lack of annotations, the description is incomplete. It does not explain the scope of the block (global or per-user), interaction with existing blocks, or what the output schema returns. With an output schema present, return values are covered, but behavioral context is missing.
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?
With 0% schema description coverage, the description effectively explains both parameters: code as a 6-digit example (001680) and note as a memo with an example. This adds significant meaning beyond the bare schema, though the note example is cryptic and could be clearer.
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 adds a stock to the ambiguous block list and specifies it blocks name-only matching when accompanied by a code. The verb 'adds' and the resource 'block list' are explicit, and the distinction from sibling tools like telegram_add_alias is implied by the focus on blocking via code.
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 context (blocking by code, name-only matching) but does not provide explicit guidance on when to use this tool vs alternatives such as telegram_add_alias or telegram_fp_candidates. No exclusion criteria or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It only states what is returned, with no mention of read-only nature, authentication requirements, side effects, or performance characteristics. For a simple list tool, this is minimal but not misleading.
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 sentence, front-loaded with the tool's purpose, containing no extraneous information. It is appropriately sized for the tool's simplicity.
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 zero parameters and the presence of an output schema, the description adequately conveys the tool's function. It does not mention potential limitations like pagination or default ordering, but for a list tool with no parameters, it is sufficiently complete.
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?
There are no parameters, and schema coverage is 100% (vacuously). The description provides all meaning beyond the empty schema, meeting the baseline of 4 for zero-parameter tools.
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 returns a list of collected channels with per-channel accumulated message count, tier, and weight. This specific verb+resource combination distinguishes it from sibling tools that perform actions like adding, classifying, or blocking channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs. alternatives. It simply describes the output, leaving the agent to infer usage context from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or side effects. The description only states the return type.
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, consisting of one purpose sentence and a structured list of parameters. It is front-loaded with the main action and uses no unnecessary 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?
The description adequately explains the tool's purpose and parameters. Although it lacks usage context or examples, the presence of an output schema reduces the need to describe return values. It is complete enough for an AI agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes a docstring explaining each parameter: query (stock name or code), hours (aggregation time range, default 24), and samples (number of samples, default 8). This adds significant meaning beyond the schema which only provides titles and defaults.
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 returns a summary and sample original texts of Telegram mentions for a specific stock. It uses a specific verb ('returns') and resource ('summary and samples of Telegram mentions'), distinguishing it from sibling tools like telegram_search or telegram_buzz_score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool vs alternatives. It only describes the basic functionality without explaining contexts, exclusions, or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions immediate reflection but lacks details on side effects (e.g., overwriting behavior, uniqueness constraints), required permissions, error handling, or output format. The output schema exists but is not shown, so return value is unknown.
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?
Extremely concise: two sentences and an Args section. No wasted words; front-loaded with the purpose and immediate effect.
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 simplicity (2 required params, no annotations, output schema exists but not described), the description adequately covers the core action but omits return value, error cases, and idempotency. Might be sufficient for a straightforward tool but lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description adds concrete examples for both parameters (alias: '현대차', code: '005380'). This provides practical meaning beyond the bare schema, though it does not specify format constraints like 'code must be exactly 6 digits'.
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?
Description clearly states it registers an alias (common term/abbreviation) to a 6-digit code. The verb 'register' and resource 'alias' are specific, and the mapping direction is explicit, distinguishing it from sibling tools like telegram_alias_candidates which likely suggest aliases.
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?
Examples are given but no explicit guidance on when to use this tool versus alternatives (e.g., telegram_alias_candidates). The description implies immediate effect but does not state prerequisites or when not 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?
With no annotations, description fully discloses behavior: overwrites auto seeds, subsequent re-seeds preserve manual setting, explains tier's role in buzz weighting. No contradictions. Could mention if destructive or permission implications.
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 paragraphs: first states action and effect, second explains tier's purpose and parameter details. Front-loaded with main action, 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?
Has output schema (not shown), so return values need not be explained. Covers parameters, behavior, and effect. Could mention prerequisites (e.g., channel must exist) but tool is fairly self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description provides detailed semantics for all four parameters, including defaults for weight and note, and acceptable values for tier. Adds meaning well beyond the bare schema.
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?
Description clearly states verb (manual setting) and resource (channel tier), and explains its use in buzz aggregation weighting. It distinguishes from sibling tools by being the only tier-setter, though lacks explicit sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use for manual override of auto seeds, but provides no when-not-to-use or alternative tools. Sibling tools include classification and other channel operations, but no guidance on choosing this over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It describes the tool as collecting and returning data, implying a read-only operation, but does not explicitly state whether it has side effects or requires permissions. The behavioral traits are adequately implied but not fully explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy and includes instructions that could be condensed. It front-loads the trigger phrases but repeats the _playbook and telegram_send_me instructions. Adequate but not optimally concise.
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 presence of an output schema (unshown), the description explains the two data categories and next steps (send via telegram_send_me). It is complete for a composite tool, though it could mention how hours affects the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains the 'hours' parameter: its meaning (aggregation time range), recommendation for morning (12 hours), and default value. This adds significant meaning beyond the schema.
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 aggregates Telegram mention data for market briefings, listing two specific output categories (trending and momentum) and distinguishing itself from siblings like telegram_trending and telegram_momentum. It also provides trigger phrases for usage.
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 explicitly states when to call this tool (for specific briefing queries) and instructs the agent to use telegram_send_me afterwards. It provides clear context but does not explicitly list when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not mention whether the tool is read-only, any side effects, resource usage, or rate limits. It only describes the output purpose but not the behavior.
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 well-structured: a brief purpose statement, background rationale, action hint, and a bulleted parameter list. No superfluous 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?
The description explains the purpose and parameters well. Although the return format is not described, the presence of an output schema helps. It could mention that the output is a list of candidate names, but it's not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates fully by explaining each parameter (days, max_name_len, min_count, top), including their defaults and units. This adds significant value beyond the schema.
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 returns false positive stock name candidates and explains the rationale (short names with common word conflicts). It distinguishes itself from siblings like telegram_block_name and telegram_alias_candidates by specifying the use case.
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 on when to use it (for suspected false positives due to short name conflicts) and suggests a follow-up action (use telegram_block_name). However, it does not explicitly state when not to use it or compare with similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It does not disclose whether the tool is read-only, has rate limits, or any side effects. While it's a query tool, transparency requires explicit statements about safety, which are absent.
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 structured well with an intro sentence, usage guideline, and a clear Args list. It is concise enough but might be more compact; still, every sentence serves a purpose.
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 that an output schema exists (so return details are covered), the description adequately explains inputs and usage. It could mention output format briefly, but overall it is complete for a tool with clear parameters and siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates thoroughly by explaining each parameter (hours, baseline_hours, top, kind) with default values and allowed values for kind. This fully adds meaning beyond the schema structure.
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 returns stocks with recent mention surges compared to a baseline period, and distinguishes it from telegram_search for non-stock queries. The verb 'return' and resource 'stocks with momentum' are specific and unambiguous.
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?
Explicitly states when to use (stock code matching) and when not (macro/geo/theme questions should use telegram_search). Provides clear alternative, leaving no ambiguity.
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?
With no annotations, the description carries full burden. It explains the algorithm: aggregates per bucket, computes increase rate, detects spikes, and includes baseline_ratio. It does not mention destructive actions or auth needs, but the read-only intent is clear.
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 well-structured with a purpose statement, algorithm explanation, and parameter list. It is slightly verbose but each section adds value. Could be tightened slightly without losing clarity.
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 an output schema exists, the description need not detail return values. It covers the algorithm and all parameters thoroughly. Minor gaps: no mention of data freshness or potential errors, but overall complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully compensates. Each parameter (query, bucket_minutes, window_hours, spike_min, top) is explained with its meaning and default. This provides the agent with all necessary context beyond the schema.
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 returns time-based flow and surge (velocity) of mentions per stock, with specific verb (returns) and resource. It distinguishes from siblings like telegram_momentum and telegram_trending by focusing on velocity over time buckets and baseline ratio.
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 explains behavior when query is omitted but does not explicitly state when to use this tool versus alternatives like telegram_momentum or telegram_trending. It implies usage for velocity analysis but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains that it scans all channels, is slow, uses sampling, and classifies based on threshold. However, it does not explicitly state whether the tool modifies data (e.g., read-only) or any side effects. It is likely non-destructive but transparency could be improved by confirming safety.
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?
Description is concise with two paragraphs: purpose/scope and parameter details + usage note. It is front-loaded with the main function. Could integrate the scope limitation more succinctly, but overall efficient.
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 the tool's complexity (classification of many channels), the description covers purpose, scope, parameter behavior, and performance warning. Output schema exists, so return format is handled. Complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no descriptions (coverage 0%), but the description explains all three parameters: sample (messages per channel), threshold (stock channel classification density), and min_mentions (minimum cumulative mentions). This adds essential meaning beyond default values and titles, fully compensating for schema gaps.
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?
Description states it scans all channels, measures stock mention density, and classifies channels as stock-focused vs macro/chat. It clearly distinguishes from sibling tools like telegram_channels (listing) or telegram_buzz_score (single-channel buzz). The specific verb 'scan and measure density' and resource 'all channels' make purpose evident.
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?
Description says 'scan all channels and is slow, use only when needed', providing clear usage context. It implies diagnostic purpose but does not explicitly list alternatives or when to avoid. Still, the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions it's a heavy operation and requires consent, but does not disclose whether it's async, how long it takes, or effects like duplicate requests. Some transparency but gaps remain.
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 with three clear parts: main action, usage condition, parameter explanation. Every sentence adds value, 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 tool's simple purpose (request background collection) and the existence of an output schema (not provided), the description adequately covers when and how to use it. It does not explain the return value, but that may be acceptable for a request-type tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (days) with 0% schema description coverage. The description adds full meaning: range (1-90), example (14 for 14 days), and purpose (retrospective collection days). This fully compensates 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 requests the background daemon to retroactively collect older data. It uses specific verb and resource, and distinguishes from siblings like telegram_dismiss_backfill and telegram_status.
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 explicitly states it should only be called with user consent due to heavy operation, and references backfill_offer from telegram_status for context. It lacks explicit exclusion of alternatives but provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It mentions query matching behavior (AND, space-separated), default values for hours, limit, and channel, but does not discuss result ordering, pagination, case sensitivity, or rate limits. This is adequate but leaves some gaps.
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, front-loaded with purpose, and structured with clear sections (purpose, matching details, parameter list). Every sentence adds value, and there is no repetition or fluff.
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 4 parameters, 1 required, and the existence of an output schema, the description covers the core behavior and all parameters thoroughly. It provides enough context for an agent to invoke the tool correctly without needing additional clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: query (keywords, AND match), hours (time range, default 72), limit (max results, default 30), channel (username without @, omit for all). This adds critical meaning beyond the bare schema.
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 does full-text search of original messages by keyword/topic, and explicitly distinguishes from sibling tools by noting it can find posts without stock codes (e.g., macro/industry/theme). The verb '전문검색' and phrase '내용 축 도구' make purpose specific and differentiated.
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 explains when to use (keyword searching for content, including without stock codes) and provides matching behavior (space-separated AND match, 3+ chars for speed). It does not explicitly mention when not to use, but the context is clear enough to guide selection among siblings.
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?
With no annotations provided, the description carries full burden. It discloses the key behavioral aspects: it returns status, last_error.code, and recovery instructions, and implies a read-only, non-mutating operation. It also explains how to act on the results, adding value beyond a simple status check.
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, front-loaded with the core purpose and followed by practical interpretation guidance. Every sentence earns its place, with no redundancy or filler.
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 nature of the tool (no parameters) and the presence of an output schema, the description sufficiently covers usage context and response interpretation. It could be slightly more explicit about when this tool should be used over others, but overall it is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed; instead, it clarifies the output semantics, which is appropriate since there are no inputs to explain.
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 returns login/collection status and background daemon status, using a specific verb (returns) and resource. This distinguishes it from sibling tools, which focus on data collection, search, and analytics rather than system health.
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 guidance on when to use the tool (to check health status) and what to do with the response (guide user to recovery commands if status is degraded or failed). It lacks explicit exclusions or alternative tools, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It lists returned fields (first mention channel, etc.) but does not disclose error handling, prerequisite data existence, or any limitations beyond input scope.
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?
Concise three-part structure: purpose, output summary, usage note, then parameter list. No wasted words; front-loaded with key purpose.
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?
Covers all parameters and usage context. Has output schema (context signal), so description's mention of return fields adds but isn't essential. Missing prerequisites like stock code validity, but still complete enough for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description adds value. It explains query as '종목명 또는 6자리 종목코드', hours as '윈도우(시간)' with default, and bucket_minutes as '시간 버킷 크기(분)' with default, supplementing the schema.
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 returns the buzz timeline for a specific stock, using a specific verb '반환합니다' (returns) and resource '버즈 전개(타임라인)'. It distinguishes from sibling telegram_search by specifying this is for stock code matching only.
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?
Explicitly says when to use (stock code matching) and when not to (macro/geopolitical/theme questions), directing the agent to telegram_search for other queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It describes the computation (independent mention, tier, spread, velocity) and filters but does not explicitly state whether the call is read-only or has side effects. The context implies a read operation, but a more explicit statement would improve transparency.
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 well-structured: a one-line definition, a usage note, then an organized list of parameters. Every sentence adds value, and there is no redundancy or unnecessary text.
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 that an output schema exists (context indicates it has output schema), the description does not need to explain return values. It covers purpose, usage, and all parameters. However, it could mention that the output is a list of stocks with scores, but the output schema likely covers this, so a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain all 6 parameters. The Args section provides clear, concise explanations for each parameter (window_hours, only_types, exclude_gossip, sentiment, top, kind), adding meaning beyond the schema's default values and types.
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 computes a buzz score per stock using independent mentions, tier, spread, and velocity, and explicitly distinguishes itself from telegram_search for macro/geopolitical/theme queries. The verb '종목별 종합 버즈 스코어' specifies the action and resource.
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?
The description explicitly states it is for stock code matching and directs macro/geopolitical/theme questions to telegram_search, providing clear when-to-use and when-not-to-use guidance with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the tool as returning data (read-only implied), but does not explicitly state non-destructive behavior or other traits like pagination, data freshness, or rate limits. For a simple query tool this is adequate but minimal.
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: three sentences for purpose and usage, followed by a structured list of parameters. No filler; every sentence adds value. Front-loaded with core purpose.
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 the tool's simplicity and the presence of an output schema, the description covers all necessary aspects: purpose, scope, parameter details, and a clear alternative for sibling tool. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds complete parameter semantics: hours (time range), top (count), kind (with enum values stock/etf/all). All defaults are listed, and the meaning of each parameter is clearly explained.
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 returns top stocks by Telegram mention volume within a period (specific verb+resource). It distinguishes itself from the sibling telegram_search by noting it is 'exclusive for stock code matching' and contrasts with macro/thematic questions.
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?
Explicitly states when to use the tool ('stock code matching') and when not to (macro/thematic questions using telegram_search). Also provides parameter defaults and explanations, giving concrete usage context.
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?
No annotations provided, so description conveys the tool's behavior well: returns mentions and summaries, not technical data. Could mention data freshness or permissions, but sufficient.
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?
Concise and well-structured: purpose first, then usage guidance, exclusions, alternatives, and parameter. No unnecessary 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?
Covers purpose, usage, and parameter. With output schema existing, it is fairly complete, though could elaborate on output content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description includes parameter explanation: 'hours: 집계 시간 범위(시간). 기본 24.' Adds value beyond empty schema.
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 returns how watched stocks are discussed on Telegram, with original texts and summaries. It differentiates from sibling tools by specifying it does not provide technical indicators, only Telegram mentions.
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?
Explicitly mentions when to call (e.g., for opinions, news, 'how is it' requests) and when not to (technical indicators). Directs to StockLens for indicators and notes stock registration via Telegram commands.
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?
No annotations provided, so description bears full burden. It explains the tool scans for mismatched tokens, implies read-only behavior, but could clarify it scans Telegram messages. The follow-up action is stated.
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, front-loaded with purpose, includes a usage instruction, and has no wasted words.
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?
The tool has three parameters, all explained; it has an output schema; the description covers what the output represents and precision, and links to a sibling tool. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description lists all three parameters with defaults and explains their role (analysis period, minimum count, top N), adding meaning beyond the schema.
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 returns missing alias candidates for a specific pattern (`이름(123456)`), distinguishing it from siblings like `telegram_add_alias`.
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?
The description explicitly says to review candidates and register them via `telegram_add_alias`, providing clear when-to-use and an alternative tool.
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?
No annotations provided, so description carries full burden. It discloses: receiver fixed (self), uses collection daemon, auto-splits messages over 4096 chars, returns success count, error if daemon not running. It also advises against multiple calls and to check for typos.
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?
Description is well-structured with bullet points and emphasis, but it is somewhat lengthy. It could be more concise while retaining all information. However, it remains clear and organized.
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?
Output schema exists but not provided; description mentions return value (success + count). For a simple tool, this is mostly complete. However, some details like exact return format or error types could be added.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 1 param with 0% coverage, so description fully compensates. It explains each element is a plain-text message, provides formatting rules, and gives an example. This adds complete meaning beyond the schema.
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 sends messages to the user's own Telegram Saved Messages. The verb 'send' and resource 'Saved Messages' are explicit. It distinguishes from sibling tools, which are mostly data retrieval or management, not sending.
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?
The description provides explicit when-to-use context: for scheduled briefings like '아침 주식 비서'. It warns against resending or correcting after sending, and specifies plain text only. It implies alternatives (other tools don't send to self).
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?
No annotations exist, so the description fully covers behavior: it checks daemon status, skips sync if daemon is active (reports DB freshness), and performs collection only when daemon is not running. Also notes session conflict issues. This is comprehensive for a potentially destructive operation.
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?
Well-organized with purpose, usage context, and parameter details. However, it includes mixed Korean and English which may reduce clarity for non-Korean agents. Still, each sentence adds value.
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 the presence of an output schema (not shown but indicated as true) and two parameters with defaults, the description covers all necessary information: purpose, prerequisites (daemon status), parameter semantics, and invocation behavior. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description provides clear parameter explanations in the Args section: 'minutes: 수집 대상 시간 범위(분). 기본 60.' and 'per_channel_limit: 채널당 최대 조회 메시지 수. 기본 500.' This adds meaning beyond schema defaults.
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: '최근 N분간의 텔레그램 메시지를 수집·구조화해 로컬 DB에 저장합니다.' This translates to collecting, structuring, and storing recent Telegram messages, which distinguishes it from sibling tools like telegram_messages (retrieval) or telegram_send_me (sending).
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?
Explicitly explains when to use ('데몬이 없을 때만 직접 1회 수집합니다' - only collect directly when daemon is absent) and when not to ('평소엔 백그라운드 수집 데몬이 DB를 채우므로 수동 호출은 보통 불필요합니다' - manual call usually unnecessary). Also mentions daemon behavior and potential conflicts.
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:

[![telegramlens-mcp MCP server](https://glama.ai/mcp/servers/Johnhyeon/telegramlens-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Johnhyeon/telegramlens-mcp)

Score Badge

Copy to your README.md:

[![telegramlens-mcp MCP server](https://glama.ai/mcp/servers/Johnhyeon/telegramlens-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Johnhyeon/telegramlens-mcp)

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/Johnhyeon/telegramlens-mcp'

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