Statiko — Telegram trends & channel analytics

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description usefully characterizes the returned payload (channel profile with metrics vs. trending story with context and sample posts), but adds nothing on failure modes or id-invalid 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?

A single front-loaded sentence with zero filler: verb, resource, and the two outcome variants. Every clause earns its place.

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 an output schema present, annotations covering safety, and the sole parameter documented at 100% coverage, the description supplies the remaining orientation an agent needs. It could still note what happens with an unknown or expired id, but 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?

Schema description coverage is 100% and the single id parameter is fully documented in the schema with its two id formats. The description adds nothing about the parameter beyond restating that it comes from a search, so baseline 3 applies.

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 (Fetch) and resource (the full document behind a search result id), then enumerates the two document shapes so the agent knows what comes back. It does not name a sibling such as search, though 'search result id' implicitly ties it to the search flow.

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 phrase 'behind a search result id' implies this is the follow-up call after a search, which is useful context. However, no explicit when-to-use, when-not-to-use, or named alternative is given, so routing must be inferred.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: newest-first ordering, album collapsing to a single row, and the resulting effect that a page may contain fewer than `limit` posts.

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?

Two dense sentences, front-loaded with what the tool returns and followed by the accepted inputs and the album/limit caveat. No filler sentences, though the return-field enumeration is somewhat long given an output schema exists.

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 six parameters, only one required, an output schema present and a read-only annotation set, the description covers inputs, ordering, and the one surprising edge case (album collapse shortening pages). It is essentially complete for calling the tool; only the sibling-routing guidance is absent.

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 83%, so the schema already documents channel, query, since, until and message_type in detail. The description adds only the collapsed-album caveat around `limit` and a loose restatement of channel/query/time-range, so it does not materially extend parameter meaning.

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 ('Recent posts from a tracked Telegram channel, newest first') and enumerates the returned metrics, which is far more than a restatement of the name. It does not explicitly contrast itself with close siblings such as get_channel_timeline or search, so sibling differentiation is left to inference.

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 lists the optional query and time-range filters, which implies how to narrow results, but never states when to prefer this tool over get_channel_timeline or search, nor any exclusion criteria. Usage is implied rather than directed.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral detail beyond them: the 10-channel cap, the 30-day window for comparison changes, and the notable failure-tolerant behavior of listing unknown entries as unresolved rather than erroring.

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?

Two dense sentences, front-loaded with the single-channel case before the multi-channel case, with no filler. It is slightly heavy for a tool of this size but each clause carries information about mode or metrics.

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 an output schema present, the description need not explain return shapes, and it does not. It fully covers the input modes, the window semantics, the cap, and error handling, which is everything an agent needs 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?

Schema description coverage is 100%, so the schema already documents slug/id format, date patterns, and the 'single channel only' constraint on start/end dates. The description largely restates that the date range is optional and mode-dependent, adding little beyond the schema; baseline 3 applies.

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 pairing (retrieves a tracked Telegram channel's profile and metrics) and makes the mode-dependent behavior explicit. However, it never names a sibling tool such as search_channels or get_channel_posts, so an agent must infer routing from the sibling list alone.

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?

Gives clear context for the two modes: one channel for the full profile, several (up to 10) for compact comparison rows. It does not, though, state when to prefer this over siblings like get_channel_timeline or get_similar_channels; no 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered without the description's help. The description adds scope context (it covers structural/historical events) but says nothing about pagination depth, result ordering behavior beyond the schema default, or whether history is complete versus windowed. 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?

A single front-loaded sentence with the resource and its event scope stated first, and no filler. The enumerated list is somewhat long but each item maps to a real event category, so it largely earns its place.

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?

An output schema exists, so return-value explanation is not required, and annotations cover the safety profile. The description adequately conveys what domain of events the tool surfaces; only minor gaps remain around how event_types filtering interacts with the described categories.

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 60%, and the description never addresses channel, page, limit, or order. It does loosely translate several enum codes into plain English (renames, description/photo changes), which helps interpretation of event_types, but this is marginal since the enum literals are largely self-describing. Baseline 3 is appropriate.

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 verb (returns) and a precisely scoped resource (structural events in a channel's history), then enumerates the concrete event categories: renames, description/photo changes, verification flips, subscriber/view milestones, post edits/deletions. This distinguishes it from siblings like get_channel_posts (content) and get_post_stats (metrics) without ambiguity.

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 trailing clause 'for telling what happened on a given date' supplies an implied use case, but no explicit when-to-use, when-not-to-use, or named alternatives are given. It does not, for example, tell the agent to prefer this over get_channel_posts when the question is about channel-structure changes rather than post content.

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 the safe read-only profile, so the bar is lower, and the description adds real behavioral detail beyond them: the series is sparse, bucketed per hour/day, ordered oldest first, and returns an empty series when no snapshots exist. That empty-result contract is genuinely useful behavior the annotations cannot convey.

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 the core purpose and kept to three sentences with no obvious filler. The opening sentence is dense but every clause carries information (metrics, series shape, bucket resolution, ordering), so it earns its length.

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?

An output schema exists, so return-value documentation is not required, and the description still covers purpose, provenance of the key id, and the empty-series edge case. For a 5-parameter read tool this is essentially complete, with only minor room to spell out time-window behavior further.

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 100%, so the schema already documents since/until/bucket/channel/message_id fully, which sets the baseline at 3. The description adds only marginal meaning, notably message_id's provenance and the bucket granularity, without adding format or constraint detail beyond 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 states a precise resource (a post's views, forwards, replies and reactions, total and per-emoji) and the exact shape of what is returned (a sparse snapshot series bucketed per hour or day, oldest first). This is a specific verb+resource read that an agent can distinguish from siblings like get_channel_posts or get_trend_samples.

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 gives clear situational context ('for view velocity and reaction drift') and, importantly, tells the agent where message_id comes from ('from get_channel_posts'), which routes correct invocation. It stops short of naming an explicit alternative or exclusion condition, so it is not a full when/when-not treatment.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds semantic context about how similarity is determined but says nothing about ordering, whether fewer than `limit` results may return, or other behavioral traits beyond 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?

A single sentence with zero filler; the core concept (similar channels by category and audience) is front-loaded, and the trailing clause adds the purpose rather than repeating the name.

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 read-only lookup with only two parameters and an output schema that already defines the return shape, the description is largely sufficient. The only material gap is that it never hints at result ordering or the effect of `limit`, which matters mildly for a ranked-list tool.

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 50%: `channel` is well documented in the schema as a slug or numeric id, while `limit` carries self-describing default/min/max constraints. The description adds no parameter meaning of its own, so the baseline 3 is appropriate rather than earned.

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 the resource (channels resembling a given one) and the similarity basis (category and audience), which is more specific than the bare title 'Similar channels'. It does not, however, differentiate itself from siblings like search_channels or get_channels, so an agent must infer which discovery tool applies.

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 clause 'the peer cohort to compare a channel's metrics against' implies the use case (benchmarking a channel against peers), which is real but indirect guidance. There is no explicit when-to-use, when-not-to-use, or named alternative versus search_channels.

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, destructiveHint=false and a closed (openWorldHint=false) world, so the safety profile is covered. The description adds the rolling-window scoping and hints at result contents, but discloses no auth needs, rate limits, or freshness caveats beyond that.

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?

Two front-loaded sentences with no filler; the board's scope comes first. The second sentence largely restates output fields that the output schema already defines, which slightly dilutes its value.

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 an output schema present, annotations covering safety, and 100% schema coverage, the description supplies enough scope context (24h window, tracked channels, ranked stories) to call the tool correctly. Only the sibling-routing guidance 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 100%, so lang, limit and window are already fully documented in the schema (including defaults, bounds and enum meaning). The description adds no parameter-level detail, making the baseline 3 appropriate.

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 resource ('ranked board of trending topics/stories') with scope ('across tracked Telegram channels', 'rolling 24h window'), which is far more than a tautology. It does not, however, distinguish itself from nearby siblings such as get_trend_samples, so an agent must infer the difference.

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 never says when to reach for this board versus get_trend_samples or get_post_stats, nor any prerequisite or exclusion. At best the 24h/window framing implies context; there is no explicit 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.

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The word 'sample' usefully signals that results are a subset rather than the full corpus, but the description says nothing about the limit cap, the now/yesterday window, or ordering within the sample.

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?

A single front-loaded sentence with no filler; the 'what it does' clause precedes the rationale. Slightly terse given the undocumented parameters, but structurally sound.

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?

An output schema exists, so return values need not be explained. However, for a 4-parameter sampling tool with an enum parameter and half its schema undocumented, the description leaves the sampling window and limit semantics to be guessed.

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 only 50%: lang and norm are documented in the schema, while limit and window (including the now/yesterday enum) have no descriptions anywhere. The tool description adds no parameter meaning at all, so it fails to compensate for the gap.

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 (sample) and resource (Telegram posts mentioning a trending topic) and adds the intent — reading what a story on the trending board is about. It is clearly distinct from get_trending_topics in effect, though it never names the sibling it complements.

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 purpose clause implies usage ('for reading what a story on the trending board is actually about'), which is enough to infer it follows get_trending_topics, but there is no explicit when-to-use or when-not-to-use versus get_channel_posts or search.

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, destructiveHint=false and a closed-world scope, so safety is covered externally. The description adds that results cite statiko.io pages and yield document ids, which is genuinely useful behavioral context, though nothing about result volume or ranking is given.

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?

Two short sentences with the core purpose front-loaded and the downstream handoff second. No filler or restated name/title material.

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?

An output schema exists, so return-value detail is unnecessary, and the description still flags the id-based handoff to fetch. The remaining gap is the unaddressed overlap with the search_channels sibling, which an agent selecting between them would want resolved.

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 is a single parameter at 100% schema coverage, so the schema already documents 'query' as a free-text search string. The description adds no format, syntax, or query-construction guidance beyond that baseline.

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 (Search) and resource (tracked Telegram channels and trending stories) on a named service, Statiko. It is clear what the tool does, but it does not distinguish itself from the sibling search_channels, which a reader may confuse with this 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?

It implies usage by noting results feed the fetch tool (returns document ids), giving one useful handoff hint. However, it never states when to choose this over search_channels or get_trending_topics, so the routing guidance is only partial.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the useful workflow fact that results are channel slugs feeding get_channels/get_channel_posts, but says nothing about result limits or matching behavior beyond what the schema shows.

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?

Two sentences, no filler, purpose and filter axes front-loaded followed by the output/handoff note. Every clause earns its place.

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 an output schema present, return values need not be explained, and annotations cover safety; the description supplies the filter scope and downstream usage. It is largely complete, only missing any note on result limits or ordering behavior that an agent might want.

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 86%, so the schema already documents query, verified, languages, categories, activity and sort in detail. The description merely restates the filter axes at a high level without adding semantics such as matching rules or defaults, which meets the baseline for high-coverage schemas.

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 (search) and resource (tracked Telegram channels in Statiko's catalog) plus the dimension it searches on (name) and what it filters by. It also names the consumer tools (get_channels, get_channel_posts), which distinguishes it from those fetch-by-slug 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?

Clear about the search-and-filter context and points at the downstream tools that consume the returned slugs, giving the agent a workflow. It stops short of stating when NOT to use it (e.g., use get_similar_channels or get_channel_timeline instead), so it is strong but not exhaustive.

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