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

Annotations only carry destructiveHint=true; the description does the heavy lifting by disclosing that this is a WRITE ACTION, that it sends a real message, that it may incur carrier cost, and that A2P 10DLC registration is required, plus the underlying endpoint. This is behavior an agent cannot infer from the annotation alone.

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 tight sentences: what it does, the critical write/cost caveat, and the API mapping. Front-loaded and free of filler.

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?

No output schema exists, and the description still doesn't hint at what a successful response contains (message id, delivery status) or failure modes beyond registration. For a send tool this is a minor gap; the send-time risks are well covered.

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 parameters (to, from, userId, content, setInboxStatus) are already documented with formats and bounds. The description only restates the 'up to 10 recipients' limit already encoded as maxItems, adding no new parameter meaning.

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 ('Send an SMS/text message from one of your OpenPhone numbers') plus the recipient ceiling, which cleanly separates it from the read-side siblings like openphone_get_message and openphone_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?

The description establishes prerequisites (approved A2P 10DLC registration) and warns that this is a real send, but it never states when to choose this tool over an alternative or any exclusions. Usage is implied by the write nature rather than explicitly guided.

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