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

The description adds one behavioral fact ('즉시 반영됩니다' - takes effect immediately) and confirms mutation, which aligns with readOnlyHint=false. However, it does not disclose what happens on duplicate aliases, whether an existing alias is overwritten, or any other side effects, so it provides only minimal value beyond annotations.

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 main statement is one efficient line, the immediate-effect note is a single short sentence, and the two parameters are listed in a clean format. No redundant words or restatements of the schema.

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?

For a simple two-parameter registration tool, the description covers purpose, parameter meaning with examples, and an important behavioral note. Since an output schema exists, return-value details are not needed. The only missing piece is usage guidance relative to the many sibling tools, which is a minor gap.

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?

With 0% schema description coverage, the description fully compensates by defining alias as a Telegram term/abbreviation and code as a 6-digit stock code, and by providing realistic examples (현대차, 005380). This is exactly the format and meaning information missing from the 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 clearly specifies the verb '등록합니다' (register) and the resource (a dictionary mapping common terms/abbreviations to 6-digit codes), with concrete examples. It is unambiguous, but it does not explicitly differentiate this from related siblings such as telegram_alias_candidates or telegram_block_name, so it stops short of a top score.

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?

There is no when-to-use or when-not-to-use guidance, and no mention of alternatives among the sibling tools. The intent is implied by the name and purpose, but the description leaves the choice between adding, blocking, or suggesting aliases entirely to the agent.

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

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

The annotations already cover readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds behavioral context beyond those by explaining exactly what kind of tokens appear in the results and why they are considered high-precision ('코드가 정답을 알려주므로 고정밀'). This provides useful transparency beyond the structured hints.

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 summary, a brief definition of the candidate pattern, a usage instruction, and a clean Args list. Every sentence earns its place and the main purpose is front-loaded.

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?

The tool is simple, has an output schema so return-value details are covered, and the description includes all parameter meanings and defaults plus the intended next action. No critical operational context is missing.

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?

Input schema has 0% description coverage, so the description carries the full burden. It fully compensates by explaining each parameter in Korean with its meaning and default value: days (분석 기간, default 7), min_count (최소 등장 횟수, default 2), and top (상위 N개, default 40).

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 clearly states the tool returns missing alias candidates and defines the exact inclusion criterion (text matching `이름(123456)` that the current dictionary fails to map). This is a specific verb+resource with enough detail to distinguish it from sibling tools like telegram_add_alias, which it identifies as the follow-up registration tool.

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?

The description gives clear context: it returns high-precision candidates for manual review and explicitly instructs the agent to register them via telegram_add_alias afterwards. It does not explicitly state when not to use this tool versus other sibling candidates tools like telegram_fp_candidates, but the usage chain is clear.

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

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

Beyond the sparse annotations, the description discloses that real application modifies the block list, dry_run makes no changes, and the dry-run removal count exactly matches actual removal. It also specifies the exact matching policy (Korean names require a code in the body; US names require a cashtag), which is important behavioral context. No contradiction 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: purpose sentence, bold matching-policy block, dry-run workflow, and a compact Args section. Each sentence earns its place and the most important behavioral constraint is front-loaded.

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?

For a 3-parameter tool with an output schema available, the description covers input formats, matching conditions, dry-run semantics, count consistency, and post-run verification steps. Nothing an agent needs to call it correctly or confirm the result is missing.

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 full responsibility for parameters, and it succeeds. code gets format and examples, note gets a concrete example, and dry_run gets its default and preview behavior. This adds meaning far beyond the bare schema properties.

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?

States a specific action: '종목을 차단 목록에 추가합니다' – adding a stock to the block list – and clarifies scope with Korean 6-digit codes vs US tickers. The matching rules make the tool's purpose distinct from generic search or alias tools, so an agent can tell what it does.

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?

The description gives clear operating guidance: dry_run previews the count and samples, and after applying the block the agent should rerun telegram_trending / telegram_fp_candidates. However, it never explicitly contrasts this with siblings like telegram_add_alias or states when blocking should be chosen over alternatives, so the selection guidance is implied rather than direct.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description doesn't need to repeat that. It adds behavioral context by stating the tool returns aggregated data and instructs the agent to then send via telegram_send_me, and notes the 'only once' constraint. It also explains the hours parameter's meaning. This goes beyond the annotations without contradicting them.

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 a bit long but well-organized: trigger phrases are front-loaded, then the return data categories, then the send instruction, and finally the parameter explanation. Bullet points aid readability. No redundant fluff, though it could be tightened slightly.

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?

For a tool with one optional parameter and an output schema (which presumably documents the return structure), the description provides sufficient context: what it returns, how to use the output (via _playbook), and the recommended hours value. It doesn't detail the output format, but that's covered by the schema and _playbook, so completeness is high.

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?

The only parameter, hours, is explained in detail: it's the aggregation time range, with a recommended value of 12 for pre-market (overnight~morning) and a default of 12. The schema only defines it as a number, so this description fully compensates for the 0% schema coverage.

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 clearly states the tool's function: it aggregates Telegram mention data for market briefing, listing two specific data categories (trending and momentum). It also differentiates from sibling tools like telegram_trending and telegram_momentum by positioning itself as a combined briefing tool ('한 번에 모아'). The trigger phrases make the purpose immediately clear.

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?

The description explicitly lists the request phrases that should trigger this tool (e.g., '오늘 브리핑', '장전', '시황'). It also gives post-call guidance: use the returned _playbook to compose a plain-text message and send it exactly once via telegram_send_me. This is unambiguous usage direction.

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

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.

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.

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.

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.

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.

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.

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 well covered. The description adds useful context about what data is returned, though it does not mention pagination, ordering, or whether the list is exhaustive.

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 a single, efficient sentence that communicates the resource and the returned attributes without extraneous detail. It is front-loaded with the main action and resource.

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?

With zero parameters, rich safety annotations, and an output schema provided, the description is complete for the agent to select and invoke this tool. There is no missing operational information needed for a parameterless read-only list.

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?

The tool has zero parameters, so the description cannot add parameter-level meaning. However, it does usefully enumerate the returned fields, which helps the agent understand the tool's output even though an output schema exists.

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 states a specific verb ('returns'), a clear resource ('collected channel list'), and the key attributes included (cumulative message count, tier, weight). This clearly distinguishes it from siblings that classify or mutate channels, making the tool's purpose immediately identifiable.

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 explicit guidance is given on when to prefer this tool over siblings such as telegram_classify_channels or telegram_set_tier. The description implies a read-only channel overview use case, but it does not state exclusions or alternatives.

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

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

Adds value beyond annotations by disclosing unbounded scope (all channels auto-included) and slowness, consistent with openWorldHint=true. However, readOnlyHint=false hints at possible side effects, and the description never clarifies what, if anything, gets written or modified — a meaningful gap for a diagnostic tool that should be safe to run.

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?

Core purpose is front-loaded, followed by diagnostic context, usage caveat, then Args. Slightly redundant — the diagnostic purpose is restated in two adjacent sentences — but overall efficient and well-ordered with no wasted 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 the output schema covers return values, the description handles purpose, scope, performance, and all three parameters adequately. Remaining gaps are the unclarified read/write behavior and lack of explicit sibling routing, but 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description carries full parameter documentation: sample (count per channel, default 80), threshold (0~1 density, default 0.05), min_mentions (cumulative count, default 3). It adds meaning well beyond the bare integer/number types and includes defaults and a range.

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?

States a specific verb+resource+outcome: scans all joined channels and measures/reports 'stock mention density' per channel. The diagnostic purpose (distinguishing stock-focused vs macro/small-talk channels) clearly separates it from the many telegram_* siblings without opening any schema.

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?

Provides clear context on when to use it — as a diagnostic tool for channel composition — and a performance caveat ('scans all channels so it's slow, use only when needed'). However, it doesn't name alternative tools or explicitly state when NOT to use it, leaving some sibling differentiation to inference.

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

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

The annotations indicate this is not read-only, not idempotent, and not destructive, and the description adds useful behavioral context beyond these flags: it is a background daemon request, it is a heavy operation, and it requires user consent. This meaningfully informs the agent about side effects and caution needed.

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 concise and well-structured. It opens with the core purpose, then adds the critical usage condition (user consent) and the parameter explanation, with no wasted or redundant sentences.

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?

The description is sufficiently complete for a tool with a single parameter and an existing output schema. It covers the core operation, the important consent prerequisite, the parameter range, and an example. Minor details such as how the background daemon reports completion are not described, but the output schema likely covers return values.

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?

The input schema only provides the parameter name 'days' with no description, so schema description coverage is 0%. The description compensates well by explaining that days means the number of days to retroactively collect, providing a 1–90 range, and giving an example ('14면 최근 14일치'). This makes the parameter semantics clear.

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 clearly states the tool's function: asking a background daemon to retroactively collect older history data. It also distinguishes the tool by tying it to the backfill_offer state in telegram_status, making its purpose unambiguous among siblings.

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?

The description explicitly tells the agent when to call this tool: only when the user has been away longer than the default 7-day backfill and only with explicit user consent. It also explains when not to call it (without consent, due to heavy operation). It does not name alternative tools directly, but the usage conditions are clear.

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

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

The description adds a useful behavioral detail beyond the annotations by stating that the proposal flag is removed. However, it does not explain consequences, reversibility, or why repeated calls may differ (annotations set idempotentHint=false). It is adequate but not rich.

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 a single front-loaded sentence with no filler. Every word adds semantic value, and the core action and side effect are stated immediately.

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?

For a zero-parameter tool with an output schema and annotations present, the description covers the essential operation. It is slightly incomplete only in that it does not clarify when the dismissal should be used or what happens after the flag is removed.

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?

The input schema has zero properties and 100% schema description coverage, so there are no parameters for the description to document. The baseline for a zero-parameter tool applies, and no compensation is needed.

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 uses a specific verb ('거절합니다' – rejects), names the exact object (과거 데이터 추가 수집 제안, or past-data additional collection proposal), and explains the concrete mechanism (removes the proposal flag). It is immediately clear how this differs from sibling tools like telegram_collect_history.

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?

The description says only what the tool does, not when to use it versus alternatives. It names no sibling tools, no exclusions, and no conditions or prerequisites for dismissing a backfill proposal. The intended usage is only implicit in the verb 'reject'.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable context: it explains the heuristic (matches without confirmation markers), the role of confirmation markers, and market-specific behavior (e.g., US false positives from common words like AI, IR, HBM). No contradiction 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: purpose, criteria, confirmation marker definition, workflow, then parameter details. Each section earns its place and provides necessary context without redundancy. The front-loaded purpose and clear parameter list make it easy to scan.

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 an output schema exists, the description does not need to explain return values. It provides enough context to understand the algorithm, parameter behavior, and downstream action (blocking via telegram_block_name). The description is complete for a read-only analysis tool with annotations already covering safety.

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 must compensate, and it does thoroughly. Every parameter (days, max_name_len, min_count, top, market) is described with defaults and behavioral meaning, including the automatic length logic and market-specific explanations. This adds significant value beyond 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 states a clear purpose: returns false-positive candidates for stocks incorrectly detected by name/character alone. It explains what counts as a false positive (no confirmation marker, common noun/abbreviation conflicts) and even defines the confirmation markers for KR (6-digit code) and US (cashtag). This is specific and distinguishes it from downstream tools like telegram_block_name.

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?

The description implies usage: use this tool to identify false positives, then review and add to block list via telegram_block_name. It gives a clear workflow but does not explicitly state when to use this tool over sibling alternatives like telegram_alias_candidates or when not to use it. No exclusions or alternative selection criteria are provided.

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

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

Beyond the readOnly/idempotent/destructive annotations, the description discloses fetch latency, excerpt truncation to 2,000 characters, non-full-article behavior, DART special handling, and the referenced_by return semantics. This is rich behavioral context with no contradiction.

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, well-structured, and front-loaded with the core purpose. Each sentence adds distinct value: caching behavior, excerpt limit, DART exception, referenced_by semantics, and parameter meaning. No redundant content.

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 the read-only annotation, idempotence, and presence of an output schema, the description covers the operation fully. It explains return semantics, limits, latency, and exceptions without needing to restate schema fields. An agent has enough information to call 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?

The schema provides only a string type for url with zero description coverage. The description compensates by explaining that url should be the link address exactly as it appears in the post's links or link_content.url, which adds practical meaning. For a single parameter this is sufficient, though no validation or format guidance is included.

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 names a specific operation and resource: returning the title, description, and body excerpt of one link attached to a Telegram post. It also distinguishes itself by explicitly stating what it does not do (DART links) and directing to DartLens, which helps separate it from siblings.

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?

The description gives clear conditional context: cached links are returned immediately, pending or unseen links are fetched now. It also provides an explicit when-not and alternative: DART disclosure links are not read, and users should use DartLens instead.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds behavioral details: it returns original messages with link_content, and explains link_body parameter behavior (including character limit). It doesn't contradict annotations. Since annotations cover safety, description adds useful context about return structure and parameter behavior, but doesn't describe pagination or ordering. Score 3.

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?

Description is concise, front-loaded with purpose, then a note about link_content, then a clean Args list. No wasted words. Score 5.

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 4 parameters, 0 required, and an output schema, description covers all parameters with defaults and behavior. It doesn't mention ordering or pagination, but that's not necessary for calling correctly. It's sufficient for an agent to use correctly. Score 4.

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 description carries full burden. It explains each parameter: channel (with format and default behavior), hours (default 6), limit (default 30), link_body (meaning and default). This is explicit and complete. Score 5.

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?

Description states a specific verb (조회합니다 - retrieves) and resource (원문 메시지 - original messages), with a drill-down hint. It also mentions the link_content attachment, which distinguishes it from search or timeline tools. Clear purpose, though it doesn't explicitly name sibling alternatives.

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 explicit when-to-use guidance. It doesn't mention alternatives or exclusions. The description implies it's for viewing original messages, but doesn't state when to prefer it over telegram_search or telegram_timeline. Score 2.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful algorithmic context (baseline comparison, per-segment top N) but does not disclose return format, pagination, or data-freshness behavior.

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 definition is front-loaded with purpose, followed by a one-line scope/alternative statement, then a clean Args list. Every line is informative and there is no 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?

For a five-parameter tool with no schema-level descriptions, the description supplies all necessary invocation details: defaults, allowed values, and the four kind/market branches. The presence of an output schema means return-value format need not be repeated.

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%, but the Args section fully documents all five parameters with defaults, allowed values, and the kind/market combination semantics. This completely compensates 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 precise definition: it returns stocks whose recent mentions surged relative to a baseline period, labeled as 'new narrative'. It also declares the tool is for stock-code matching only and explicitly routes macro/geopolitical/theme questions to telegram_search, distinguishing it from a sibling.

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?

The description gives an explicit when/when-not pair with an alternative: use it for stock-code matching, and use telegram_search for macro/geopolitical/theme queries. This leaves no ambiguity about the primary intended use case.

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

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

Beyond readOnly/idempotent annotations, it discloses meaningful behavior: multi-word AND matching, the 3-character performance note, searching through attached link titles/descriptions/excerpts, and the matched_in result field distinguishing 'text' from 'link'. This gives the agent useful expectations about search scope and result semantics.

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 dense but well-organized: a clear lead sentence, brief behavioral notes, and a compact parameter list. Every line adds operational value, with no filler or repetition of annotation facts.

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?

For a 6-parameter search tool with zero schema descriptions, this is complete: it covers scope, matching semantics, link handling, defaults, and result-field hints. The output schema supplies return structure, so the description does not need to repeat it.

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 coverage is 0%, but the Arg list fully compensates by explaining all six parameters: query keywords, hours range with default 72, limit with default 30, channel restriction with @ exclusion, in_links behavior, and link_body excerpt inclusion. This adds substantial meaning beyond the bare schema titles.

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 specific verb and resource: '원문 메시지를 키워드/주제로 전문검색합니다' (full-text search of original messages by keyword/topic). It also positions itself as the '내용' (content) axis tool, distinguishing it from siblings that focus on velocity, momentum, or channel metadata.

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?

The description gives clear context on when to use this tool: for searching message content and link bodies, including macro/industry/theme posts without stock codes. It does not explicitly name alternatives or state when not to use it, but the 'content axis' framing and search-oriented behavior provide solid usage direction.

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

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

Beyond the annotations, the description discloses recipient fixed to self, daemon dependency and error behavior, no markdown/HTML rendering, 4096-character auto-splitting, and the duplicate-message risk. This gives the agent essential behavioral context for a non-idempotent send action, and it does not contradict the annotation flags.

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 front-loaded with the core action and organized into clear bullets and starred warnings. It is somewhat long and has minor repetition between the general introduction and the '아침 주식 비서' usage example, but every block contributes useful operational or safety information.

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?

For a single-parameter send tool, the description covers the message content, recipient, transmission mechanism, failure mode, length limits, return value, and content-safety rules. Nothing essential is missing for an agent to invoke it 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?

With 0% schema description coverage, the description fully documents the only parameter: messages is a plain-text string list where each element becomes one Telegram message. It also explains plain-text formatting, auto-splitting behavior, and provides a realistic example call, making invocation unambiguous.

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 opening sentence uses a specific verb (전송합니다) and a precise destination (user's own Telegram 'Saved Messages'), clearly identifying this as a send-to-self tool. This distinguishes it from the many read/search/classify sibling tools, and the example call reinforces the intended action.

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?

The description places the tool in a concrete workflow: write a briefing in a scheduled task, then send it once. It adds strong operational rules such as 'call only once' and 'never resend or correct after sending.' It does not explicitly name alternative tools or exclusion 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.

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

Annotations already indicate a mutating, non-idempotent operation, and the description adds meaningful behavioral detail: it overwrites the auto-seeded tier, the manual tier survives future re-seeds, and tier is the basis for buzz aggregation weights. This is useful context beyond the structured flags.

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: purpose, persistence behavior, and weighting impact come first, followed by a clean Args list. Every sentence earns its place and nothing is redundant.

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?

The definition covers purpose, side effects, and all parameter semantics, and an output schema exists so return values do not need explanation. The only meaningful gap is explicit when-to-use guidance relative to the large sibling set, which makes it very strong but not fully complete.

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%, but the description fully compensates by explaining each parameter: channel format (username without @ or non-6-digit numeric ID), allowed tier values with labels, default weight per tier, and optional note. An agent could construct correct arguments from this alone.

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 uses a specific verb and resource ('채널 tier(성격)를 수동 지정합니다') and explains that it overrides the automatic seed. This distinguishes it from automatic-classification siblings such as telegram_classify_channels, even though no sibling 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?

The manual-override context is clear ('수동 지정', '자동시드를 덮어쓰며'), so an agent can infer when it is relevant. However, it never explicitly states when to prefer this tool over automatic classification or other siblings, and no direct alternatives or exclusions are given.

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

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

Annotations already establish a safe read-only, idempotent operation. The description adds meaningful context beyond that: it explains health triage behavior, requires passing recovery.instruction through unchanged, and forbids terminal-command guidance. No contradictions exist.

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?

Four short, purposeful sentences in Korean. The main purpose is front-loaded, followed by concrete triage rules and an explicit boundary. Every sentence earns its place with no redundant restatement of the schema.

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?

For a zero-parameter, read-only status tool with an output schema, the description is complete. It covers purpose, expected status values, user-facing actions, and a clear prohibition. Nothing essential is missing.

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?

There are zero parameters and 100% schema coverage, so the description has no parameters to document. The baseline for param-less tools is 4, and the description correctly focuses on output semantics and user handling instead.

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 states a clear verb and resource: it returns login/collection status and background daemon status. It also names the meaningful fields (status, last_error.code, recovery.instruction), which distinguishes it from sibling tools that send, sync, or search data.

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?

The intended use is evident: check this tool for login/collection/daemon health. It gives strong post-invocation guidance – surface recovery.instruction verbatim, direct users to LeetKit Manager diagnostics/support, and never provide terminal commands – but it does not explicitly name alternatives or when-not-to-use conditions.

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

Does 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.

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

Annotations (readOnlyHint=false) already signal a write operation; the description confirms and enriches this by disclosing the session-ownership conflict with the daemon and the write-to-DB behavior. This adds behavioral context beyond the annotations without contradicting them.

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?

Purpose is front-loaded in the first sentence, followed by relevant guidance and an Args block. Every sentence earns its place, though the daemon situation is spread across several sentences that could be tightened slightly.

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?

Complete for a moderate-complexity sync tool: it explains the daemon interaction, documents both params, and relies on the existing output schema for return values. No critical gaps for correct invocation, though permissions/auth are not mentioned.

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 — and it delivers. Both parameters are documented with meaning, units (minutes, count), and defaults (60, 500), 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?

States a specific verb and resource: collect/structure Telegram messages over the last N minutes and persist them to a local DB. The purpose is unambiguous, but it doesn't differentiate from overlapping siblings like telegram_collect_history or telegram_messages — the description never names a sibling it is not.

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?

Exceptionally explicit. It gives the when (no daemon running), the when-not (daemon active), the why (session ownership conflict), and the fallback behavior (skip sync, report DB freshness only). This is the strongest part of the definition.

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

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.

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.

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.

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.

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.

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.

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

The description reveals non-obvious behaviors beyond what annotations provide: the four-way segment split when kind and market are both 'all', the result structure containing `segments`, `market`, and `segment`, and the buzz_score bias toward large caps like Samsung Electronics and SK Hynix. It also exposes the min_independent default of 3 and why it exists to prevent one-off mentions from dominating baseline_ratio ranking. These behavioral details are crucial for correct invocation.

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 purpose is front-loaded in the first sentence, followed immediately by a routing rule to a sibling. The Args section is a clean bulleted list with defaults, allowed values, and inline warnings that add context without redundant text. Every paragraph serves a distinct purpose: behavior explanation, ranking-pitfall warning, or parameter semantics.

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?

The description covers purpose, usage boundary, parameter semantics, default behaviors, output structure, and a sibling alternative. It also warns about ranking pitfalls so the agent can choose the correct sort_by. With read-only annotations and an output schema present, nothing essential for correct invocation is left undocumented.

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?

The schema has 0% description coverage)Skip over the schema. The description documents all schema-listed parameters (hours, top, kind, market) with defaults, allowed values, combinations, and interactions, and even documents sort_by and min_independent, which are absent from the schema. This far exceeds compensation for the schema's silence.

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 states the exact function: '기간 내 텔레그램 언급량 상위 종목을 반환합니다' (returns top stocks by Telegram mention volume within a period), with a clear verb and resource. It also explicitly differentiates itself by saying '종목코드 매칭 전용' and pointing non-stock queries to telegram_search. This fully distinguishes it from siblings.

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?

It explicitly says this tool is for stock code matching only, and tells the agent to use telegram_search for macro/geopolitical/theme questions. It also provides decision guidance inside the tool via sort_by, recommending baseline_ratio when the agent's intent is to find '새로 관심이 붙는 종목' (newly gaining attention). This is explicit when/when-not 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.

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

Annotations already mark the tool read-only and idempotent, and the description adds meaningful behavior beyond that: it aggregates independent mentions per time bucket, computes increase versus the previous bucket, flags spikes, and includes baseline_ratio. This gives an agent a solid sense of what the tool does internally.

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-organized: purpose statement first, then computation summary, then a clear Args list. Every sentence adds value and there is no repetition of schema or annotation fields.

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 the rich annotations, an output schema, and five optional parameters, the description covers the tool's core behavior, parameters, defaults, and output concepts like baseline_ratio. Nothing critical is missing for an agent to invoke it 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?

Input schema has 0% description coverage, but the description fully compensates by documenting all five parameters with meaning and defaults. Each parameter's role is explained, including the conditional behavior of query and top.

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 clearly states a specific verb and resource: it returns time-bucket flows and velocity of per-stock Telegram mentions, with increase rates and spike flags. It does not explicitly differentiate from siblings like telegram_momentum or telegram_trending, but the velocity/spike focus is reasonably distinct.

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?

The description provides parameter-level defaults and behavior (e.g., query omitted returns top velocity stocks), but gives no guidance on when to choose this tool over sibling tools such as momentum, trending, or buzz_score. No exclusions or alternate conditions are mentioned.

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

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

The description explains what data is returned (mentions, original text, channels, links) and its purpose in summarizing sentiment, but does not detail performance limits or data freshness. Annotations already indicate it's not destructive and is open-world, but the description adds relevant context.

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 appropriately concise, with the core purpose front-loaded. The additional notes on usage and alternatives are valuable, but slightly verbose in the middle section.

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?

For a tool with one optional parameter and a rich context of siblings, the description covers the main usage and output expectations, making it sufficiently complete for effective selection and invocation.

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?

The schema covers 0% for the single parameter 'hours', but the description provides basic semantics by stating it is the aggregation time range in hours with a default of 24. This is sufficient, though minimal.

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 clearly states the tool returns mentions of the user's stocks on Telegram, including original text and summary rationale. It distinguishes itself from technical indicators and other analytical tools.

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?

It explicitly specifies when to call (requests about Telegram mentions, sentiment, etc.) and when not to (technical indicators, charts, moving averages). It also names alternatives like StockLens for technical analysis and mentions the command for registration/deletion.

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