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

No annotations are provided, so the description carries the full behavioral burden — and it delivers. It discloses ordering semantics, the partial-inclusion of messages (thread replies excluded), the conditional return of reactions depending on bot scope, and failure modes the agent will encounter. This is exactly the behavioral context an agent needs beyond a bare 'get messages' statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Four compact sentences that are front-loaded with the core purpose, followed by progressively specific usage details (diff fetching, thread exclusion, reactions scope, error conditions). There is minimal waste — every sentence earns its place. Slightly long compared to the simplest tools, but the richness matches the complexity of the behavior being disclosed.

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 no output schema and no annotations, the description does an excellent job covering what an agent needs: retrieval semantics, incremental fetching, thread exclusion, reaction scope dependency, and error behavior. The only minor gap is that the exact response message structure isn't spelled out, though that's a conventional Slack message shape and the description notes reactions are included. Fully adequate for correct tool 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 the baseline is 3; the description raises it by adding real usage semantics for `oldest` — explaining that passing the previous ts yields only the diff. The ordering semantics ('新しい順') also clarifies how `limit` and `oldest` interact. `channelId` and `limit` are already well documented in the schema, so the description's marginal addition is meaningful but not extensive.

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-resource pair (get channel messages) with explicit ordering ('新しい順' = newest first). It clearly distinguishes itself from siblings by stating that thread replies are NOT included and routing messages with reply_count > 0 to get_thread_replies. An agent can reliably discriminate this from list_channels, list_active_threads, and get_thread_replies.

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 explicit usage guidance: it explains the incremental-fetch pattern ('oldest に前回の ts を渡すと差分だけ取れる'), states when NOT to use it (thread replies require get_thread_replies), calls out the scope prerequisite (reactions:read for reactions), and discloses error conditions (not_in_channel / channel_not_found when bot not participating). This is model-grade routing and preconditions.

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 burden of behavioral disclosure. It explains the pagination behavior (max 2000 replies, inclusion/exclusion of parent message) which is useful, but doesn't disclose rate limits, error conditions, or what happens with empty threads. The behavior described is consistent with the tool's purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is compact and front-loaded with the core purpose, then explains the two modes of operation. Every sentence adds value, though the pagination details could be slightly more 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?

For a read-only retrieval tool with 100% schema coverage, the description covers the essential behavior. However, it doesn't mention return format, sorting order, or error handling, which an agent might need to know for correct invocation. The lack of an output schema increases the burden on the description to explain what the caller receives.

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 all three parameters. The description adds context about the oldest parameter's role in pagination and the parent message inclusion behavior, but doesn't add significant meaning beyond the schema's parameter descriptions.

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 thread replies and requires the parent message's ts. It distinguishes itself from siblings by focusing on thread replies rather than channel history or active threads, though it doesn't explicitly name a sibling alternative.

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 explains when to use the oldest parameter and the default behavior when it's omitted, giving clear context for pagination. It doesn't explicitly state when not to use this tool versus alternatives, but the thread-specific focus makes the usage context clear.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the tool traverses channel history to oldest, judges activity using latest_reply, excludes reply bodies, and truncates message text to the first line. It does not discuss error conditions or rate limits, but the core behavioral quirks are 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 one dense, front-loaded paragraph: purpose first, then selection algorithm, exclusions, truncation behavior, and how to set 'since'. No sentence is filler; the parenthesis about get_thread_replies earns its place by routing to a sibling.

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 moderately complex polling tool with no output schema and no annotations, it covers inputs, selection logic, return limitations, and the polling usage model. It would be slightly stronger if it specified the exact fields returned (e.g., the thread identifier to pass to get_thread_replies), but an agent can invoke it correctly from the information given.

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%, giving a baseline of 3, and the description adds real value: it tells the caller to pass the previous polling time to 'since' and explains 'oldest' as the lower bound for traversing parent messages. This is practical guidance beyond the schema's field labels.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and scoped resource: a polling tool that returns only items with activity since 'since'. It clearly distinguishes itself from get_thread_replies by stating reply bodies are not included, and it names the extraction criteria (new posts or threads with new replies), so an agent can tell what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage context: it is for periodic polling and since should be the previous polling time. It also points to get_thread_replies with oldest as the alternative for reading reply bodies. However, it does not explicitly state when not to use this tool versus the other siblings like get_channel_history or resolve_user, though their purposes differ.

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 does not query Slack (implying potential staleness or cached data) and that even listed channels may be unreadable if the bot isn't invited. These are meaningful behavioral traits beyond the basic purpose, adding transparency without 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?

Two concise sentences with no redundancy. The purpose is front-loaded in the first sentence, and the second adds a critical caveat. 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?

For a zero-parameter tool with no output schema and no annotations, the description covers the core purpose, data source (not live Slack), and a key access limitation. It doesn't specify the return fields or format, but that is acceptable given the absence of an output schema. The description is complete enough for an agent to call 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?

The tool has zero parameters and schema coverage is 100% (no properties). Per the baseline rule for 0 params, a score of 4 applies. The description adds no parameter information, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Returns a list of channels that are set as read targets.' It also differentiates itself by noting it does not query Slack, distinguishing it from sibling tools that fetch live data. The purpose 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?

The description implies usage context: this tool retrieves a locally configured list of channels rather than querying Slack live. It doesn't explicitly name alternatives or when-not-to-use, but the 'does not query Slack' hint provides clear contextual guidance that this is for configuration-based reads, not live Slack queries.

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 implies a read-only lookup but never explicitly states that there are no side effects, nor does it disclose failure behavior (e.g., unknown IDs) or the exact return value. For a simple lookup tool this is acceptable but not thorough.

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 short sentences with no filler. The primary purpose is front-loaded, and the usage note is relevant and concise. 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?

For a single-parameter tool with no output schema, the description covers purpose, usage, and parameter format adequately. The only gap is that it does not specify what the tool returns (e.g., a string, object, or whether both display name and real name are returned). This is minor for the tool's apparent 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 schema already describes userId as 'U から始まる' (starting with U) at 100% coverage. The description adds no new parameter-level detail; it only gives contextual usage (mentions). Baseline of 3 is appropriate since the schema does the heavy lifting.

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 (resolve) and a resource (user ID to display name/real name), and provides a concrete use case (converting <@U…> mentions). It clearly distinguishes itself from the sibling tools, which are about channels and threads, not user resolution.

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 an explicit scenario for use ('used to convert <@U…> in text to person names'), which tells an agent when to apply it. It does not mention when not to use it or alternatives, but no sibling tool performs this role, so the guidance is adequate.

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