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

The description explicitly leads with 'MUTATES', reinforcing the destructiveHint annotation, and adds behavioral detail beyond the schema: file/multipart payloads are unsupported and the operation maps to POST /{channel_type}/{channel_url}/messages. It does not discuss delivery/push consequences, but the schema already documents silent and push controls.

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 sentences, each earning its place: mutation and function, the unsupported multipart limitation, and the API endpoint. The key MUTATES signal 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?

For an 11-parameter mutation tool with a fully documented schema and destructiveHint, the description plus schema is largely sufficient. The main gap is the lack of any hint about the response/return value, since no output schema is provided.

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 has 100% description coverage, so the description does not need to re-document parameters. It adds little semantic value beyond the schema—'MESG/ADMM' already appears in the message_type property—so baseline 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 uses a specific verb ('sends') with a clear resource ('a message into a channel') and distinguishes the two modes (MESG user, ADMM admin). It states the exact API endpoint, making it unambiguous and distinct from sibling read tools like sendbird_list_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?

It clearly marks the operation as a mutation and gives a concrete exclusion ('File/multipart messages are not supported'), so an agent knows when not to use it. However, it does not explicitly name alternatives or spell out when to prefer a sibling such as sendbird_request for unsupported payloads.

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