Địa chỉ ngừng gửi

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add that the operation is a read/view returning addresses plus reasons, which is meaningful, but it says nothing about output shape, scope (mail vs monapay), ordering, or pagination. For a tool with zero annotation coverage, this is thin.

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?

Two short sentences in Vietnamese and English, with the scenario front-loaded before the action. Every word earns its place and there is no filler; the only minor inefficiency is the bilingual duplication being partially redundant.

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?

Given there is no output schema and no annotations, the description should clarify what the response looks like and any scope constraints; it reveals only that addresses and reasons are returned. For a simple zero-parameter list tool it is close to adequate, but it omits sibling differentiation and any hint of output structure that an agent would need without an output schema.

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 schema declares zero parameters with trivially complete coverage, so per the rubric the baseline for 0 params is 4. There is nothing about parameters for the description to add, and the schema needs no compensation.

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 action and resource: "xem địa chỉ và lý do ngừng gửi" (view addresses and the reason for suppression), and the English gloss 'diagnose suppressed recipients' reinforces the read/list nature. It is distinguishable from the sibling mail_suppression_remove by direction (view vs remove), though it does not explicitly name that sibling or the cross-domain monapay_list_email_suppressions.

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 English sentence 'Use to diagnose suppressed recipients' gives a clear trigger condition for when to call the tool, which is more than just implied usage. However, it provides no exclusions and names no alternatives — an agent gets no guidance on when to prefer this over monapay_list_email_suppressions or when to pair it with mail_suppression_remove.

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