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

Annotations only flag destructiveHint=true; the description goes further by disclosing that messages cannot be undone, are never retried, and require explicit user approval via confirm=true. It also names the underlying endpoint (POST /{account}/messages), which helps the agent reason about side effects. This is exactly the added context the annotation bar asks for.

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 short clauses, front-loaded with the WRITE label and the irreversibility warning before the procedural instruction. No filler; 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?

For a destructive write with no output schema, the description covers safety, approval workflow, and side effects well. The one gap is that it doesn't indicate what the call returns (message IDs, per-recipient status), which an agent may need to report back or verify delivery.

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 all four parameters are already documented in the schema, including confirm's "Must be true" semantics. The description's mention of showing recipients and passing confirm=true largely restates the schema rather than adding format or constraint detail. Baseline 3 applies.

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 ("sends a REAL SMS") with scope ("from the account's number to one or more recipients"), which cleanly separates it from the read-only sibling tools like textus_get_conversation or textus_list_contacts. An agent can identify it as the sole outbound-write tool without opening the 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?

Gives an explicit precondition workflow: "Show the user the recipients and text first, then call with confirm=true." This tells the agent what to do before invoking. It stops short of naming alternatives or when-not-to-use cases, but for a terminal send action there is no obvious alternative to route to.

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