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

With no annotations, the description alone must disclose behavioral traits. It does state the key state restriction, which is valuable. But it omits what happens on invalid states (error vs no-op), whether cancellation is reversible, any idempotency effects, or side effects. This is minimal but not comprehensive.

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 two short sentences, one in Vietnamese and one in English, with no filler. The action and state restriction are front-loaded, and every word contributes to the meaning.

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 simple cancellation tool, the essential action is stated, but without an output schema the description does not clarify return values or failure behavior. It also does not explain how idempotency_key affects cancellation or recommend verifying checkout status beforehand. Adequate but with clear gaps.

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%, and the schema already documents checkout_id and idempotency_key, including the auto-UUID behavior. The description adds no additional parameter meaning, so the baseline of 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?

The description clearly specifies the action: cancel a pending checkout, and explicitly restricts the operation to pending state only. This distinguishes it from sibling tools like monapay_cancel_qr and other checkout operations without ambiguity.

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 clear context on when the tool is valid (pending checkout) and explicitly lists ineligible states (paid, expired, cancelled). However, it does not name an alternative tool for non-pending checkouts or suggest checking status first, so it stops short of full routing guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says cancellation happens, without revealing whether the cancellation is irreversible, what happens if the QR was already scanned, or any side effects on associated transactions. This is a significant transparency gap for a destructive operation.

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 uses two short, parallel sentences (Vietnamese and English) that communicate the action directly. It is front-loaded, scannable, and wastes no words.

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 mutation tool with no annotations and no output schema, this description is too thin. It omits parameter semantics, behavioral side effects, and any response hints. An agent would need to infer too much to invoke it correctly and confidently.

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 coverage is 0% and the description does not mention qr_code_id at all. While the parameter name is somewhat self-explanatory, the description fails to compensate for the lack of schema documentation. An agent is left guessing what value to pass and how to obtain it.

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 and resource: 'Cancel a dynamic QR' (Huỷ một mã VietQR động đã tạo). This clearly distinguishes it from siblings like monapay_create_qr and monapay_cancel_checkout. The bilingual text reinforces the same unambiguous action.

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 phrase 'already created' implies a prerequisite: the QR must be dynamic and existing. However, there is no explicit guidance on when to use this versus alternatives like monapay_cancel_checkout, nor any mention of conditions or exclusions. The usage context is only lightly implied.

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

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

With no annotations, the description carries the full burden, and it does disclose one important behavioral trait: confirmation is asynchronous via the CHECKOUT_PAID webhook, so fulfilment must wait. It omits other relevant traits for a mutation tool such as auth/permission needs, whether the link expires by default, and what the caller receives back.

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 compact sentences in a Vietnamese/English pair, with the core action front-loaded and no filler. The bilingual duplication doubles the character count without adding information, which slightly works against pure conciseness.

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 12-parameter creation tool with no annotations and no output schema, the description covers only the headline purpose plus the webhook wait. It says nothing about sandbox vs live mode, idempotency, URL/expiry fields, or metadata, so an agent must infer most of the contract from the schema alone.

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 only 25% across 12 parameters, so most fields (return_url, cancel_url, expires_in, metadata, virtual_account_id, payer_*) are opaque. The description adds no parameter-level meaning to compensate, leaving the majority of the surface undocumented.

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 and resource ('Tạo link thu tiền / Create a hosted checkout link'), which is unambiguous and distinguishable from write-side siblings like monapay_create_qr. It stops short of explicitly naming the alternative tools or contrasting the hosted-link flow against QR-based collection.

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?

It gives downstream workflow context ('đưa link cho khách hoặc chuyển hướng checkout; đợi webhook CHECKOUT_PAID trước khi giao hàng'), i.e. deliver or redirect, then wait for the webhook before fulfilment. This is useful implied usage but it never states when to prefer this over monapay_create_qr, nor any preconditions/exclusions.

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

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

With no annotations, the description carries the full burden and does disclose key behavior: creation triggers per-recipient 6-digit verification codes and requires a subsequent verify step. It does not cover permissions, rate limits, whether the config is inactive until verified, or error behavior, leaving some gaps for a mutation tool.

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 content is front-loaded and contains no filler beyond the core purpose and verification workflow. The only inefficiency is the bilingual duplication, which repeats the same two sentences in Vietnamese and English.

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 4-parameter mutation tool with no annotations and no output schema, the description covers the essential creation purpose and the critical post-creation verification workflow. It leaves out secondary details (authorization, failure handling, config state before verification), so it is strong but not fully complete.

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 descriptions already document all four parameters at 100% coverage, so baseline is 3. The description adds meaningful semantics by clarifying that each recipient address receives its own code, which changes how the recipients parameter must be handled (collect one code per address).

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 ('Tạo kênh thông báo email' / 'Create an email notification config') and clearly differentiates from siblings like update, delete, and list email configs. An agent can identify this as the creation step without ambiguity.

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 explicit post-creation instructions: MONA Pay sends a 6-digit code to each address, the agent must ask the user for each code and then call monapay_verify_email, never guessing. This names the follow-up tool and action sequence, though it does not explicitly distinguish when to create versus update an existing config.

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

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

With no annotations, the description carries the behavioral disclosure burden. It adds valuable context beyond the schema: the customer scans the QR, funds go to a virtual account, and MONA Pay fires a webhook. This explains the operational consequence of calling the tool, though it does not discuss idempotency, expiry, or failure modes.

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 short, front-loaded with the core action, and includes a useful behavioral sentence. The English summary is mildly redundant with the Vietnamese sentence but serves bilingual users without adding meaningful bloat.

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 tool has 13 parameters, no annotations, and no output schema, so the description should compensate for more. It explains the payment flow and webhook behavior, which is helpful, but it does not describe what the tool returns (e.g., QR image, URL, or ID), nor does it give guidance on prerequisites or when to prefer this over related Monapay payment tools.

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 62%, so the schema already documents most key parameters. The description adds a small semantic clue by saying 'điền sẵn số tiền + nội dung', which maps to the `amount` and `description` parameters, but it does not explain ambiguous optional parameters like `traceNumber`, `loyaltyCode`, or `voucherCode`.

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 explicitly states a specific verb ('Tạo'), resource ('mã VietQR động'), and context ('cho một đơn hàng qua ACB'). This clearly distinguishes it from siblings like monapay_create_checkout and monapay_cancel_qr, and adds behavioral specifics beyond the title.

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 implies when the tool should be used ('cho một đơn hàng' / for an order) and describes the QR flow, but it does not explicitly contrast it with alternatives such as monapay_create_checkout, monapay_link, or static QR generation. There are no exclusions or if-then routing cues.

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

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

No annotations exist, so the description must carry full behavioral disclosure. It states the side effect of registering a webhook and recommends HMAC_SHA256 plus secret_key, but it does not explain whether secret_key is required or auto-generated for HMAC, whether the URL is validated, when the webhook becomes active, or what the response contains.

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 short and front-loaded, with the core purpose and a useful security recommendation. The English trailing phrase 'Create a webhook config' largely repeats the title, so there is minor redundancy, but overall it is compact.

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 7-parameter mutation tool with no annotations, no output schema, and only 43% schema coverage, this description is incomplete. It omits required-field semantics, conditional behavior for auth types, notification scope details, and the expected result or error cases, leaving the agent to guess important configuration choices.

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 only 43%, so the description should compensate. It adds a recommendation involving auth_type and secret_key, but it does not explain the required 'name' field, clarify webhook_url expectations beyond 'URL', or describe payload_format and virtual_account_id behavior.

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 action ('Đăng ký URL nhận webhook' / 'Create a webhook config') and the triggering condition ('khi có tiền vào' / when money comes in). It distinguishes this from update/delete/list webhook siblings by the explicit create/register framing, though it does not name alternatives.

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 implies when to use it: when you need a webhook to receive incoming-payment notifications. However, it does not explicitly tell the agent when to prefer this over monapay_update_webhook, monapay_test_webhook, or monapay_generate_webhook_snippet, and it omits prerequisites or conditions.

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

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

No annotations are provided, so the description carries the behavioral transparency burden. It does disclose a non-obvious platform behavior (Zalo ignores Markdown, so templates must be plain text) and clarifies that the group already contains the bot. However, it omits side effects, idempotency, duplicate-connection behavior, permissions, and success/failure response details for a mutation tool.

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 two compact sentences with no filler. It front-loads the primary action and ID constraint, then adds the important template caveat, making every sentence earn its place.

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 description covers essential ID sourcing and the Markdown constraint, but for a connection operation with no output schema and no annotations, it lacks information about what happens on success or failure, whether reconnecting an already-connected group errors or is idempotent, and how events and is_active interact. The sibling update/delete/test tools are not referenced for follow-up actions.

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 already covers 83% of parameters, including group_id source and message_template plain-text requirements, so the description mostly restates schema content. The only added semantic context is the rationale that Zalo does not parse Markdown. This meets the baseline but does not compensate for the undocumented is_active parameter.

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 uses a specific action verb 'Nối' (connect/link) and identifies the resource: a Zalo group containing the Mona bear bot, identified by a 10–25 digit group_id. The action is clearly distinct from sibling list/update/delete/test operations, and the title reinforces that this is about connecting, not creating, a Zalo group.

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 gives clear, actionable context: obtain group_id from MONA Account/PMS and keep message templates as plain text because Zalo does not parse Markdown. It does not explicitly contrast with monapay_update_zalo_group or state when not to use it, so there is room for a 5, but the prerequisites and constraints are clear enough for correct usage.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It does disclose that deletion is permanent/irreversible, which is important for a destructive operation. However, it does not mention side effects, required permissions, or what happens to linked notifications after deletion.

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 very short and front-loaded: 'Xoá vĩnh viễn' / 'Permanently delete' appears immediately. Both bilingual lines earn their place with no filler or redundancy.

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 tool is simple with one required parameter, and the schema covers that parameter fully. The description adds the key permanence warning, but with no annotations and no output schema, it leaves expected return behavior and side effects unspecified.

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%, and the single required parameter config_id is already documented as a UUID for the email config. The description adds no additional parameter-level meaning, so the baseline score of 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?

The description states a specific action ('permanently delete') and a clear resource ('email notification config'), which fully clarifies what the tool does. It also distinguishes itself from sibling tools like list, create, and update email configs by using the verb 'delete'.

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?

No when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives such as monapay_update_email_config for modifying a config instead of deleting it, nor does it warn about conditions like invalid or already-deleted config IDs.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It only restates the delete operation and adds nothing about permanence, failure behavior, side effects, authentication needs, or response shape.

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 a single, short, front-loaded sentence in two languages with no wasted words. However, it largely repeats the tool name and title, so the conciseness does not add much informational value.

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 one-parameter delete operation, the core instruction is present and minimally usable. But with no annotations and no output schema, the agent is left without behavioral expectations or any guidance on locating config_id, so completeness is only adequate for a very simple tool.

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 coverage is 0% and config_id is only described as a required string. The description adds the minimal context that the resource is a 'webhook config', which lets an agent infer that config_id identifies that config, but it does not explain how to obtain the ID or any format expectations.

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: 'Delete a webhook config', and the Vietnamese title reinforces it. It is clearly distinct from sibling operations like monapay_create_webhook, monapay_update_webhook, or monapay_test_webhook because of the delete verb, even without explicit comparison.

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?

There is no guidance on when to use this tool versus alternatives, no prerequisites (e.g., that the config must exist, that the operation is irreversible), and no indication that config_id should be obtained from monapay_list_webhooks. The sibling list shows many webhook-related operations, but the description provides no routing help.

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

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 states the delete action but does not disclose whether the deletion is permanent, whether notifications stop immediately, whether it is idempotent, or what happens if the id does not exist. There is no contradiction, but the transparency is minimal.

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 a single, front-loaded sentence with no wasted words. It efficiently conveys the exact action and object, which is appropriate for a simple delete operation.

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 one-parameter delete tool, the description is nearly complete: it names the exact resource and the schema documents the id thoroughly. It falls just short of a 5 because it omits optional but useful context such as irreversibility, success/failure behavior, or requirements, especially given the absence of annotations and 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 describes the only parameter fully, including its purpose and UUIDv6 format, so the description does not need to repeat parameter details. With 100% schema description coverage, the baseline of 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?

The description uses the specific verb 'Xoá' and clearly identifies the resource as a Zalo group notification configuration ('cấu hình thông báo nhóm Zalo'). This distinguishes it from sibling operations like create, update, test, and list, and clarifies that it is the configuration being deleted, not an actual Zalo group.

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?

There is no guidance on when to use this tool versus alternatives. It does not mention how to obtain the id via monapay_list_zalo_groups, nor does it provide conditions such as 'use only when you want to permanently remove a group notification configuration' or any exclusions.

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

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

No annotations are present, so the description carries the behavioral disclosure burden. It meaningfully discloses that message bodies are never stored, which is an important privacy trait, and implies a read-only metadata listing. It omits pagination behavior, ordering, retention, and permission requirements, but those are less critical for a non-destructive log query.

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 short and front-loaded with the core action, followed by the privacy caveat and filter dimensions. The Vietnamese and English halves are redundant, but the duplication is compact and unlikely to confuse an agent.

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 read-only optional-filter listing tool, the description covers purpose, the no-body guarantee, and the main filter dimensions. It lacks any hint of the returned metadata fields, default ordering, or pagination behavior, and there is no output schema to fill that gap.

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 0% schema description coverage, the description only partially compensates: it maps filters to config, status, event, and date, which correspond to config_id, status, event_type, and from_date/to_date. It does not explain enum meanings, date format, or pagination semantics, so agents must still rely on property names and schema patterns.

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 ('List'/'Tra') on a specific resource ('email delivery metadata'/'email logs') and explicitly excludes message bodies, which distinguishes it from email config, stats, and suppression tools. The bilingual wording reinforces the same intent without ambiguity.

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?

It gives clear use context: retrieving per-send delivery metadata with optional filters by config, status, event, and date. It does not explicitly name sibling alternatives or state exclusions, but the intended lookup scenario is clear enough for an agent to select this tool over the related email stats or config tools.

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

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

With no annotations provided, the description carries the full behavioral burden and does disclose the main output aspects: totals, success rate, P95 latency, and error groups. It does not mention whether the operation is read-only, how date boundaries are treated (inclusive/exclusive), timezone assumptions, or any limits, but the wording strongly implies a read-only aggregate report.

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 key metrics and the date-range constraint in the first clause. The bilingual repetition is slightly redundant for an English-capable agent, but it is not verbose and every substantive detail serves a purpose.

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 simple two-parameter statistics tool, the description covers the core return value categories and the date-range input concept. It is incomplete in smaller but useful ways: no mention of date inclusivity, maximum range, timezone, default behavior when parameters are absent, or how this relates to sibling tools like mail_stats and monapay_email_logs.

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 0%, so the description must compensate. It mentions a date range, which partially explains the purpose of from_date and to_date, and the parameter names are self-explanatory. However, it does not explicitly state which parameter is the start or end, whether both are required, or what happens when one is omitted.

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 a specific resource (email delivery statistics) and a specific verb (Lấy/Get), and enumerates the metrics returned: totals, success rate, P95 latency, and error groups. However, it does not explicitly distinguish itself from the similar sibling mail_stats or from monapay_email_logs, so it stops short of full differentiation.

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 phrase 'trong khoảng ngày / in date range' implies this tool is for date-bounded aggregate reporting, which gives some usage context. There is no explicit statement of when to use this tool versus alternatives like mail_stats or monapay_email_logs, and no exclusions or conditions are provided.

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

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

With no annotations, the description carries the behavioral disclosure burden. It usefully discloses that the secret is shown only once ('hiện 1 lần'), which is critical for the agent. However, it does not mention whether existing keys remain valid, whether generation has side effects, or any security/rate-limit implications; the English portion omits the one-time display detail entirely.

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 short and front-loaded, with the key action and one-time display behavior placed first. The bilingual repetition is mostly redundant, and the crucial 'shown once' detail appears only in Vietnamese, which slightly harms structure and accessibility.

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 simple tool with no output schema, the description partially explains the result: a new client_secret is generated, displayed once, and used in a header. However, it lacks explicit return/format details, parameter semantics, and any indication of whether previous secrets are affected, so the information is adequate but incomplete.

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 one optional string parameter 'name' with default 'mcp' and no schema description (0% coverage). The description never mentions this parameter, so the agent cannot know what 'name' represents or whether it affects the generated key. The optional/default nature lowers the risk, but semantic meaning is entirely absent.

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 verb and resource: generate a new client_secret, and it explains the intended use via the X-Client-Secret header. This makes the tool's purpose understandable and distinct in practical terms, though it does not explicitly contrast it with the sibling monapay_rotate_key.

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?

No usage guidance is provided about when to choose this tool over alternatives such as monapay_rotate_key or mail_api_key_create. The description implies it is for obtaining a new client_secret but gives no conditions, exclusions, or context about when generation is appropriate.

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

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

With no annotations provided, the description carries the full burden. It clearly states the output is sample code with HMAC verification and a sample payload, but it does not explicitly disclose that the tool only returns code and does not create, modify, or register a webhook endpoint or send a test request.

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 a single bilingual sentence with no filler. It front-loads the core purpose and packs the key details, supported languages and HMAC verification, into compact form.

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 simple one-parameter code-snippet tool, the description covers the main facts a caller needs: the output kind, supported languages, HMAC verification, and sample payload. It could be slightly more complete by noting the tool has no side effects and does not configure an actual webhook, but the gap is minor.

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?

There is only one parameter, language, and schema description coverage is 0%. The description compensates by listing the supported languages (PHP, Node, Python), matching the enum values, but it does not explain any behavioral differences between language choices or how the response might vary.

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 names a specific verb ('Trả code mẫu' / get) and a specific resource (webhook receiver endpoint with HMAC verification) for PHP, Node, and Python. It clearly differentiates this code-generation tool from sibling webhook configuration/management tools such as monapay_create_webhook or monapay_webhook_stats.

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 implies the use case: call this when you need sample receiver code for a MONA Pay webhook. However, it does not explicitly state when not to use it or name alternatives, such as monapay_verify_signature for actually verifying a signature or monapay_create_webhook for registering a webhook.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns authoritative status/details and positions it as a server-side verification step, which is useful behavioral context. However, it does not explicitly state that it is read-only, whether it has side effects, or what happens for invalid or expired checkout IDs.

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 short, front-loaded with the core purpose, and includes a practical usage note. The bilingual repetition is acceptable in this context and every sentence earns its place.

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?

There is no output schema, so the description's mention of 'status and details' is the main return-value information, which is broad but adequate for a simple single-parameter get-by-ID tool. It also supplies the important integration context of checking server-side before delivery. It omits possible status values or error behavior, but those are not critical for basic invocation.

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% and the only parameter, checkout_id, is already documented as 'ID phiên thanh toán' (payment session ID). The description merely repeats 'by ID' without adding format details, constraints, or guidance on where to obtain the ID, so it adds no meaningful value beyond the schema.

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 verb 'get', the resource 'checkout', and the scope 'by ID', and additionally says it returns status and details. This makes it easy to distinguish from sibling tools like monapay_create_checkout, monapay_list_checkouts, and monapay_cancel_checkout.

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 gives a concrete usage context: 'should check server-side before shipping/delivery', which tells the agent when this tool is the right choice. It does not explicitly rule out alternatives or compare with monapay_list_checkouts, but the before-delivery scenario is a clear signal.

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

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

No annotations are provided, so the description carries the transparency burden. The word 'Get' clearly signals a read operation and the returned fields are listed, but it does not explicitly confirm absence of side effects, authentication needs, or error/empty-result behavior.

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: one Vietnamese sentence with useful field details and one short English equivalent. There is no filler, and the key information is front-loaded.

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 zero-input getter with no output schema, the description is mostly complete: it names the resource and the returned fields. It could add minor context such as how this profile relates to monapay_set_payment_profile, but nothing critical is missing for correct invocation.

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 tool has zero parameters and 100% schema description coverage, so no parameter documentation is required. The description adds context about what the result contains, which is enough for a parameterless getter.

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 uses a specific verb ('Get') and identifies the exact resource ('hosted-checkout payment profile'), while the Vietnamese text adds the returned fields: shop name, identification, and default account. This clearly differentiates it from related siblings like monapay_set_payment_profile.

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 verb 'Get' implies this tool should be used when the agent needs to read the current hosted-checkout payment profile. However, it does not explicitly state when to use it over alternatives or mention the setter sibling, leaving usage context mostly implied.

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

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

With no annotations, the description carries the full burden. It usefully discloses that only incoming (credit) transactions are returned and that lookup is scoped to a virtual account, but says nothing about behavior when no match is found, auth requirements, or return shape.

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?

Purpose and use case are front-loaded in the first clause. The Vietnamese and English halves duplicate the same content rather than extending it, which is mild redundancy but keeps the definition short and scannable.

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 two-parameter read tool, the description covers purpose, scope, and usage intent. With no output schema, it could say more about the returned fields, but the verb 'get' plus the incoming-transaction scope make the result predictable enough to call correctly.

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 coverage is 100%, so both parameters are already documented, including the DH10234 example. The description's mention of 'ma don' and 'trong mot tai khoan ao' adds only marginal framing beyond the schema, so the 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?

States a specific verb (get/find) and resource (one incoming transaction) and scopes it by transaction_code or id within a virtual account. The singular 'one incoming transaction' distinguishes it from monapay_list_transactions, but no sibling is named explicitly, so it stops short of full differentiation.

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 a concrete use case — 'use to check whether order X has been paid yet' — which tells the agent when this tool applies. However it offers no exclusions or alternative routing (e.g., when to prefer list_transactions or get_transactions_summary).

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

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

With no annotations, the description carries the full burden. It discloses a key behavioral trait: MONA Pay does not hold funds or maintain a wallet balance, so the output is incoming money into the user's bank account. It also mentions data by day. However, it doesn't cover authentication/scope requirements, rate limits, or whether the range is inclusive.

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 concise, front-loading the core purpose and then the important caveat. The bilingual phrasing is dense but each clause serves a purpose, though the repetition of the 'no balance' point in both Vietnamese and English is slightly 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 the tool has only 2 optional parameters, no output schema, and no annotations, the description provides necessary context about what is returned (totals, transaction count, per-day data) and the important domain fact that there is no wallet balance. It could mention response format or pagination, but overall it's sufficient for correct invocation.

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 coverage is 100%, so start_date and end_date formats (YYYY-MM-DD) are fully documented in the schema. The description adds the concept of a date range but no format or boundary details beyond what the schema 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?

Description specifies the resource (incoming totals over a date range) and adds a critical clarification: MONA Pay holds no wallet balance, so this is not a wallet-balance query. It distinguishes itself from sibling tools like monapay_get_transaction and monapay_list_transactions by focusing on aggregate summaries, though it doesn't name them explicitly.

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 implies usage for date-range summary queries but doesn't explicitly state when to use this versus monapay_list_transactions or other aggregation tools. The negative clarification ('not wallet balance') helps avoid a specific mis-use but doesn't provide full when-to-use guidance.

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

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

With no annotations provided, the description carries the full behavioral burden, and it does well by disclosing that the OTP is sent to the user's phone and that the agent must never guess it. It also clarifies that this step registers the ACB account and VA, which is a meaningful side effect. It does not mention reversibility, permissions, or error states, but the OTP-handling disclosure is critical and well handled.

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 step number and purpose, followed by a critical instruction. The bilingual repetition is somewhat redundant but serves multilingual users and does not obscure the content. Every substantive piece of guidance earns its place.

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 description covers the flow's start and the OTP expectation, but there is no output schema and the description does not say what the tool returns or what data the subsequent verification step will need. It references "the verification tool" without naming it, and it omits information about the remaining steps 2-4. For an agent to complete the multi-step flow reliably, more detail about the response and next tool would be needed.

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 schema already fully documents all seven parameters. The description adds mild contextual value by linking the phone number to OTP delivery, but it does not explain the conditional requirements around bank_account_id, account_number, and phone_number beyond what the schema already provides.

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 a specific verb and resource: "register the ACB account and VA" as Step 1/4, and the title adds "start linking ACB bank and send OTP." It distinguishes itself from the verification sibling by explicitly framing this as the step that precedes OTP verification. This makes the tool's role unambiguous.

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 clear sequential guidance: this is Step 1/4, and after receiving the OTP the agent must ask the user before calling the verification tool. It implies the correct flow and warns against guessing, though it does not explicitly name the verification sibling or state when not to use this tool.

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

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

With no annotations, the description carries the full burden of disclosing side effects. It only explains that the OTP comes from the user's phone and that user consent is required, but it does not disclose that the tool creates an ACB virtual account (only the title mentions this), nor what happens on invalid OTP, whether the OTP is single-use, or what side effects occur. This is a significant transparency gap for a mutating operation.

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 short and front-loaded with the step number and the critical instruction, and it repeats the message in Vietnamese and English for clarity. The repetition is purposeful in a bilingual tool, so there is minimal waste, though the same information is essentially given twice.

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?

There is no output schema and no annotations, so the description should explain what the call accomplishes and what the agent can expect in response. It does not state success/failure behavior, return values, or what step 3/4 entails. The agent is left without a complete picture of the call's outcome.

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 already documents both parameters with 100% coverage. The description adds meaningful value for the 'code' parameter by stating the OTP must be obtained from the user and never guessed, which is a critical semantic constraint not present in the schema. It adds nothing new for 'acb_request_id', but the overall contribution goes beyond the baseline.

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 does not explicitly state a verb+resource; it focuses on the OTP flow and the requirement to ask the user rather than saying 'verify OTP and create ACB virtual account'. The title does provide that purpose, and the step-2/4 context implies the operation, but the description itself is vague about the tool's actual action.

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 gives explicit precondition and prohibition: the agent MUST ask the user before calling and must never guess the OTP. It also positions the call as step 2 of 4, which clarifies when in the flow it should be used. However, it does not name or contrast alternative/sibling tools such as monapay_notification_verify_otp, so it stops short of fully explicit when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Liệt kê' implies a read-only enumeration, but the description does not explicitly state that the operation has no side effects, what it returns, or whether any authentication/authorization constraints apply beyond MONA Pay linkage.

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 minimal and front-loaded with the action and resource. The bilingual phrasing adds a little length but does not introduce filler or ambiguity.

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 zero-parameter, read-only listing tool, the description provides enough context to invoke it correctly: it names the resource, the platform, and the operation. The main gap is the absence of an output schema means the description could be slightly more explicit about the returned account fields, but this does not prevent correct invocation.

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 zero properties and 100% description coverage, so there are no parameters to explain. A baseline of 4 is appropriate for a no-parameter tool; the description correctly implies that no inputs are required.

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, 'Liệt kê' (list), and a specific resource: bank accounts linked to MONA Pay. It is specific enough to distinguish this tool from siblings like monapay_list_virtual_accounts, monapay_list_transactions, and monapay_link_bank_start. The 'ACB…' example reinforces that these are real connected bank accounts.

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 gives clear context: use this tool to retrieve bank accounts already linked to MONA Pay. It does not explicitly name alternatives or state when not to use it, but the resource scope is clear enough for a simple zero-parameter listing operation.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only restates the filter dimensions already visible in the parameter names. It does not disclose pagination defaults, result ordering, whether from_date/to_date are inclusive, timezone handling, or what happens when filters are omitted — key unknowns for a fully-optional-parameter list tool.

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 a single front-loaded sentence starting with the verb, with no filler. The only mild inefficiency is that the Vietnamese and English halves partially duplicate each other, though each contributes one distinct piece ('filter dimensions' in Vietnamese, 'hosted' qualifier in English).

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?

This tool has no output schema, no annotations, and zero parameter documentation, making the description the sole documentation; it does not cover the response shape, pagination defaults, or filter semantics. An agent would understand what the tool does but not what to expect back or how optional filters behave when omitted.

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 0% schema description coverage, the description is the only semantic layer for the parameters and it maps each parameter cluster to a concept: trạng thái→status, mã đơn→order_code, khoảng ngày→from_date/to_date, phân trang→page/limit. However, it adds no depth beyond these labels — no default values, no date-format or range-boundary semantics, and no note on how filters combine.

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 uses a specific verb ('Liệt kê' / 'List') with a clear resource ('hosted checkouts') and enumerates the filter dimensions: status, order code, date range, and pagination. The 'list' verb and 'hosted checkouts' qualifier distinguish it from siblings such as monapay_get_checkout (single retrieval), monapay_create_checkout, monapay_cancel_checkout, and other resource-different list tools (transactions, webhooks, bank accounts).

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 tool's role as a list/filter operation is implied by the description, and the listed filter dimensions give context for when it applies (finding checkouts by status, order code, or date). However, there is no explicit guidance on when not to use it or which sibling to prefer instead — e.g., monapay_list_transactions for payment transaction history or monapay_get_checkout for a single checkout.

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

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

With no annotations, the description carries the full burden. It conveys non-mutating behavior through 'List' and reveals that the output includes recipient verification status, but it does not disclose auth needs, scope, pagination, or any side-effect guarantees beyond what 'list' implies.

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 a single compact sentence in two languages with no filler. The operative verb and object appear immediately, and the recipient-verification detail is appended without redundancy.

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 zero-parameter, non-mutating list tool, the description is sufficient to invoke: it names the resource and the notable output trait. It would be stronger with explicit return-shape or scope details, but the absence of parameters and output schema keeps the needed context small.

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 zero parameters, so the baseline is 4 and there are no parameter semantics for the description to clarify. The description instead clarifies the output domain (configs plus verification status), which is the relevant context.

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 uses a specific verb (Liệt kê/List) with a concrete resource (email notification configs) and adds a distinguishing scope detail (recipient verification status). Among the email-config siblings, this clearly identifies the read-only listing operation rather than create/update/delete/verify/test.

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 intended use is implied by the verb and resource: an agent should call this when the user asks to see email notification configs or their recipient verification state. It does not, however, name alternatives or state when not to use it, so there is no explicit routing guidance.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It adds useful context by defining what suppression means (bounce, complaint, manual), which goes beyond the bare tool name. However, it does not disclose the output shape, whether reasons are returned per address, pagination behavior, or that this is a non-destructive read — though the verb 'list' weakly implies it.

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 parallel clauses — Vietnamese and English — with the verb front-loaded and the suppression-cause taxonomy adding genuine value. The bilingual duplication is mild redundancy but serves a dual-language user base; nothing extraneous is present.

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?

Adequate for a simple zero-parameter list tool, but the crowded sibling set makes the missing differentiation material. The description does not clarify the scope boundary versus `mail_suppressions_list`, nor hint that results can be cleaned up via `monapay_remove_email_suppression`. For such a small tool, the core meaning is covered but the surrounding workflow context is not.

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 tool has zero parameters with 100% schema coverage, so there is nothing for the description to explain. Baseline 4 applies because no parameter documentation is needed; the description correctly implies a parameterless list operation.

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 clear verb ('Liệt kê' / 'List') and resource (suppressed recipient addresses), and even adds the suppression causes: bounce, complaint, or manual. However, it does not differentiate itself from the near-identical sibling `mail_suppressions_list`, leaving ambiguity about which list tool applies in which context.

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?

No guidance is given on when to use this tool versus alternatives. With `mail_suppressions_list` as a sibling and `monapay_remove_email_suppression` being the natural follow-up action, the description does not say when to choose this over `mail_suppressions_list` or when to pair it with the removal tool. Usage context is only implied by the monapay prefix.

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

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

With no annotations provided, the description carries the full burden, and it does disclose real behavior: filtering by virtual account, pagination capped at 100 per page, and incoming-only scope. But it omits ordering of results, whether pending/failed transactions are included, and any read-only guarantee — details that matter for a reconciliation workflow.

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 Vietnamese sentence is efficient and front-loaded with verb+resource+scope, with every clause earning its place. The trailing English fragment 'List incoming transactions' adds nothing beyond the title and is mild redundancy, preventing a 5.

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 simple 3-parameter list tool with no output schema and no annotations, the description covers the essentials: what is listed, the required filter, the pagination cap, and the reconciliation use case. Gaps remain: no indication of return shape, no transaction-status semantics, and no disambiguation from monapay_list_checkouts, which an agent might confuse it with.

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 only 33% (only virtual_account_number is documented), so the description must compensate. The pagination clause ('phân trang tối đa 100/trang') explains the limit/page semantics beyond the bare schema, but it does not explicitly define what 'page' means or how results are ordered, and it partly duplicates the schema's maximum:100 constraint.

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 ('Liệt kê' / list), a concrete resource (incoming transactions — 'giao dịch tiền vào'), and the scoping dimension (by virtual account). This distinguishes it from sibling tools like monapay_list_checkouts and monapay_list_webhooks without needing to open the schema. It falls short of 5 because it never names a sibling to contrast against.

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 phrase 'dùng để đối soát' (used for reconciliation) provides an explicit use case, which is genuine context an agent can act on. However, there is no guidance on when NOT to use it or which alternative to choose (e.g., monapay_list_checkouts for order-facing transactions), leaving selection among the many monapay list_* tools to inference.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. 'List' clearly signals a read-only, non-destructive operation, which is the most important behavior. However, it does not mention pagination, response format, authentication requirements, or any limitations such as whether the result is ordered or capped.

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 a single bilingual sentence with no filler or repetition. It front-loads the verb and resource, and the English version clarifies the Vietnamese without adding unnecessary length.

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 tool with one fully documented parameter and no output schema, the description is nearly complete: it states the action, the resource, and the scope. The only minor gap is the absence of any comment about result shape or pagination, but the low complexity of this list operation makes that a small omission.

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 schema already fully documents bank_account_id, including where to obtain it from monapay_list_bank_accounts. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 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 ('List') and a precise resource ('virtual accounts of a bank account'), making the operation immediately identifiable. It inherently distinguishes this tool from sibling list operations such as monapay_list_bank_accounts by making clear it lists virtual accounts scoped to a bank account, not bank accounts themselves.

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 implies the use case: when an agent needs virtual accounts belonging to a specific bank account. The parameter schema additionally points the agent to monapay_list_bank_accounts as the source of bank_account_id, which helps with prerequisites, but the description itself gives no explicit when-to-use or when-not-to-use guidance compared to alternative tools.

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

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

With no annotations, the description carries the full behavioral burden, and 'list' communicates a read-only retrieval with no side effects. It does not describe return format, pagination, or permissions, but for a zero-parameter list operation this is minimally adequate.

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 short and front-loaded with the action and resource. The Vietnamese and English versions duplicate the same information, but the redundancy is minor and the entire description fits in one compact line.

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 zero-parameter list tool, the description is sufficient to select and invoke the tool. It is less complete for post-call interpretation because there is no output schema and the description does not describe response fields, pagination, or how it differs from webhook stats/logs tools.

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 zero parameters and 100% schema coverage, so there are no parameter semantics for the description to add. The baseline of 4 for zero-parameter tools 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?

The description states a specific action ('Liệt kê / List') on a clear resource ('webhook configs'), so an agent knows exactly what this tool returns. It also distinguishes the tool from sibling webhook tools that create, update, delete, test, log, or collect stats on webhooks.

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 intended use is implied: call this when the agent needs to see the list of configured webhooks. However, it does not explicitly state when not to use it or point to closely related alternatives such as monapay_webhook_stats or monapay_webhook_logs.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does communicate that the operation is a non-destructive listing filtered to groups with the Gấu Mona bot — a genuinely useful behavioral fact. However, it does not disclose output shape, empty-result behavior, or what happens when no qualifying groups exist, which matters more given there is no output schema.

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 clauses with zero waste: the first front-loads the verb and resource, the second appends the constraint. Nothing repeats the title verbatim, and every word earns its place.

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 zero-parameter, no-output-schema list tool, the description covers the essentials: what is listed and the inclusion criterion. Small gaps remain — no statement of the tool's practical purpose (e.g., identifying groups that can receive notifications) or guidance for when no groups have the bot — but nothing blocks correct invocation.

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 tool has zero parameters and schema coverage is trivially 100%, so the baseline of 4 applies per the rubric. The description adds the only relevant context a parameter-less call needs: what the result set contains and under what condition groups are included.

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 pairs a specific verb ('Liệt kê' = list) with a specific resource ('cấu hình thông báo nhóm Zalo' — Zalo group notification configurations), and adds a meaningful scope constraint: groups must have the Gấu Mona bot. This distinguishes it from the sibling mutation tools (monapay_create/update/delete_zalo_group) by its read-list nature, though it does not explicitly name them as the HIGH calibration example did.

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 bot precondition ('nhóm phải có bot Gấu Mona') implies when the tool is applicable and suggests the agent may need to verify bot presence first, but there is no explicit when-to-use vs. when-not-to-use guidance or named alternative. Among five Zalo group siblings (create/update/delete/test/logs), the agent is left to infer that this is the read-only listing option.

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

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

There are no annotations, so the description carries the burden. 'Get' implies a read-only operation and 'đang đăng nhập' indicates the current authenticated account, which is useful. However, the description does not explicitly state side-effect-free behavior, error conditions, or authentication requirements beyond the implication.

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 two short sentences with no filler, and the bilingual wording is front-loaded with the core action. It is concise while conveying the resource, scope, and sample output fields.

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 simple no-parameter profile tool with no output schema, the description is reasonably complete by naming the data it returns (id, tên, trạng thái). It lacks differentiation from sibling tools, but that gap is more about usage guidance than contextual completeness.

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 tool accepts zero parameters, so the description does not need to explain parameter meanings. The baseline for zero-parameter tools is 4, and the description appropriately confirms the operation without inventing parameter details.

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 ('Get') and resource ('current MONA Pay client profile') and even lists the expected fields (id, tên, trạng thái). However, it does not distinguish this tool from the sibling monapay_whoami, which appears to serve the same purpose.

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 gives some context ('đang đăng nhập' / currently logged in) but provides no when-to-use guidance or exclusions. With siblings like monapay_whoami and monapay_get_payment_profile nearby, an agent cannot tell when to choose this tool over those.

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

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

No annotations are provided, so the description carries the disclosure burden. It discloses a key side effect (the bank sends a second OTP to the user's phone) and sets an interaction rule (never guess the OTP). It does not mention idempotency, reversibility, permissions, or failure behavior, so it is above bare but not rich.

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 dense and front-loaded with step and purpose, and the user-querying rule is emphasized. Bilingual duplication adds a little length but remains focused with no 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?

For a one-parameter step with no output schema or annotations, the description gives the essential flow position and interaction requirement. It does not describe the return payload or explicitly list preconditions, leaving some ambiguity for an autonomous agent.

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 coverage is 100%, with the only parameter already documented as coming from monapay_link_bank_verify_otp. The description adds no additional parameter details, so the baseline of 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?

The description clearly states 'Step 3/4: register real-time transaction notifications' with a specific verb ('register') and resource ('real-time transaction notifications'). It also notes that the second OTP is sent by the bank, which distinguishes this registration step from subsequent verification steps.

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 'Bước 3/4 / Step 3/4' prefix positions the tool within a multi-step flow, and the explicit instruction that the agent must ask the user before calling the verification tool ('tool xác thực') gives clear usage context. It does not explicitly name an alternative tool or state when not to use it, but the sequencing is informative.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose a key trait: the tool completes a money-receiving flow using a code only the user possesses, and the agent must not fabricate it. However, it does not disclose the operation's side effects (finalizing/irreversibly completing the transfer), error behavior on a wrong code, or retry implications — meaningful gaps for a financial step.

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?

A single bilingual sentence, front-loaded with the critical guardrail and free of fluff; the VI/EN duplication is a deliberate localization choice, not redundancy. The step marker 'Bước 4/4 / Step 4/4' precedes the rule, placing the highest-value information first.

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 2-parameter tool with a fully documented schema, the essentials are present: what to collect (user-provided OTP plus request ID), when to call (step 4/4, only after asking), and the outcome in the title. Missing is any guidance on failure behavior — what happens if the OTP is wrong, whether retries are allowed, or that calling this completes a financial transaction — which matters more given there are no annotations and no 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?

Schema coverage is 100% — both parameters are described with provenance (code comes from the user after receiving from ACB; acb_request_id comes from monapay_notification_register). The description adds a normative rule beyond the schema by forbidding OTP guessing and requiring user confirmation, which directly sharpens the semantics of the code parameter. Baseline 3 raised to 4 for that added constraint.

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 title states the action plainly ('Xác thực OTP lần 2 và hoàn tất nhận tiền' — verify the second OTP and complete receiving money), and the description anchors the tool as step 4/4 of a bank-OTP flow. The 'lần 2' qualifier plus the acb_request_id linkage to monapay_notification_register distinguishes it from the bank-linking OTP sibling, though not explicitly.

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 gives an explicit invocation condition: the agent MUST ASK the user for the OTP before calling and must never guess it — a strong, actionable rule for a fraud-sensitive step. It also positions the call as step 4/4, implying it follows monapay_notification_register. It does not explicitly name alternatives or state when not to use it (e.g., monapay_link_bank_verify_otp for the separate bank-linking flow).

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

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

With no annotations, the description carries the full disclosure burden and does well: it says what is checked (bank linked, VA present, webhook configured) and what is returned (next steps + recipe). It stops short of stating that the call is read-only with no side effects and requires no permissions setup, which would fully close the gap.

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?

Content is front-loaded and the key action ('call this first') leads. However, the entire description is duplicated verbatim in Vietnamese and English, roughly doubling length without adding informational value for a single reader.

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 zero-parameter onboarding/router tool with no output schema, the description covers purpose, trigger intent, ordering, and the shape of the return (state check + next steps + recipe). The main remaining gap is not clarifying that the call has no side effects, but overall it is sufficient to invoke correctly.

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 tool takes zero parameters, so the schema has nothing to document and the baseline is 4. No parameter meaning needs to be conveyed, and the description correctly focuses on behavior instead.

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 function: it is the entry point for the 'receive bank transfers' intent, checks account state (bank/VA/webhook), and returns concrete next steps plus an end-to-end recipe. This is clearly distinguishable from siblings like monapay_me, monapay_list_bank_accounts, or monapay_list_webhooks, which only report a single slice of state.

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?

Explicitly instructs to call this tool FIRST ('Goi tool nay TRUOC') for the receive-transfers intent, giving clear ordering guidance. It does not name specific alternative tools or state when NOT to use it, but the 'before anything else' framing covers the main routing decision.

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

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

With no annotations, the description carries the full burden. It usefully discloses the consequence of the action — re-enabling sends and shifting responsibility to the client — which is real behavioral context beyond the name, but it omits permissions required, whether the removal is reversible, behavior when the address is not suppressed, and the response shape.

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?

Both sentences are front-loaded and earn their place — the second carries the responsibility caveat. The bilingual duplication roughly doubles the text for the same content, which is the only structural inefficiency.

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 one-parameter mutation tool with no annotations and no output schema, the description covers purpose, precondition, and consequence. It is still missing auth requirements, reversibility, and error behavior, leaving meaningful gaps an agent would want before calling it.

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 single parameter is undocumented in both schema (0% description coverage) and description, but the schema supplies a format constraint and a regex pattern that make 'email' self-explanatory. The description adds no parameter-level detail, so this sits at the minimum-viable baseline rather than compensating for the coverage gap.

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 and resource ('Remove a suppression') and names the object precisely, so an agent can distinguish it from the read-only sibling monapay_list_email_suppressions. It does not explicitly name that sibling, so it falls short of the top score.

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?

It gives a clear precondition for use ('after fixing its cause'), which tells the agent when this tool is appropriate rather than merely what it does. It stops short of naming alternatives or stating when not to use it, so it is context without exclusions.

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

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

With no annotations, the description carries full behavioral burden and does disclose a genuinely useful trait: a limit of five requests per address per hour. It omits other behaviors a caller would want, such as whether the previous code is invalidated, what error surfaces when the limit is hit, or whether the config_id must already exist.

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?

Front-loads the action and appends the rate limit in one tight sentence, though the full bilingual duplication repeats identical content for no additional information gain.

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 two-param mutation tool with no annotations and no output schema, the description covers purpose and the rate constraint but leaves the success/failure outcome and config prerequisites unstated.

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 coverage is 50% (email has only format/pattern, no description; config_id is documented). The description partially compensates by naming both concepts - an address and a config - but adds no format or identity detail beyond what the schema already encodes.

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?

Names a specific verb (resend) and resource (email verification code) with an added scoping detail ('tới một địa chỉ trong cấu hình'). An agent can distinguish it from monapay_verify_email (which validates a code), but the description never explicitly routes against that sibling.

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?

Implies the scenario of re-issuing a code when the user didn't receive one and states the rate ceiling, but gives no explicit when-to-use/when-not guidance or named alternative among the many email-config siblings.

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

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

With no annotations, the description carries the full burden. It discloses the key behavior—re-sending a webhook/Telegram notification—but it does not mention side effects such as duplicate delivery, prerequisites, or whether the action is reversible. This is enough for the core action but lacks deeper behavioral context.

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 a single direct sentence repeated in Vietnamese and English, with no filler. It is appropriately sized for a simple retry operation.

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 tool has 3 parameters, no output schema, and no annotations, yet the description only covers the general purpose. It omits the meaning of target_id, the default target_type behavior, and what the response indicates about success or failure, so an agent has to guess at a non-trivial part of invocation.

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 0%, so the description must compensate. It maps target_type to 'webhook/Telegram' and transaction_id to 'transaction', but it says nothing about target_id, the default target_type behavior, or what happens when target_id is omitted. This leaves important invocation details undocumented.

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 ('Re-send') and a specific resource scope ('webhook/Telegram for a transaction'), which is distinct from sibling tools like monapay_test_webhook or monapay_sandbox_transaction. The bilingual text reinforces the same clear purpose.

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 phrase 'cho giao dịch đã có / for a transaction' implies the tool is for existing transactions, so an agent can infer when to use it. However, it gives no explicit guidance about when not to use it or which sibling would be a better alternative for testing or creating notifications.

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

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

With no annotations, the description carries the full burden and does a good job: it discloses the rotational nature of the operation, the required X-Client-Secret, and the operational consequence that MONAPAY_CLIENT_SECRET must be updated and the plugin/agent restarted. It could more explicitly state that the old secret is immediately invalidated, but the implication is strong enough.

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 trigger condition. Both languages add value and there is no filler; every sentence earns its place.

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 zero-parameter tool, the description covers the trigger, the mechanism, and the required post-step. However, since there is no output schema, it does not explain what the response returns—specifically how the new secret is conveyed—even though updating MONAPAY_CLIENT_SECRET implies the response provides it. This leaves an implicit gap.

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 zero parameters, so the baseline is 4. The description adds useful context about X-Client-Secret and MONAPAY_CLIENT_SECRET, though these are not formal parameters.

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 action: rotate the current API key secret after suspected exposure. It is specific about the resource (API key secret) and the trigger condition, but it does not explicitly differentiate from the sibling monapay_generate_key, so it misses the top score.

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?

It explicitly states when to use the tool ('Dùng khi secret nghi lộ' / 'after suspected exposure') and gives a mandatory follow-up step: update MONAPAY_CLIENT_SECRET and restart. It does not mention alternatives or explicit when-not-to-use conditions, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses auto-creation of a sandbox VA, recording of the transaction, sending a signed webhook, delivering Telegram/email/Zalo notifications, matching checkouts like real money, and not counting toward limits.

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 main Vietnamese sentence is dense but every clause carries useful behavioral information. The English summary is somewhat redundant, but it provides a concise cross-language anchor and helps agents recognize the tool's core purpose quickly.

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 low-complexity tool with all-optional parameters and no output schema, the description covers the trigger, side effects, bank-link behavior, and checkout impact well. The main gap is that it does not describe what the caller receives in response, but that is not critical for safe invocation given the strong behavioral disclosure.

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 67%, and the schema already documents `description` and `virtual_account_number` well, including the auto-VA behavior. The tool description adds little parameter-specific meaning beyond what the schema provides, and `amount` still lacks an explicit semantic description, though its default and bounds are present.

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 action and resource with 'Tạo một giao dịch tiền vào GIẢ' and 'Create a fake incoming transaction in the sandbox.' It also differentiates itself from real-payment transaction tools by emphasizing sandbox, fake, and no-cost behavior, making it distinct from siblings like monapay_retry_transaction and monapay_list_transactions.

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 implies the tool is for testing incoming payments: it explains that without a linked bank, MONA Pay auto-provisions an SBX sandbox VA, and that the transaction matches a checkout like real money. However, it does not explicitly state when to use this tool instead of other MONA Pay tools, nor does it give any exclusion criteria.

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

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

No annotations exist, so the description carries full burden. It does disclose one genuinely useful behavior: the redirect signing secret is returned by the API only once. But for a 15-parameter mutation tool it omits auth/permission requirements, whether unspecified fields are cleared on update, and the response shape.

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 sentences, front-loaded with the action and its timing, and the secret caveat is appended where it matters. The Vietnamese/English duplication is the only padding, but it serves the bilingual audience.

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 15 parameters, 0 required fields, no output schema, and no annotations, the description is far too thin. It never clarifies which fields are needed for a first-time create versus an update, nor what the one-time secret return means operationally for the caller.

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 only 7% (just logo_url), and there are 15 parameters. The description groups them conceptually (name, identity, default receiving account) but explains none of the individual fields such as merchant_id, terminal_id, va_prefix, owner_type, or the two default account IDs, so it fails to compensate for the schema gap.

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 pair ('create or update') and resource ('hosted-checkout payment profile'), and enumerates the conceptual contents (shop name, identity, default receiving account). The upsert framing distinguishes it from the sibling monapay_get_payment_profile, though that contrast is only implicit.

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?

'trước khi tạo checkout' / before creating checkout gives timing context that implies when to reach for this tool. However, no alternative is named, no when-not guidance is offered, and it never states what prerequisites (e.g. linked bank account) must exist first.

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

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

With no annotations, the description carries the behavioral burden. It clearly discloses that the action sends a sample/test notification to recipients already verified within a config, which is a meaningful side-effect warning since these are not arbitrary addresses. It does not describe the return value or failure modes, but the core behavior and target are explicit.

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 entry is a single bilingual sentence with no filler; the verb and recipient constraint come first, making it easy to scan. Both languages carry the same content, but this is a deliberate bilingual format rather than redundancy.

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 one-parameter tool with no output schema, the description covers what the tool does, who is targeted (verified recipients), and how it is scoped (via a config). It could add expected results or error conditions, but the essential selection and invocation information is present.

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 coverage is 100%, and the single config_id parameter is already described as 'UUID cấu hình email'. The description adds 'in a config' but no new syntax, format, or value semantics beyond the schema, so the baseline score of 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?

The description uses a specific verb ('Send') and identifies the resource ('test notification'/'email mẫu') and the recipient scope ('verified recipients in a config'). This clearly distinguishes it from sibling test tools such as monapay_test_webhook and monapay_test_zalo_group, and 'test/sample' signals it is not a production send.

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?

No explicit when-to-use or when-not-to-use guidance is provided, and no alternative tool is named. The word 'test' implies the tool is for validating an email config, but the agent is left to infer when to choose this over related send/test tools such as mail_send or monapay_test_webhook.

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

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 transparently reveals that a fake transaction (is_dummy) is sent to the URL and that the goal is endpoint/signature testing. However, it does not mention whether the test creates logs, whether it requires a saved webhook config, what side effects occur on MONA Pay, or what the caller receives back.

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 one compact sentence with the core purpose front-loaded. The English translation 'Send a dummy webhook' is largely redundant, but it does not add significant noise. It is appropriately sized for a straightforward test action.

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?

There is no output schema, so the description should indicate what result the agent can expect—such as HTTP status, delivery success, or signature validation outcome. It does not. It also leaves the roles of auth_type, secret_key, and the saved-config fallback to the schema, making invocation details under-specified.

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 only 33%: only webhook_url has a description, and it is in Vietnamese. auth_type and secret_key are undocumented in both the schema and the tool description; the agent can only infer they relate to signing from the signature-testing phrase. With low schema coverage, the description needed to explain these parameters but did not.

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: MONA Pay sends a dummy webhook (is_dummy) to a URL to verify the endpoint and chữ ký (signature). This clearly identifies the resource and purpose. However, it does not explicitly distinguish it from sibling tools such as monapay_sandbox_transaction or monapay_verify_signature, so it stops one step short of full differentiation.

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 phrase 'để kiểm tra endpoint + chữ ký' gives an explicit use context: use this tool when you need to test whether a webhook endpoint receives and validates signatures. It does not mention exclusions or name alternative tools, but the scene is clear enough for an agent to decide when this tool fits.

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

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

No annotations are present, so the description carries the full disclosure burden. It does disclose two behavioral constraints: the bot must exist in the group and Markdown will not be parsed. However, it does not mention that this sends a real visible message to the group or what success/failure looks like.

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?

One compact sentence delivers action first, then prerequisite and rationale. There is no filler, no repetition of schema content, and every clause earns its place.

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 test tool, the essential context is present: what it does, the required group precondition, and why only plain text is supported. Missing return-value or side-effect detail is a minor gap given the simple schema and absent 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?

Schema description coverage is 100%; the id parameter is already documented as the MONA Pay Zalo group configuration ID (UUIDv6). The description adds no parameter-level information, so the 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?

The description states a specific action: send a test plain-text message to a Zalo group ('Gửi tin thử text thuần'), and the second clause confirms the group context. 'Thử' plus the text-only constraint clearly differentiates it from the Zalo group create/update/delete/list/log siblings.

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?

It provides actionable usage context: the target group must contain the Gấu Mona bot, and the message must be plain text because Zalo does not render Markdown. It does not explicitly name alternative tools, but there is no direct sibling for sending a test Zalo message, so the prerequisite is sufficient guidance.

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

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

No annotations are provided, so the description carries the full disclosure burden. It usefully reveals the post-update activation caveat about recipient verification, but omits permissions required, whether the update is partial (all five fields are optional) or a full replacement, and what happens to unspecified fields.

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 compact sentences with the primary purpose front-loaded and the caveat second. The Vietnamese/English mirroring is a deliberate localization choice rather than padding, though it does roughly double the token footprint.

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?

With no output schema and no annotations, a mutation tool over six parameters at 33% coverage needs more than it gets. The verification caveat is the strongest addition, but PATCH-vs-PUT semantics, response shape, and authorization expectations remain unaddressed.

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 coverage is only 33% (only config_id and virtual_account_id carry descriptions), so the description is expected to compensate. It does enumerate the updatable fields, mapping loosely onto name, recipients, events, virtual_account_id, and is_active, but adds no format, enum, or constraint detail (e.g. the TRANSACTION_IN/WEBHOOK_FAILED/VA_CREATED event set or the 10-recipient cap).

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 ('Update') and resource ('an email config') and enumerates the mutable fields (name, recipients, events, VA, active status), which clearly separates it from siblings like create_email_config, delete_email_config, and list_email_configs. It stops short of explicitly naming those alternatives, so it lands just below the top tier.

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?

It provides one meaningful precondition – new recipients must be verified before the config becomes active – which is real usage guidance. However, it never names the relevant sibling tools (monapay_verify_email, monapay_resend_email_verification) or states when to choose update over delete/recreate, leaving the workflow routing implicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool updates fields like URL, secret, and active status, but it does not disclose whether updates are partial or full replacement, what happens if the config_id is invalid, whether secret keys are returned or write-only, or what effects the update has on live webhook delivery.

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, using a parenthetical to list the main updatable aspects and a bilingual sentence to reinforce the purpose. The duplication between Vietnamese and English costs some efficiency, but overall the description is appropriately brief for its clarity.

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 mutation tool with 9 parameters, no annotations, and no output schema, the description is far too sparse. It does not mention the required config_id parameter, the available auth types, payload formats, or what the tool returns upon success. An agent would struggle to know exactly how to construct a valid update request without additional information.

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 0%, so the description must compensate for the 9 undocumented parameters. It provides some mapping for webhook_url, secret_key, and is_active, but it omits important parameters like config_id, auth_type, api_key_name, payload_format, and virtual_account_id, leaving the agent without semantic guidance for those fields.

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 tool updates an existing webhook config and gives concrete examples of what can be changed (URL, secret, enable/disable). It distinguishes itself from create/list/delete webhook siblings through the explicit 'update' verb, though it could more explicitly separate itself from the delete/test sibling 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?

There is no guidance on when to use this tool versus alternatives like monapay_create_webhook or monapay_delete_webhook. The verb 'update' implies modifying an existing webhook, but no context is given about prerequisites, such as needing an existing config_id, or when creation would be more appropriate.

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

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

No annotations are provided, so the description carries a heavier burden. It tells the agent that this is an edit/update operation, but it does not disclose update semantics (partial vs full replacement), permissions, reversibility, effects of omitted fields, or expected response. The Markdown constraint is useful but is more parameter guidance than tool behavior.

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 a single efficient sentence that leads with the core action and packs two actionable constraints without unnecessary words. It is concise while still adding useful context.

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 mutation tool with 7 parameters, no output schema, and no annotations, this description is incomplete. It does not explain update behavior, what virtual_account_id represents, what the event values control, or what happens after a successful update. An agent could invoke it but would be guessing about several key fields.

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 only 43%. The tool description adds context for group_id (source) and message_template (no Markdown), but events, is_active, friendly_name, and virtual_account_id receive no meaningful explanation beyond their names and schema types. This is a significant gap for a config-update tool.

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 verb ('Sửa' = edit) and resource ('cấu hình nhóm' = group configuration) for a Zalo group containing the Gấu Mona bot. This is distinguishable from the create/delete/test/list sibling tools, though it does not explicitly name a sibling.

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 gives practical constraints: group_id comes from MONA Account/PMS and message_template must be plain text because Zalo does not parse Markdown. However, it does not explicitly state when to use this tool versus alternatives like monapay_create_zalo_group or monapay_delete_zalo_group.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses input provenance and the no-guessing constraint, but says nothing about failure behavior, retry/attempt limits, idempotency, or what a successful verification changes for the recipient — meaningful gaps for a state-changing verification call.

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 with the constraint front-loaded and zero filler; the only cost is the duplicated Vietnamese/English rendering, which is defensible for i18n but doubles the surface text.

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?

There is no output schema and no annotations, so the description is the only source of behavioral context, and it omits what a success or failure returns and how errors should be surfaced. For a three-required-parameter verification mutation it is adequate but leaves the agent guessing about outcomes.

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 schema already documents code, email and config_id; the baseline is 3. The description reinforces that the code is user-supplied and exactly 6 digits, but adds no format or provenance detail for email or config_id beyond what the schema already states.

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 (verify) and resource (a recipient / pending email address) plus the exact credential required (the 6-digit code). It is distinguishable from the OTP-verify siblings (monapay_notification_verify_otp, monapay_link_bank_verify_otp) by naming the recipient email context, though it never explicitly names those alternatives.

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 a concrete operating rule: the code must be supplied by the user and must never be guessed, which tells the agent how to obtain the input before calling. It stops short of stating when to use this versus monapay_resend_email_verification (e.g. when no code has arrived) or when verification is not appropriate.

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

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

With no annotations and no output schema, the description carries the behavioral burden. It delivers genuine value by disclosing the HMAC-SHA256 algorithm and the no-network-call behavior. However, it does not disclose what happens on signature mismatch (return false vs. error), the return shape, or how the timestamp tolerance rules behave.

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 (~25 words) and front-loads the algorithm, purpose, inputs, and offline trait in the first sentence. The second English sentence is largely redundant with the first, adding only the 'locally' gloss, so there is minor waste, but overall it is well-sized.

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 tool with no output schema, no annotations, and 0% parameter descriptions, the description should specify the return value on success/failure and how raw_body must be formatted (e.g., exact HTTP body vs. parsed JSON). The description explains the computation at a high level but leaves the agent unable to predict the tool's response, which is a significant gap for a verification utility.

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 0%, so the description must compensate. It adds real semantics by showing how raw_body, timestamp, and secret combine into the HMAC computation, and signature is implied by 'so chữ ký'. However, tolerance_sec and skip_time_check are left entirely to their self-descriptive names, which is thin compensation for the 0% schema coverage.

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 names a specific verb (verify), a specific resource (MONA Pay webhook signature), the exact algorithm (HMAC-SHA256), and the input composition (raw body + timestamp + secret). The added 'offline'/'không gọi mạng' trait clearly differentiates it from network-triggering siblings like monapay_test_webhook and monapay_generate_webhook_snippet.

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 offline/local framing gives implied usage context: use this to verify a signature without making network calls. However, it never explicitly names alternatives or states when NOT to use it, leaving the agent to infer the boundary against siblings like monapay_test_webhook.

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

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

With no annotations, the description carries the full burden; it does disclose that each log entry contains the HTTP code, response time, and error label of a send attempt, which is genuinely useful behavioral context for a read-only list tool. However, it does not disclose pagination defaults/limits, date-range semantics, or explicitly confirm these are outgoing delivery attempts to configured webhooks.

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 two short clauses totaling well under 20 words, with the core concept ('webhook delivery logs') front-loaded in English followed by the richer Vietnamese detail. The bilingual repetition is mildly redundant but each clause is compact, specific, and scannable.

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 simple 5-parameter read-only list tool, the description conveys the core return content (HTTP code, response time, error label), which partially offsets the missing output schema. It omits pagination behavior, to_date format, whether logs span all configured webhooks, and the default state of the status filter, so an agent still faces small but real ambiguities.

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?

Only from_date ('YYYY-MM-DD') is documented in the schema, so coverage is 20%; the description compensates with nothing — it names no parameter and explains no filter or pagination semantics. page, limit, status, and to_date meanings must be inferred from their names, and the to_date format is left unspecified.

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 specifies both the resource ('webhook delivery logs') and the content of each record ('HTTP code, response time, error label'), clearly identifying this as a list of individual delivery attempts. It is implicitly distinguishable from monapay_list_webhooks (webhook configurations) and monapay_webhook_stats (aggregate statistics) by subject matter, though it never names them.

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?

No when-to-use guidance appears anywhere in the description — it does not say when to prefer this over monapay_webhook_stats or monapay_list_webhooks, nor does it state any exclusions or prerequisites. An agent must infer routing from the tool name and the terse content list.

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

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

With no annotations and no output schema, the description carries full responsibility for behavioral disclosure. It does reveal the key output dimensions (success rate, P95, error classification), which is meaningful. However, it omits important traits such as whether the data is read-only, what time range is covered, whether it aggregates all webhooks or a subset, and what the response structure looks like.

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 extremely concise: a short Vietnamese phrase listing the metrics followed by an English translation. Every word adds value, and the key information is front-loaded. There is no repetition or 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?

For a zero-parameter stats tool, the description names the three most important metrics, but it leaves gaps around the aggregation period, scope (which webhooks are included), and the exact output format. Since there is no output schema or annotation, these omissions could lead an agent to misinterpret the data or make wrong assumptions about the returned payload.

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 is empty and there are zero parameters, so there are no parameter semantics to document. The baseline of 4 applies because the description does not need to add parameter meaning, and it doesn't introduce any confusing parameter-related text.

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 resource (webhook stats) and lists concrete metrics (success rate, P95, error classification), which clearly communicates what the tool provides. It also differentiates from sibling tools like monapay_webhook_logs, which focus on raw logs. However, it uses a noun phrase ('Webhook delivery stats') rather than an explicit verb like 'get' or 'retrieve'.

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?

No usage guidance is provided. The description does not explain when to choose this tool over alternatives such as monapay_webhook_logs or monapay_email_stats, nor does it mention any prerequisites or filtering context. An agent must infer usage entirely from the name and metric list.

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

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

With no annotations provided, the description carries the burden of explaining behavior. It states that the tool confirms active credentials and returns account name and plan, which conveys the read-only, informational nature of the operation. It does not elaborate on error behavior or auth context, but for a simple whoami tool the core behavior is adequately disclosed.

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 two short sentences covering both Vietnamese and English, with no wasted words. It front-loads the key action and the expected return values, making it easy for an agent to parse quickly.

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 simple, zero-parameter whoami tool, the description is complete: it states the purpose, the verification behavior, and the returned information. There is no output schema, but the description explicitly names what will be returned, so an agent has enough context to invoke and interpret the tool correctly.

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 tool has zero parameters, so parameter semantics are inherently simple. The description adds no parameter-specific meaning because none is needed; the schema already covers everything. Per the baseline for zero-parameter tools, this is appropriately handled.

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 specific action: verify that client credentials are working and return the account name and current plan. It is specific about both the operation and the resource, making it easy to distinguish from the broader sibling set.

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 explicitly frames the tool as a connection/credential verification action, which gives clear context for when to call it. It does not explicitly name alternatives like cloud_whoami or monapay_me, but for a zero-parameter whoami-style tool the usage context is sufficiently clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It communicates a lookup/filter operation but does not state the return format, pagination behavior, whether results are limited to a specific Zalo group, or any other side effects or limitations.

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 one concise, front-loaded sentence with no wasted words. It could be slightly more structured by mapping behavior to parameters, but it is appropriately brief for a simple logs-lookup tool.

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 simple two-optional-parameter log retrieval tool, the description conveys the core purpose and the status filter. However, with no output schema and no return-value explanation, the agent is left to infer what the response contains and how the 'limit' parameter behaves.

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 0%, so the description needed to explain both parameters. It only paraphrases the status filter ('lọc trạng thái thành công hoặc thất bại'), which largely restates the enum, and it says nothing about the 'limit' parameter or its default behavior.

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, 'Tra lịch sử gửi vào nhóm Zalo' (query send history to Zalo groups), with a clear resource and filter behavior. It is distinguishable from sibling tools like monapay_list_zalo_groups, though it does not explicitly name the alternative it is not.

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 gives no guidance on when to use this tool versus related tools such as monapay_email_logs, monapay_webhook_logs, or monapay_list_zalo_groups. There are no exclusions, prerequisites, or selection criteria provided.

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