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

No annotations are provided, so the description carries the full burden. It does not explicitly mention that the operation is read-only or free of side effects, though 'compare' implies a non-mutating action. The lack of explicit safety disclosure leaves room for ambiguity.

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, focused sentence that conveys the purpose and a performance note without redundancy. It is highly concise and well-structured.

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 sufficient for understanding the tool's function, even without an output schema. It states the metrics compared and the per-call efficiency. Minor gaps like output format are not critical given the simplicity of the comparison.

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 covers 100% of the parameter (channel_ids) with a clear description, so the baseline is 3. The description does not add extra semantic meaning beyond the schema, such as ordering or deduplication behavior, but no additional detail is necessary.

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 action (compare), the resource (channels), and the specific metrics (subscribers, average reach, ERR). It distinguishes itself from single-channel lookups by emphasizing side-by-side comparison.

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 for comparing multiple channels on key metrics, but does not explicitly state when to prefer this over alternatives like get_channel_stats or get_channel. The 'one channels/stat lookup per channel' hint suggests efficiency but lacks explicit 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?

With no annotations, the description carries the transparency burden. The verb 'Get' implies a read-only operation, but the description does not explicitly state that it causes no side effects or mention any access requirements or error 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 description is concise and well-structured: one sentence states the core purpose and returned fields, and a second sentence directs the user to the relevant alternative for reach/ERR. No wasted 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?

For a simple read tool with no output schema, the description sufficiently outlines the returned profile fields and points to the alternate tool for different metrics. It could mention whether more profile fields exist, but current coverage is adequate for the likely use case.

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, channel_id, is already fully described in the input schema as accepting @username, t.me link, or TGStat channel ID. The tool description adds no additional parameter-level meaning, so the baseline of 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?

States a specific verb ('Get') and resource ('Telegram channel's profile'), and enumerates key profile attributes (subscribers, category, ci_index, RKN verification). It also distinguishes itself from get_channel_stats by noting that reach/ERR belong there.

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 tells the agent to use get_channel_stats for reach/ERR, giving a clear alternative for a likely overlapping need. It does not address every sibling tool, but the primary alternative is covered.

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?

No annotations are present, and the description does not disclose side effects, return behavior, data source, or limitations. Since it is a read-like operation the risk is low, but the description carries the full burden and does not elaborate.

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 clear sentence with no unnecessary words. It is appropriately sized and front-loaded with the core purpose.

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 has no output schema and the description does not specify the response format, units, or whether the average is computed per post or per period. The parameter set covers the main inputs, but return semantics are left implicit.

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 all four parameters with concise descriptions: channel_id format, date patterns, and grouping period. However, it does not explain whether start_date/end_date are both required for a meaningful range or how the default group 'day' affects the returned history.

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 clearly identifies the resource (a channel) and metric (average post-reach) over time. It is distinguishable from siblings like get_channel_stats or get_channel_views, though it is phrased as a noun phrase rather than an explicit verb.

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 provided on when to use this tool versus related tools such as get_channel_stats, get_channel_views, or get_channel_posts. The description does not mention preferred use cases or conditions that would make this tool the right choice.

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?

No annotations are provided, so the description carries full responsibility. The name 'get_channel_err' and the verb 'history' imply a read-only operation, but the description does not explicitly state that no data is modified or that it is safe. This is adequate but not fully transparent.

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 concise sentence that directly conveys the tool's purpose without redundant information. It is well-structured and easy to parse.

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 simple nature of the tool (4 parameters, no output schema), the description is complete enough to understand what data is returned. It does not describe the output format, but that is not strictly required here. Overall, it provides sufficient context for an agent.

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 100% with clear descriptions for each parameter (channel_id, group, start_date, end_date). The description adds no additional meaning beyond these fields, but the schema itself is sufficiently descriptive. Baseline of 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 clearly states the tool retrieves ERR (engagement rate by reach) history for a channel over time. It identifies the specific metric and scope, though it could be slightly more explicit about the data source or calculation.

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 does not mention when to use this tool versus alternatives like get_channel_stats or get_channel_avg_reach. There is no guidance on conditions or scenarios where this tool is preferred, leaving the agent to infer.

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?

With no annotations and no description of side effects, the description does not disclose whether the operation is read-only, whether it paginates, orders results, or enforces rate limits. The agent gets no behavioral context beyond the returned data shape implied by the description.

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, concise sentence that directly conveys the core purpose. No filler or redundant wording is present, and the key qualifier 'from other channels' 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 description lacks essential context for an agent: it does not explain what fields are returned, whether results are paginated, how date ranges interact with the query, or any default behavior. Since there is no output schema, the description should compensate, but it does not.

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 provides full descriptions for all four parameters, including channel_id format, date-range format, and limit bounds. The main description adds no extra parameter context, but given the high schema coverage, the baseline score 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 clearly identifies the resource (posts forwarded from other channels) and the scope (specific channel), making it distinct from the sibling get_channel_mentions. It lacks an explicit verb like 'get' or 'list', but the intent is unmistakable.

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 provided on when to use this tool versus alternatives such as get_channel_mentions or search_posts. There is no mention of preferred scenarios, limitations, or exclusions, leaving the agent to infer usage entirely from the terse 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?

The description does not disclose whether the operation is read-only, what data the response contains, or any side effects or limitations. Since no annotations are provided, the description carries the full burden of behavioral transparency and fails to meet it.

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, concise sentence with no unnecessary words or repetition. It is perfectly sized for the tool's simplicity.

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 tool with only two parameters and no output schema, the description gives the core purpose but omits information about the response format or any edge cases. It is adequate but not enriched with contextual details that would help an agent fully understand the tool's behavior.

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 descriptions cover 100% of the parameters, clearly explaining channel_id and limit. The tool description adds nothing beyond the schema, so the baseline score of 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?

The description clearly states the verb 'Find' and the resource 'where a channel is mentioned or forwarded by other channels and chats,' which distinguishes it from sibling tools like get_channel_forwards. However, 'where' is somewhat vague—it could be more explicit about whether it returns a list of channels/chats or something else.

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 no guidance on when to use this tool instead of alternatives. It does not mention any prerequisite conditions, typical use cases, or contrast with sibling tools like search_channels or get_channel_forwards, leaving the agent to infer usage.

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?

With no annotations, the description carries the burden of explaining behavior. It does mention the return type (posts with view metrics) and supported options (date range, pagination), but it omits details like sorting order, output shape, error handling, and whether date boundaries are inclusive. This is adequate but not fully transparent.

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 two concise sentences with no redundant phrases or extraneous details. It efficiently communicates the core purpose and key optional capabilities.

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 absence of an output schema and annotations, the description provides a reasonable high-level summary but lacks important context such as response structure, default sort order, pagination behavior, or date range inclusivity. It is not incomplete enough to be misleading, but it leaves room for interpretation.

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 JSON schema already provides descriptions for all 7 parameters, covering 100% of them. The tool description adds only a high-level mention of optional date range and pagination, which does not materially enhance understanding beyond the schema definitions. Baseline score of 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 clearly states a specific action ('Get') on a specific resource ('posts of a channel') and includes key modifiers (recent, with view metrics, optional date range and pagination). This distinguishes it from sibling tools like get_channel_forwards, get_channel_mentions, and get_post 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 description does not provide any explicit guidance on when to use this tool versus its alternatives, such as get_channel_forwards, get_channel_mentions, or search_posts. It merely restates the purpose without contrasting with related tools or indicating appropriate scenarios.

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?

With no annotations, the description carries the burden of behavioral disclosure. It implies a read-only operation by listing retrieved statistics, but does not explicitly state safety, authentication needs, or any side effects. For a simple get, this is adequate but minimal; no contradictions or misleading claims.

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, well-structured sentence that front-loads the core action and lists the returned metrics. No wasted words, and the most important information is presented first.

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?

There is no output schema, so the description must convey the return shape. It lists the four statistics, which gives a reasonable idea, but omits types, units, or structure (e.g., object vs. list). Given the tool's simplicity, this is adequate but not thorough; an agent might need to infer details like ERR% being a percentage.

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% for the only parameter (channel_id), so the schema fully documents its meaning. The description adds no extra parameter details, which is acceptable at the high-coverage baseline. No additional semantics are needed 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 uses a specific verb ('Get') and resource ('a channel's statistics') and enumerates the exact metrics (average post reach, ERR%, daily reach, citation index). This clearly distinguishes it from siblings like get_channel_avg_reach or get_channel_err, which focus on individual metrics.

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 more granular siblings (get_channel_avg_reach, get_channel_err, get_channel_views). It doesn't state whether this is a summary/aggregate tool or when to prefer a specific metric. The agent must infer usage from the listed fields.

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?

No annotations are provided, and the description only mentions returning history. It does not disclose read-only behavior, authentication requirements, or rate limits. For a read operation, this omission is noticeable but not critical.

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, focused sentence with no unnecessary words or repetition. It efficiently communicates the core functionality.

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 time-series query, the description is sufficient. It does not explain the output format, but given the straightforward nature and available schema parameters, an agent would likely understand what to expect. Lacks detail on data granularity beyond the group parameter, but that is defined in the schema.

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 descriptions cover all four parameters with clear meanings (channel identifier, grouping, date range). The tool description adds no extra context beyond the schema, so it meets the baseline for full 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 states a specific resource ('subscriber-count history') and scope ('over time'), clearly distinguishing it from sibling tools like get_channel_stats or get_channel_views. However, it could be slightly more explicit about returning a time series, but the intent is unambiguous.

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 on when to use this tool over alternatives. The description implies historical data, but doesn't directly contrast with other channel metrics tools. Users must infer usage from the 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?

With no annotations provided, the description carries the full burden. It discloses that the tool returns a history over time, but does not mention whether it is read-only, what aggregation or granularity is used, any rate limits, or what the response structure looks like. For a data retrieval tool, this is minimal disclosure.

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, concise sentence with no redundancy. It is front-loaded with the core action and resource. It could be more informative, but for conciseness alone it is efficient.

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 4 parameters, no output schema, and no annotations, the description is notably incomplete. It does not explain how time range works, what 'post-views history' means in terms of aggregation, whether data is returned as a series, or any constraints on date ranges. An agent would need to inspect the schema to infer behavior, but the schema only describes parameter types, not expected output or edge cases.

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 covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds no parameter-specific meaning beyond what the schema already provides, so it does not exceed the 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?

The description states a specific verb (get) and resource (channel post-views history over time). It is clear what the tool does, but it does not explicitly differentiate from siblings like get_channel_stats or get_channel_avg_reach, which might also return view-related metrics.

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 on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or scenarios where a different tool would be more appropriate. The agent is left to infer from the name and schema.

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?

No annotations are present, so the description must convey behavioral traits like read-only nature, error handling, or rate limits. It does not; it only lists output fields. The absence of any mention of side effects or failure modes leaves the agent without critical context, especially since the operation is likely a read but is never stated.

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, focused sentence that includes the essential information without any redundant phrases or filler. It is well-structured and immediately understandable.

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 get operation with one parameter, the description is reasonably complete: it specifies the object type and the fields returned. It does not mention error responses or edge cases, but given the simplicity and the absence of an output schema, it provides sufficient context for an agent to know what to expect.

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 already fully describes the only parameter (post_id) with an example and format. The tool description adds no extra meaning about the parameter, so it does not go beyond the schema. This matches the baseline for full 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 purpose: 'Get details of a single post' and enumerates the specific data returned (views, forwards, reactions, text). This is distinct from sibling tools like get_post_stats or get_channel_posts, which focus on aggregates or channel-level 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 description implies when to use the tool—when details of one specific post are needed—but does not explicitly contrast it with alternatives or mention any prerequisites. There is no direct 'use this instead of X' guidance, so it falls to implied usage rather than explicit 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?

No annotations are provided, so the description carries the burden. The term 'Get' implies a read-only operation, but it does not explicitly state side effects, rate limits, or any other behavioral details. This is adequate but not overly transparent.

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, concise sentence with no superfluous words. It efficiently conveys the tool's purpose and key outputs.

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 required parameter and no output schema, the description sufficiently covers what the tool does and what it returns. No critical information 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?

The schema description for post_id is fully covered (100%), providing the format and example. The tool description adds no additional parameter details, so the baseline score of 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?

Clearly states the action ('Get') and the specific resource ('a post's engagement dynamics') with explicit detail on what is returned (views, forwards, reactions over time). This distinguishes it from sibling tools like get_post (which likely returns post content) and get_channel_stats.

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 that this tool is for engagement metrics over time, which implicitly guides when to use it. However, it does not explicitly mention alternatives or when not to use it, so it falls just 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?

With no annotations, the description bears full responsibility. The verb 'Show' implies a read-only operation, which is transparent. It does not mention side effects or potential errors, but nothing about the operation suggests any, so the description is adequate.

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, concise sentence that efficiently lists the key information returned (requests, channels, words, expiry). It is well-structured and free of unnecessary detail.

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?

Despite lacking an output schema, the description outlines the expected contents of the response (usage vs. quota, package expiry), giving the agent a clear picture of what to expect from the call.

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, so the baseline is 4. The description appropriately explains what the tool does without needing to describe any parameters. No conflict or missing information 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 clearly states the tool's purpose: displaying TGStat API usage and quota, including specific metrics (requests, channels, words) and package expiry. This distinguishes it from sibling tools that retrieve channel/post/word 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 description implicitly indicates this tool is for checking API consumption, which is distinct from data-retrieval siblings. However, it lacks explicit 'use when' or 'instead of' guidance, so a full 5 is not warranted.

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?

No annotations are provided, and the description does not mention side effects, permissions, rate limits, or the read-only nature of the tool. Although the function appears to be a non-destructive query, this is not explicitly stated.

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, concise sentence that packs the core functionality, scope, and output type (mentions + views per period) without any redundancy or 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?

The description covers the primary purpose but leaves several gaps for an agent: no output schema or format details, no explanation of how parameters like start_date and end_date interact (e.g., whether both are required), and no mention of error conditions or edge cases. The tool is relatively simple, but the lack of additional context limits completeness.

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?

All 8 parameters have schema descriptions, achieving 100% coverage. However, the tool description adds no additional meaning beyond the schema—it only rephrases the overall purpose. No parameter interactions, defaults beyond the schema, or output-shaping details are explained.

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: tracking keyword mentions across Telegram over time, including views per period. The verb 'track' and resource 'keyword mentions' are unambiguous, and the temporal scope is explicit.

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 does not explicitly state when to use this tool versus the related sibling tools (e.g., get_word_mentions_by_channels, get_channel_mentions). While the global 'across Telegram' scope implies a difference, no explicit guidance or prerequisites 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?

With no annotations, the description carries the full burden of explaining behavior. It mentions the output (channel + mention/view counts) but does not disclose limitations, data freshness, or how the breakdown is ordered or aggregated.

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, clear sentence that gets directly to the point. It is concise and well-structured, with minimal unnecessary wording.

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?

Since there is no output schema, the description should summarize the return values. It mentions channel and mention/view counts, which is helpful, but it does not explain ordering, pagination, or whether the result is sorted by mention count or view count, leaving some ambiguity.

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 all parameters with descriptions, so the baseline is 3. The tool description does not add additional meaning beyond what the schema already provides, so no boost is warranted.

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 that the tool breaks down keyword mentions by channels and provides counts, which is a specific function. It distinguishes itself from raw mention queries and channel-specific mentions, though it doesn't explicitly name alternative 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?

No guidance is given on when to use this tool versus alternatives like get_word_mentions or get_channel_mentions. The description only states what it does, not the context in which it is preferable.

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?

No annotations are provided, so the description carries the full burden. It correctly implies a read-only operation and mentions the output (category codes), but does not disclose details like response format or any side effects. For a simple list tool this 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?

A single, front-loaded sentence that conveys the purpose and usage without any filler. Every word 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?

The tool is simple: one optional parameter and no output schema. The description tells the agent what it returns and how to use the result. It could mention the output structure, but that is not essential for a list of codes.

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% (the 'lang' parameter has a description), so the baseline is 3. The description does not add anything about the parameter, but it is not necessary given the schema covers it.

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 ('list') and resource ('channel category codes'), and explicitly notes its intended use as a filter in search, which differentiates it from sibling tools like search_channels or get_channel.

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 tells the agent exactly when to use it (to obtain category codes for the 'category' filter in search). It lacks explicit 'when not to use' or alternatives, but the context is clear enough for a reference tool.

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?

There are no annotations, and the description does not disclose behavioral traits such as side effects, read-only nature, or any impact. As a simple list operation, it likely has none, but the lack of any statement leaves this ambiguous.

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, clear sentence that directly states the purpose and usage context without any unnecessary details.

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 and the purpose is clear; the description does not need to detail the output schema since the return type (list of country codes) is obvious from the action. It is complete for a tool of this simplicity.

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 parameter 'lang' is already described in the schema with an enum and default, and the description adds no further meaning beyond what is present. The schema coverage is high, so the baseline 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?

The description clearly states the tool lists available country codes and explicitly ties it to the 'country' filter in search, distinguishing it from sibling enumeration tools like list_categories and list_languages.

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 provides a usage context ('use as the country filter in search') but does not explicitly mention when to use it instead of alternatives or when not to use it. No comparison with sibling list tools is 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?

With no annotations, the description carries the full burden. The verb 'List' clearly implies a read-only operation with no side effects, which is transparent enough for a simple enumeration. It does not explicitly state 'read-only', but the behavior is unambiguous.

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 concise sentence that packs both the purpose and a usage hint. No unnecessary words or redundancy; it is well-structured and to the point.

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 low complexity (one optional parameter, no output schema), the description provides all necessary context: what the tool returns and how to use it. The parameter is fully documented in the schema, so no missing information affects usability.

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 already includes a description for the 'lang' parameter ('Response language for names'), covering 100% of the parameter. The tool description does not add additional meaning beyond this, so the score matches the baseline for full 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: 'List available language codes' and provides a specific use case: 'use as the `language` filter in search'. This makes the purpose unmistakable.

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 how to use the output ('use as the `language` filter in search'), giving clear guidance on when this tool is relevant. It implicitly differentiates it from other list tools by focusing on language codes.

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?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It only mentions 'curated channel cards', hinting at ranking but not explaining pagination, default limit, error handling, or the effect of the search_by_description flag. It does not state that the operation is read-only or any rate limits. This is a significant gap for a search tool.

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, compact sentence that front-loads the core purpose and mentions the key filter types. It is appropriately concise without being under-specified, though it omits some operational details. The structure is efficient and not verbose.

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 7 parameters and no output schema, the description is incomplete. It does not mention the required query parameter, the limit parameter, the peer_type enum, or the search_by_description option. It also fails to note that category/language/country codes come from the list_* sibling tools. An agent would need to inspect the schema to understand these details, and the description provides insufficient context for correct 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?

Schema coverage is 100%, so all parameters are already documented in the input schema. The description adds minimal value by listing filter types (category, language, country, type) which correspond to schema properties, but it does not explain any parameter further. Since the schema is thorough, the baseline of 3 applies; the description does not add meaningful semantic detail beyond that.

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 searches Telegram channels by query with optional filters for category, language, country, and type. It distinguishes this from search_posts by explicitly focusing on channels and mentions the return of 'curated channel cards', giving a specific verb, resource, and result format.

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 no guidance on when to use this tool versus alternatives like search_posts or get_channel. It does not state when to prefer this over a direct lookup or when to avoid it. No exclusions or alternative references are present, leaving the agent to infer usage context.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the operation and filters. It does not mention result ordering, pagination, or any side effects or limitations, which are critical for a search tool with many parameters.

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 that efficiently captures the core purpose and mentions the filter types without redundancy. Every word adds 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?

The tool has 11 parameters and no output schema, yet the description gives only a high-level summary. It fails to explain what 'extended' means, how results are ordered, or what the response structure is, leaving significant gaps for an agent that needs to use the tool effectively.

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 100% and each parameter already has a description in the schema. The description only groups some filters (source-type, category, language, country, date) without adding any new meaning or syntax beyond what the schema provides, so it stays at the baseline of 3.

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 performs full-text search across Telegram posts with optional filters. It is specific enough to distinguish from tools like get_channel_posts (which targets a specific channel) and search_channels (which searches channels), though it doesn't explicitly name those 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?

The description implies usage for searching posts broadly, but provides no explicit guidance on when to prefer this tool over siblings like get_word_mentions or search_channels. There are no exclusions or alternative recommendations, leaving the agent to infer context.

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