slack_catch_me_up

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

Annotations already declare readOnlyHint=true, and the description adds valuable context beyond that: it runs locally (no hosted account, no server-side model), and it returns an `output_contract` that instructs how to compose the final summary. This goes beyond the structured fields without contradicting them.

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

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

The description is dense but efficient—each sentence serves a purpose: stating the action, describing the process, clarifying execution context, and explaining output usage. It is slightly long but front-loaded with the core purpose and contains no fluff. A minor trim could improve it, but it earns a 4.

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 explains the full workflow: reading channels, filtering by time, expanding threads, returning structured evidence, and how to use the output (`output_contract`, `signals`, `conversations`). It lacks explicit handling of edge cases (e.g., no conversations, partial failures), but for an agent invoking the tool, the provided information is sufficient to understand what to expect and how to act on results.

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 100% coverage of both parameters with clear descriptions (profile_name and since, including default cadence). The description only mentions `since` in passing and does not add deeper semantic meaning (e.g., format validation or edge-case handling) beyond what the schema already provides, 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?

The description states a specific action ('catch up on a saved workflow profile'), identifies the resource (workflow profile), and enumerates the outcomes (threads unanswered, priority people, active conversations). This clearly differentiates it from sibling tools like slack_get_thread or slack_conversations_history, which serve narrower raw-data purposes.

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 clearly implies when to use the tool—when you have a saved workflow profile and want a structured summary rather than raw message history. However, it does not explicitly name alternatives or when not to use it, so there is no exclusion clause, but the context is clear enough for an agent to select it over related tools.

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