TelegramLens

Overview Schema Source Related Servers Discussions Admin

telegram_buzz_score

Read-onlyIdempotent

Aggregates Telegram mentions into a buzz score per stock/ETF using tier, diffusion, and velocity. Supports filtering by market, sentiment, and message type to reveal trending securities.

Instructions

종목별 종합 버즈 스코어(독립언급×tier×확산×velocity). 감성·유형 필터 지원.

종목코드 매칭 전용 — 거시·지정학·테마(예: "미국 이란", "금리") 질문은 telegram_search 사용.

Args: window_hours: 집계 윈도우(시간). 기본 24. only_types: 포함할 메시지 유형(예: ["report"]). 생략 시 전체. exclude_gossip: only_types 미지정 시 gossip 제외. 기본 False. sentiment: positive/negative/neutral 중 하나만. 생략 시 전체. top: 상위 N개(세그먼트별). 기본 20. kind: 종목 종류 — "stock"(개별주만)/"etf"(ETF만)/"all"(전체). 기본 all. market: 시장 — "KR"(국내만)/"US"(미국만)/"all"(전체). 기본 all. kind 와 조합해 국내주식·미국주식·국내ETF·미국ETF 네 갈래로 나뉩니다.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`top`	No
`kind`	No
`market`	No
`sort_by`	No
`sentiment`	No
`only_types`	No
`window_hours`	No
`exclude_gossip`	No
`min_independent`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedv0.7.0Sep 19, 2026
- removedInput schema / properties / exclude_gossip / default
```
Removed value: -false
```
- removedInput schema / properties / kind / default
```
Removed value: -"all"
```
- removedInput schema / properties / market / default
```
Removed value: -"all"
```
- removedInput schema / properties / min_independent / default
```
Removed value: -0
```
- removedInput schema / properties / only_types / anyOf
```
Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / only_types / default
```
Removed value: -null
```
- addedInput schema / properties / only_types / items
```
Added value: +{
+  "type": "string"
+}
```
- addedInput schema / properties / only_types / type
```
Added value: +"array"
```
- removedInput schema / properties / sentiment / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / sentiment / default
```
Removed value: -null
```
- addedInput schema / properties / sentiment / type
```
Added value: +"string"
```
- removedInput schema / properties / sort_by / default
```
Removed value: -"buzz_score"
```
- removedInput schema / properties / top / default
```
Removed value: -20
```
- removedInput schema / properties / window_hours / default
```
Removed value: -24
```

Changed3 schema fields changedv0.6.1Sep 12, 2026

addedInput schema / properties / market

Added value: +{
+  "default": "all",
+  "title": "Market",
+  "type": "string"
+}

addedInput schema / properties / min_independent

Added value: +{
+  "default": 0,
+  "title": "Min Independent",
+  "type": "integer"
+}

addedInput schema / properties / sort_by

Added value: +{
+  "default": "buzz_score",
+  "title": "Sort By",
+  "type": "string"
+}

First observedv0.4.3Jul 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so no contradiction exists. The description adds valuable behavioral context: conditional gossip exclusion, segmentation by kind/market into four branches, per-segment top-N behavior, and default values for window_hours, top, kind, and market.

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, front-loaded with the core formula, then states the critical usage boundary, then lists parameters in a scannable format. Every sentence contributes meaningful guidance; nothing is 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?

For a tool with 9 optional parameters, this description covers the main invocation path very well, including defaults, filter behavior, and segmentation logic. The output schema supplies return structure, and annotations cover safety. The only meaningful omission is the lack of any explanation for sort_by and min_independent, which prevents it from being fully self-sufficient.

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 carries the parameter documentation burden. It explains 7 of 9 parameters with defaults and allowed values, notably kind, market, sentiment, and exclude_gossip. However, sort_by and min_independent are entirely undocumented, leaving a real gap for an agent trying to use those advanced options.

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 and resource: it computes a per-ticker composite buzz score based on an explicit formula ('독립언급×tier×확산×velocity'). It also scopes the tool firmly to ticker matching, which separates it from generic search and other siblings.

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 when NOT to use it: macro/geopolitical/theme queries such as '미국 이란' or '금리' should go to telegram_search. This gives a clear alternative and usage boundary, which is exactly the kind of guidance agents need.

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