CurrencyGuard Guard Pricing

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

Annotations indicate readOnlyHint and openWorldHint. Description adds that it uses 'approved product and FAQ content' and covers specific topics, which is consistent and provides useful 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?

Two concise sentences with front-loaded purpose. No wasted 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?

Given no parameters or output schema, the description is reasonably complete, covering purpose and scope. Could mention output format, but not essential.

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?

No parameters exist; schema coverage is 100%. Description does not need to add parameter info. Baseline 4 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 it explains the Guard product using approved content, and lists specific topics covered. It distinguishes from sibling tools which focus on rates, pricing, or settlement dates.

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 obtaining official product explanations, but does not explicitly state when not to use it (e.g., for pricing questions). However, sibling tools are clearly different, so context is sufficient.

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?

Annotations (readOnlyHint=true, destructiveHint=false) indicate a safe read operation. The description adds that rates are derived from interest rate differentials, rounded, and for illustration only, and explains the returned fields and their meanings, providing rich 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 front-loaded with the tool's purpose and includes necessary details about return values and interpretation. It is slightly verbose but each sentence adds value, making it appropriately concise.

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?

Despite no output schema, the description fully explains all return fields (forwardRate, forwardPoints, spotMid, settlementDate) and their meanings, including how to interpret negative/positive forward points. This is complete for a tool with 3 required parameters 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% with descriptions for each parameter. The description does not add new parameter details but provides an example (base=GBP, quote=USD, tenor=3M) that clarifies usage, adding slightly above 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 clearly states it gets an indicative forward FX rate for a currency pair and tenor. It distinguishes itself from siblings like get_spot_rate by specifying it's a forward rate, and it notes the rate is indicative, not for execution.

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 says the rate is indicative and not for execution, guiding appropriate use. It explains negative/positive forward points but does not explicitly mention when to use alternatives like get_spot_rate or resolve_settlement_date.

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?

Annotations already indicate readOnlyHint=true and openWorldHint=true, but the description adds important behavioral context: it uses Bank of England historic rates, returns a specific array structure, and defines the meaning of BEST/WORST based on the direction of delta. This adds value beyond annotations without contradicting them.

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 sentences: the first is concise and purpose-driven, while the second lists output fields in a structured but somewhat lengthy way. It is still effective and not overly verbose. It could be slightly more concise by summarizing the array structure, but remains clear.

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 6 required parameters, no enums, and no output schema. The description fully compensates for missing output schema by detailing the exact structure of the return value, including all fields and their interpretation. This ensures an agent understands what to expect without additional documentation.

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 describes all 6 parameters with 100% coverage. The description reinforces the requirement that parameters must match price_guard, but does not add new semantic information beyond what is in the schema. The emphasis on exact matching is useful but not novel, warranting a baseline score of 3.

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's purpose: analyzing historic best/worst FX performance for a currency pair over a Guard's duration. It specifies the data source (Bank of England) and the output structure (performances array with 6 entries). This distinguishes it from sibling tools like get_spot_rate or get_forward_rate, which serve different purposes.

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 states that parameters must match the preceding price_guard call, and it explains how to interpret BEST/WORST for both Guard-Pay and Guard-Receive. However, it does not provide explicit guidance on when not to use this tool or compare it to alternatives, though the context of being used after price_guard is 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?

Annotations provide readOnlyHint=true and destructiveHint=false, confirming no side effects. The description adds that rates are 'rounded bid, ask, and mid', which is behavioral context not in annotations. No contradictions.

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 concise sentences: first gives purpose and return values, second provides a usage example. No fluff, every sentence adds 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 tool with no output schema, the description adequately explains the return type (bid, ask, mid rates) and a usage example. Could mention possible error conditions (e.g., invalid currency codes) but overall sufficient for a simple read-only 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 descriptions already cover both parameters (base and quote currency codes) with full coverage (100%). The description adds an example clarifying the order and meaning, which is helpful but not critical.

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' and the resource 'spot FX rate' for a currency pair, with a concrete example (GBP/USD). It distinguishes from sibling tools like get_forward_rate by specifying 'spot' and 'indicative'.

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 states 'for illustration purposes only — not for execution', which tells the agent when to use (indicative rates) and when to avoid (for actual trades). This addresses usage boundaries.

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?

The annotations already indicate readOnlyHint=true, so the description's admission of a listing operation is consistent. The description adds value by naming the specific currency pairs, providing concrete behavioral context beyond the annotations' safety profile.

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 sentence with no redundant words. It front-loads the purpose and immediately provides the supported pairs, making it maximally efficient.

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 parameterless tool with no output schema, the description is adequate. It states the output is a list of three specific currency pairs. However, it could improve by explicitly stating the return format or noting that the list is static, but given the simplicity, it is mostly 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?

With zero parameters and 100% schema description coverage, the baseline is 4. The description goes further by listing the actual currency pairs returned, which adds significant semantic meaning over the empty 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 tool lists all supported currency pairs for Guard pricing, specifying the exact pairs (GBPUSD, GBPEUR, EURUSD). The verb 'list' and resource 'supported currency pairs' are unambiguous. The title matches the purpose, and the tool is distinct from siblings that perform different 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?

No guidance is provided on when to use this tool versus alternatives like get_spot_rate or get_forward_rate. The description simply lists the function without context or exclusions, leaving the agent to infer usage from the tool name alone.

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?

Annotations already indicate readOnlyHint and destructiveHint. The description adds value by noting quotes are indicative and by specifying the prerequisite call to resolve_settlement_date, which gives behavioral context beyond 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 concise, front-loaded with purpose, and efficiently lists return fields and usage hint. Every sentence adds value 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?

Given no output schema, the description fully lists all return fields. It includes prerequisites, clarifies indicative quotes, and covers input context. No gaps for a pricing tool of this complexity.

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 each parameter is described. The description adds the context that settlementDate should come from resolve_settlement_date if a tenor is given, which aids correct usage. It also lists return fields, compensating for no output 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 tool prices a CurrencyGuard FX protection product. It distinguishes from sibling tools like resolve_settlement_date and price_guard_extension by specifying when to use each, and lists the return fields in detail.

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 advises calling resolve_settlement_date first if a tenor is given, providing clear guidance on prerequisite usage. It does not explicitly list alternatives for all scenarios, but the mention is strong and sufficient.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral details: the three components of the cost breakdown and the key fact that both quotes use the same guard rate, so fee difference is due to tenor only. No contradictions.

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 efficient: begins with the core purpose, then explains the calculation method, and ends with usage guidance. Every sentence adds value 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?

Given 6 required parameters, no output schema, and strong annotations, the description fully covers what the tool does, how the extension cost is computed, and when to use it. It does not require further clarification for an AI 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?

All 6 parameters are described in the schema (100% coverage). The description adds context that parameters match price_guard plus the two dates, explaining their role in the extension calculation beyond the schema's field descriptions.

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 'Get an indicative price for extending a Guard to a later settlement date.' It specifies the action (estimating additional cost) and distinguishes from siblings like price_guard and explain_guard_product by focusing on extension scenarios.

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 says 'Use this when a customer asks how much would it cost to extend my Guard by X months?' providing a direct usage scenario. It implies not to use for new guards via the sibling context, but does not list exclusions or alternatives explicitly.

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?

Annotations indicate readOnlyHint=true, and the description adds that the tool accounts for weekends and holidays, providing behavioral context beyond 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?

Description is mostly concise with useful examples, though slightly verbose with repeated examples. Each sentence adds 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?

Given no output schema, description explains the return value ('settlementDate') and its use in price_guard, covering holidays. Complete for a 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 100%, so baseline 3. The description adds format examples for the tenor parameter but doesn't significantly extend schema meaning.

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 ('resolve') and resource ('settlement date for a currency pair'), clearly distinguishing it from sibling tools like price_guard.

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 states when to use (when user provides tenor instead of exact date) and ties to sibling tool price_guard, but lacks explicit when-not or alternative tools.

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