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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false. The description adds genuinely new context beyond that: the referral-fee disclosure, the unlicensed-referrer status, the licensed HK broker arrangement, and the mainland-visitor sales requirement. It restates the read-only nature ('never write, send email or submit') which is somewhat redundant with annotations, but the regulatory disclosures are substantive additions not derivable from structured 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?

The lead sentence is well front-loaded, but the description runs six sentences with redundancy: 'No submission or email sending' is repeated later as 'they never write, send email or submit an enquiry.' Some sentences read as legal boilerplate that crowds out more actionable guidance for the 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 simple one-parameter, read-only lookup with no output schema, the description gives an adequate picture of what it returns and its operational/regulatory boundaries. The main gap is that it never addresses the locale parameter, so an agent cannot know how to use it beyond the enum itself.

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% and the single 'locale' parameter is never mentioned in the description, so the description does not compensate for the coverage gap. The enum values (en, zh-hant, zh-hans) imply a language switch, but the description says nothing about localization or what locale affects. This is a clear miss on the one parameter that exists.

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 first sentence names the specific resource returned (enquiry URL, WhatsApp, WeChat, email) with a clear retrieval verb. It also distinguishes itself from siblings by stating it performs no submission or email sending, unlike action-oriented tools. An agent can tell what this tool yields without opening the schema.

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 clearly frames the usage context ('General information only; no product recommendation, suitability assessment or best ranking'), which steers the agent away from expecting advisory output. However, it never names sibling alternatives (e.g., get_product, compare_products) or states explicitly when to prefer this tool over them, leaving sibling routing implicit.

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