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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value by disclosing what data is exposed (member lists, usernames of most active participants, archive boundary), but says nothing about cost, rate limits, or behavior when the chat is missing or inaccessible.

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 enumerates the payload without padding. It is dense but every clause maps to a distinct returned field.

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 the return-value enumeration is partly redundant, and the genuinely missing piece, the accepted identifier format for 'chat', is not addressed. Adequate for a simple read, but incomplete on the only input an agent must produce.

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 single parameter 'chat' has 0% schema description coverage and accepts either a string or an integer, yet the description never explains what form the identifier takes (username, title, numeric ID). The description does not compensate for the schema gap on the one parameter an agent must supply.

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-plus-resource ('Details of one chat') and enumerates the returned data (kind, members, forum topics, top participants, archive coverage), which clearly separates it from list_chats. It never names a sibling explicitly, but the singular 'one chat' scope makes the distinction inferable.

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 explicit when-to-use statement, no prerequisites, and no mention of alternatives such as list_chats for enumeration. Usage is only implied by the word 'one chat'.

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 openWorldHint=false, so the safety profile is covered. The description adds useful operational context beyond that: the hard cap of 300 on limit, the default window behavior when no range filter is supplied, and the exact rendered line format. It does not discuss pagination edge cases beyond the paging notes, keeping it at a 4.

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?

Front-loads the core behavior and output format, then breaks parameter guidance into compact clauses that each convey distinct information. Slightly dense as a single paragraph, but no sentence is redundant; a light bulleted layout would push it to a 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?

For a 10-parameter read tool, the description covers default behavior, range filtering, paging direction, media filtering, and result format, and an output schema exists to cover return structure. An agent has everything needed to select the right argument combination on the first try.

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 carry all parameter meaning and it largely does: limit's 300 cap, since/until format examples ('7d', '2026-09-01'), after_chat's role tied to the paging note, topic accepting id or title, and media's full enum including the 'files'/'any' aggregates. Only `chat` itself is left undefined, which is self-evident given the stated purpose.

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 ('Read one chat in chronological order') and specifies the exact output shape (one line per message with ref, id, date UTC, sender, text). This distinguishes it from list_chats and search_messages, which do not return per-message text in that form, and the mention of 'the context of a search hit' implicitly positions it against search_messages.

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 routes between modes: no since/around means newest `limit` messages, 'the right call for "latest from X" or drafting a reply'; around_message_id for search-hit context; before/after_message_id for paging history; since/until for time ranges. Each parameter's use case is stated so the agent can pick the right call without 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?

Annotations already declare readOnlyHint and openWorldHint=false, so the safety profile is covered. The description adds useful traits — the result ordering and the set of fields returned — but says nothing about pagination/limit behavior or what "archived" scope actually includes (all chats vs. archived-only), which is the main ambiguity for an agent.

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?

Front-loaded with purpose and ordering, then a three-line parameter glossary with zero filler. Every sentence adds either scope, usage routing, or parameter meaning.

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 optional and the field list is a bonus. For a four-parameter filtered list tool with read-only annotations, the only meaningful hole is the undocumented limit parameter and the unstated meaning of "archived" scope.

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 carry the parameter burden and largely does: query is defined as part of a title/username, kind enumerates the four accepted values, and active_since gets concrete format examples ("24h", "7d", "2026-09-01") that the schema does not supply. The limit parameter is never mentioned, leaving its default of 30 and maximum unbounded from the description.

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 ("List archived Telegram chats") plus the returned fields and sort order ("most recent first"), which is well beyond a restatement of the name. It does not explicitly differentiate itself from siblings like chat_info or search_messages, so it stops short of a 5.

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?

"Use it to find a chat id or to see when a chat was last active" gives clear positive usage context tied to concrete outcomes. It never names an alternative tool or states when not to use this one, so no exclusions 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine behavior beyond that: results are ordered most recent first, aggregation is per chat, and there is an explicit 'waiting for the user's reply' flag. It does not disclose pagination, caps on the number of chats returned, or cost/latency considerations, which keeps it below 5.

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 compact blocks: the purpose/return summary first, then per-parameter notes, each sentence load-bearing. Front-loaded correctly with the highest-value information. Minor deduction for the slightly fragmented line-wrapped phrasing that reads like an unstyled bullet list.

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 needn't be spelled out, yet the description still characterizes the payload (counts, latest few, reply flag) helpfully, and annotations cover the safety profile. Defaults (since=24h, per_chat=5) and the exact 'chats' identifier format are the remaining holes an agent might need before calling.

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 carries the full burden and largely meets it: 'since' gets concrete format examples ('24h', '7d', '2026-09-01'), 'per_chat' gets a meaning plus an undocumented cap of 20, 'kind' is glossed per enum value, and 'chats' is described as a limiting filter. The gap is 'chats', where the accepted identifier form (string usernames vs integer ids) is never clarified for a union-typed array.

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?

Opens with a concrete verb+resource and result shape: 'What happened recently across chats, most recent first: per chat the number of new messages, the latest few, and a flag on chats waiting for the user's reply.' An agent immediately knows this is an aggregated digest, not a raw message dump. It doesn't explicitly contrast itself with siblings like list_chats, get_messages or search_messages, so it misses the top mark.

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 'Use for "what's new", "what did I miss" and "who am I owing an answer"' line gives strong user-intent triggers that map directly onto selection decisions. However, it never states when NOT to use it (e.g., for a full message search use search_messages, for a single chat's history use get_messages), so no exclusions or named alternatives 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?

Adds real context beyond the annotations: it blocks and waits up to wait_seconds (capped at 300), single-chat refresh also picks up edits, and 'Never sends anything to Telegram' clarifies that readOnlyHint=false refers to local archive writes, not outbound sends. That said, it doesn't explain the archive-write side effects or whether refresh is safe to run concurrently.

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?

Three tight sentences, front-loading the core action, then the wait behavior, then the safety note. No filler and each sentence carries distinct 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?

Annotations cover the safety profile and an output schema exists, so the description needn't explain return values. It covers both parameters and the key blocking behavior; the only remaining gap is any hint about typical duration or failure handling when the wait times out.

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 does the needed work: 'chat' is explained as optional all-chats-vs-one-chat selector, and 'wait_seconds' is described as a wait bound with a max of 300 (a constraint absent from the schema). It doesn't say whether chat accepts a username, ID, or title, leaving the string-or-integer ambiguity unresolved.

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 — 'Fetch new messages from Telegram into the archive' — and scopes it ('all chats, or one chat'). An agent can distinguish this from get_messages or search_messages because the description makes clear it pulls new data into the archive rather than querying existing stored messages.

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?

Implies when to use it (to get new messages and edits into the archive) and notes that refreshing a single chat also captures recent-message edits, which is a useful contextual cue. However, it never explicitly names alternatives such as search_messages or get_messages or states when not to refresh.

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 openWorldHint=false, so safety is covered; the description adds real behavioral detail beyond them — ordering (newest first), grouping by chat, and the prefix-matching fallback ('if no message has all words, messages with any of them are returned'), which changes how results should be interpreted. It does not mention the limit default of 20 or truncation behavior, keeping it below a 5.

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?

Dense two-block structure: a summary sentence with the return path first, then a parameter glossary. Every clause carries actionable information with no filler or repetition of the title.

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 needn't be explained, and the description still adds ordering, grouping, and the message-id linkage. Missing are pagination/limit behavior and result count behavior, minor but relevant for a 7-parameter search 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 description coverage is 0%, so the description must carry all parameter meaning, and it does: query prefix-matching/quoting/OR semantics, chat accepting id/@username/title fragment, sender as partial name, since/until formats ('24h', '7d', ISO), and the media enum values. Only limit is left undocumented.

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?

Specific verb+resource+scope: 'Keyword search over all archived messages and file names, newest first, grouped by chat.' It also explains the output shape and routes the agent to get_messages(around_message_id=...) for opening a hit, which distinguishes it from list_chats/get_messages/recent_activity.

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 states when this applies and when not: 'Not semantic: search for words the messages would contain, not for the question.' It names the follow-up tool and the exact parameter for drill-down, so an agent knows both entry and next step.

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