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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds substantial behavioral detail: data source and authority, publication frequency (daily), default window (last 7 days), max range (~1 year per call), the two returned fields (mop_per_unit and market_quote), and the MOP/HKD peg context. This goes well beyond the annotations.

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 but each clause contributes: source, currencies, return shape, defaults, parameters, and sample uses. The main purpose is front-loaded in the first sentence, with operational details following. It's longer than the model two-sentence description, but given the complexity of a multi-currency data tool, the length is justified without being wasteful.

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, the description fully explains the return shape ('one dated row per currency per Macau business day' with the two fields), plus defaults, filtering, and date constraints. It also covers the data source and what kinds of user questions it answers. An agent has everything needed to call this tool correctly and interpret its results.

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 baseline is 3. The description enhances this by explaining defaults for begin/end, the date format constraint, the approximate maximum range, and the comma-separated currency filter with concrete examples. It also clarifies that 'currency' is optional and maps to the example queries, adding operational meaning not fully present in 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 states a specific verb ('Returns') and a specific resource: daily interbank mid exchange rates for the Macau pataca from AMCM, listing ~17 currencies. It is immediately clear what data the tool provides. While it doesn't explicitly name a sibling to distinguish from (e.g., macau_monia), the resource is so uniquely specified that an agent can easily separate it from the broad sibling list.

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 usage context with example natural-language queries ('MOP to USD exchange rate', 'Macau pataca vs RMB last week', '澳門元匯率') and explains parameter-driven filtering and date ranges. It doesn't explicitly discuss when not to use this tool or name alternatives, but the context is strong enough for an agent to decide when to invoke it.

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