Отправка сообщения

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

Beyond the annotations, the description adds important behavioral context that the user message will be read by a live human, that the message is irreversible, and that user confirmation must be obtained beforehand. This is critical operational context not found in readOnlyHint, openWorldHint, or destructiveHint. The word "irreversible" is about being unable to retract the message, which does not contradict destructiveHint=false.

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 compact and front-loaded with the most important warning: the action is irreversible and visible to a human. Each sentence contributes real guidance, though there is slight redundancy between "irreversible" and "cannot be recalled".

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 definition is sufficiently complete for a simple two-parameter messaging tool. It covers the key prerequisite (conversation_id), the user confirmation requirement, and the irreversible human-facing nature. The existence of an output schema reduces the need to explain returns, and the description does not address errors or invalid conversation handling, but these are not needed for adequate invocation guidance.

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?

With schema description coverage at 0%, the description compensates for conversation_id by stating it comes from messenger_conversations(), and for text by implying it is the content shown and sent to the user. It does not add formatting or length constraints, but the two plain string parameters are primarily clarified through this additional source and confirmation guidance.

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 clearly states the operation: sending a message into a chat, with a specific verb and resource. It differentiates itself from the sibling messenger_* tools, such as messenger_conversations, messenger_messages, and messenger_unread, which are read operations.

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 provides strong usage context: it is for sending a chat message to a human (usually bank support), it is not for moving money, and explicit consent is required before sending. It tells the agent to pull conversation_id from messenger_conversations(), and while it does not name explicit alternatives, it effectively separates this tool from money-moving tools like transfer.

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