删除消息

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

With no annotations, the description carries full responsibility for disclosing behavior. It explicitly states the high-risk nature, that all recipients lose access after deletion, and that the action cannot be undone. It also discloses the unified response structure. This goes beyond what the raw schea or endpoint alone would convey.

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?

Every sentence carries meaningful information: the endpoint, the high-risk/irreversibility warning, the required parameter, and the response format. It is compact, well-organized, and front-loads the most critical safety information before procedural details.

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 single-parameter delete operation with no output schema, the description covers the essential behavioral details: what gets deleted, the consequences, irreversibility, how to supply the parameter, and the shape of the response. No critical knowledge needed to invoke or understand the tool is missing.

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% parameter description coverage for shortCode, and the description simply repeats the parameter name and required flag. While it confirms the field is mandatory, it adds no format, length, origin, or relationship to other messages beyond what the schema already provides. 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 states a specific verb+resource via the HTTP method and endpoint ('DELETE /open/message/deleteMessage') and clearly communicates the destructive intent: deleting a message so all recipients can no longer see it. This distinguishes it from non-delete sibling tools such as open_message_list and open_message_send_result, and from delete tools targeting other resourcesses like topics or friends.

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 makes the usage context unmistakable: use this when you need to permanently remove a message from all recipients. It does not nae alternative tools or exclusions, but given that no sibling tool offers message deletion, the context is clear enough. The high-risk warning also advises againt casual use.

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