Summarize Telegram chatter for any stock ticker or name, returning key mention insights along with original message samples over a configurable time window.
특정 종목의 텔레그램 언급 요약과 원문 샘플을 반환합니다.
Args: query: 종목명 또는 6자리 종목코드. hours: 집계 시간 범위(시간). 기본 24. samples: 원문 샘플 개수. 기본 8.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| query | Yes | ||
| samples | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.7.0Input schema / properties / hours / defaultRemoved value: -24Input schema / properties / samples / defaultRemoved value: -8v0.4.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns an aggregate summary plus raw samples and that the time window and sample count are configurable, which is useful, but it does not disclose other behaviors such as data coverage limits or no-data handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose statement followed by a tight Args block. It is front-loaded with the core function, and every line carries relevant information without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only three flat parameters and an output schema, the description covers the input semantics and returned content well. It lacks comparative context for choosing among siblings, but that gap is already captured by the usage_guidelines dimension; operationally an agent has enough to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter meaning, and it does so completely. It explains that query is a stock name or 6-digit code, hours is the aggregation time window (default 24), and samples is the number of raw samples (default 8). All three parameters are defined with defaults, fully compensating for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb 'returns' (반환합니다) and a specific resource: a summary of Telegram mentions and original-text samples for a specific stock. The '특정 종목' qualifier suggests per-stock scoping that distinguishes it from broader siblings like telegram_trending, though no alternative is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many sibling telegram_* tools. There is no mention of use cases, exclusions, or alternatives such as telegram_buzz_score, telegram_trending, or telegram_momentum. The agent is left to infer the appropriate context from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.