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

Annotations already declare this a safe read, and the description layers on genuinely new behavioral context: rates are indicative mid, rounded, from the market forward curve, and explicitly 'not for execution'. It also dictates the sign convention for forward points and states what each returned field means. That is well beyond what readOnlyHint/destructiveHint convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the trigger and the tenor rule before moving to caveats and return values, and each sentence carries information. It runs long (nine-plus sentences), and the currency-pair example plus field-by-field return list push it toward the verbose end of acceptable.

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 compensates by enumerating forwardRate, forwardPoints, spotMid and settlementDate and explaining the sign of forward points. Combined with the usage path and the 'not for execution' caveat, an agent has everything needed to call and interpret this 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 100%, so the baseline is 3, but the description adds real meaning: the tenor's two accepted forms, the consequence of using a period (curve date can be several days off settlement), and why that mismatch misleads comparisons. Base/quote semantics come from the schema and example rather than new 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 and scope: a forward FX rate taken from the market forward curve, with the spot rate returned for comparison. It distinguishes itself implicitly from get_spot_rate through the explicit 'forward' framing and the forward-points field. It does not explicitly name a sibling, which keeps it short of a 5.

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 when-to-use context ('Use when you need a forward FX rate') and, more usefully, a decision rule for the tenor argument: pick an exact date whenever the forward must line up with a Guard settlement date, because period tenors resolve to the curve's own date. It stops short of naming alternative tools (e.g. get_spot_rate, compare_guard_with_forward) as explicit substitutes.

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