price_floating_rate_bond

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

No annotations are provided, so the description carries the full burden, and it discloses real behavior: fixing_days and in_arrears default from the preset, index_id defaults to the preset's, and when coupon_pricer is omitted the tool injects the preset's zero-vol BlackIborCouponPricer. It also defines the four market_data_source modes and forbids estimated/recalled data. Remaining gaps (permissions, failure modes) are minor for a non-mutating pricing 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?

Purpose is front-loaded in one line, followed by a scannable Args list that groups FRN-specific params first and defers shared ones by reference instead of repeating them. The market_data_source entry is long but each mode earns its place because it governs whether the call is even legal.

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 22-parameter tool with nested objects and no annotations, the description covers the domain-specific pieces well and correctly leaves return values to the existing output schema. The gap is the unmentioned required curve/market inputs and undocumented optional plumbing (as_of, calendar_overrides, request_id), which an agent must infer from schema names 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 0%, so the description has to compensate, and it does for the FRN-specific params (spread as decimal, index_id default, fixing_days/in_arrears defaults) and market_data_source in detail. However, required params such as market, discounting_curve, and forwarding_curve are never mentioned, and as_of, calendar_overrides, additional_trades, and request_id are left entirely undocumented, so roughly a third of the 22 params get no help.

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 ('Price a floating-rate note') and pins the HTTP endpoint, and the argument list makes the FRN-specific surface (spread, index_id, fixing_days, in_arrears, coupon_pricer) explicit against the sibling price_fixed_rate_bond it defers to. Differentiation from price_zero_coupon_bond / price_vanilla_swap is clear from the resource name, though the contrast with price_fixed_rate_bond is only implied by the cross-reference rather than stated.

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 an explicit when-not rule ('If you would have to invent numbers, do not call this tool: ask the user for the data') and a prerequisite for the preset ('a preset with a floating_rate_bond block'). It does not name alternative sibling tools or say when a different pricing tool is the better pick, so it falls short of the 5 tier.

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