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

Annotations only say readOnlyHint=false; the description goes far beyond by disclosing the draft-not-post side effect, the degraded experience on older Slack installs (Copy / Open in Slack / Reconnect), and that a Send button posts 'as YouSpot' only for channels the bot is in. It also specifies the voice/formatting conventions to write in.

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?

Purpose and the crucial no-post fact are front-loaded in the first two sentences. The paragraph is dense but nearly every sentence carries distinct information; it is slightly run-on but not padded.

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 5-param tool with no output schema and minimal annotations, the description covers behavior, fallbacks, and usage triggers well. The only gap is that it never indicates what the call returns (e.g., draft confirmation or identifier), which an agent might reasonably want.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all five parameters, making 3 the baseline. The description adds modest value by clarifying to/person vs channel_id/channel routing and formatting conventions, but does not add syntax or constraints beyond the schema text.

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 ('Write a Slack message for the user') and immediately draws the boundary that matters: 'Nothing posts: the draft is saved in the user's own Slack.' This cleanly separates it from the sibling send_slack_message without needing to open either schema.

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?

Explicit trigger: 'Use this whenever the user asks you to write, draft or prepare a Slack message,' plus re-invoke guidance for revisions. The no-post behavior implicitly routes sending to send_slack_message, though the sibling is never named as an explicit alternative, so it falls 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.