Skip to main content
Glama
Johnhyeon

TelegramLens

by Johnhyeon

telegram_timeline

Read-onlyIdempotent

Track a stock's buzz timeline: identify first mention, channel spread, and velocity over time. Use for specific stock names/codes to analyze how narratives propagate.

Instructions

특정 종목의 버즈 전개(타임라인)를 반환합니다.

이 종목이 언제 어느 채널에서 처음 터져 어떻게 번졌나(종단): 최초 언급 채널·시각, 시간대별 독립 언급·확산 채널 수·velocity·베이스라인 배율·원문 샘플.

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

Args: query: 종목명 또는 6자리 종목코드. hours: 윈도우(시간). 기본 72. bucket_minutes: 시간 버킷 크기(분). 기본 60.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hoursNo
queryYes
bucket_minutesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.7.0
    • removedInput schema / properties / bucket_minutes / default
      Removed value: -60
    • removedInput schema / properties / hours / default
      Removed value: -72
  2. First observedv0.4.3

TDQS

A4.8/5.0
Behavior4/5

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

Annotations already provide readOnly/openWorld/idempotent hints, so the bar is lower. The description adds useful context about the returned timeline content (first mention channel/time, velocity, baseline multiplier) and scope (stock code matching only), but doesn't discuss error behavior or rate limits, which are not critical given 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 front-loaded with the main verb and resource, then details, then usage guidance, then parameter definitions. No filler 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?

With a 3-parameter tool and an output schema present, the description covers input semantics, defaults, scope, and usage boundaries. The existence of the output schema means return-value details are handled externally. Nothing an agent needs to call it correctly is missing.

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 compensate. It defines all three parameters: query (stock name or 6-digit code), hours (default 72), bucket_minutes (default 60). This is essential meaning the schema lacks.

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?

States a specific verb and resource: 'returns the buzz development (timeline) of a specific stock.' It further lists the data points (first mention channel/time, independent mentions, velocity, etc.) and distinguishes from sibling telegram_search by explicitly excluding macro/geopolitical/theme queries.

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 'Exclusively for stock code matching' and directs non-stock queries to telegram_search with examples ('미국 이란', '금리'). This is clear when-to-use and 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.