CurrencyGuard Guard Pricing

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool uses 'CurrencyGuard's approved product and FAQ content,' ensuring accuracy and compliance, and it requires calling the tool rather than relying on memory. However, it lacks details on potential limitations like response format, error handling, or rate limits, which could be useful for an agent.

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 core purpose, followed by specific usage guidelines and a prohibition. Every sentence earns its place: the first defines the tool, the second lists question types, and the third mandates its use. It is appropriately sized, with no redundant or vague language, making it highly efficient and structured.

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 the tool's complexity (explaining a product with legal/regulatory aspects), no annotations, and no output schema, the description is largely complete. It covers purpose, usage, and behavioral constraints like using approved content. However, it doesn't specify what the output looks like (e.g., structured FAQ, text response), which could help an agent understand the result format, leaving a minor gap.

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 has 0 parameters with 100% coverage, so no parameter information is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and usage. A baseline of 4 is applied as it compensates for the lack of parameters by providing clear context, though it doesn't add semantic value beyond the schema (which is fine here).

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: to explain the Guard product using approved content. It specifies the verb 'explain' and the resource 'Guard product', distinguishing it from siblings that perform actions like pricing, listing, or getting rates. The description explicitly lists the types of questions it handles (e.g., what, how, who, comparisons, legal/regulatory), making it highly specific and differentiated.

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 provides explicit guidance on when to use this tool: for any question about the Guard product, including specific categories like legal or eligibility questions. It also states when not to use it: 'Do not answer those questions from memory — always call this tool,' effectively prohibiting alternatives and emphasizing reliance on this tool for accurate, approved content.

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?

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: that rates are 'derived from interest rate differentials, rounded,' 'for illustration purposes only — not for execution,' and explains the meaning of positive/negative forward points. It also describes what the tool returns (forwardRate, forwardPoints, spotMid, settlementDate), though it doesn't cover error conditions or rate limits.

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 appropriately sized and front-loaded with the core purpose. Every sentence adds value: the first states the purpose, the second explains derivation and limitations, the third details return values, the fourth explains forward point signs, and the fifth provides an example. Some minor redundancy exists between explaining forward points and the example.

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 annotations and no output schema, the description does well to explain the tool's behavior, limitations, and return values. It covers the indicative nature of rates, derivation method, return structure, and provides an example. However, it doesn't mention error conditions, rate limits, or authentication requirements that might be relevant for a financial 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?

With 100% schema description coverage, the baseline is 3. The description adds minimal parameter semantics beyond the schema - it provides an example ('base=GBP, quote=USD, tenor=3M') but doesn't explain parameter interactions or constraints beyond what's in the schema descriptions. The schema already documents each parameter's purpose adequately.

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 specific action ('Get an indicative forward FX rate'), resource ('for a currency pair'), and scope ('at a specific tenor'). It distinguishes from sibling tools like 'get_spot_rate' by focusing on forward rates rather than spot rates, and from 'resolve_settlement_date' by providing full forward rate data rather than just 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 provides clear context about when to use this tool ('for illustration purposes only — not for execution'), but doesn't explicitly mention when not to use it or name specific alternatives. It implies usage for forward rate queries rather than spot rates or historical data, but lacks explicit exclusion statements.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the response structure, data source (Bank of England historic rates), and presentation requirements. However, it doesn't mention potential errors, rate limits, or authentication needs, leaving some behavioral aspects unspecified.

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 excessively long (over 400 words) with redundant information. While well-structured into purpose, usage, response, and presentation sections, it includes overly detailed presentation instructions that belong in agent guidelines rather than tool description. Many sentences don't earn their place for tool selection purposes.

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 annotations or output schema, the description provides comprehensive context: complete response structure with field explanations, data source, presentation requirements, parameter dependencies, and usage timing. It fully compensates for the lack of structured metadata, making the tool's behavior and outputs completely understandable.

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 schema already documents all parameters. The description adds context by emphasizing that parameters must match the preceding price_guard call and explaining the relationship between payReceive and deltaAmount interpretation, but doesn't provide additional semantic details beyond what's in the schema 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 explicitly states the tool's purpose: 'Analyzes how much a customer's base currency cost would have changed if they had left their FX exposure unhedged in the past' and 'get historic best/worst FX performance data.' It distinguishes from siblings by specifying it's for historic performance analysis after pricing a Guard, unlike tools like get_spot_rate or 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?

The description provides explicit usage instructions: 'Use this AFTER pricing a Guard when the user asks for historic context.' It also warns against alternatives: 'NEVER generate, estimate, or fabricate historic FX data from your own knowledge' and specifies that all parameters must match the preceding price_guard call, clearly defining when and how to use this tool.

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?

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the rates are 'indicative,' 'rounded,' and 'for illustration purposes only — not for execution,' which clarifies limitations not inferable from the schema. It doesn't mention rate limits, data sources, or freshness, leaving some gaps.

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 core purpose, followed by key behavioral details and an example, all in three concise sentences with zero wasted words. Each sentence adds essential information 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 the tool's moderate complexity (2 required parameters, no output schema, no annotations), the description is fairly complete: it explains purpose, behavioral constraints, and includes an example. However, it lacks details on output format (e.g., structure of returned rates) and potential error cases, which would enhance completeness.

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 schema already documents both parameters (base and quote) with examples. The description adds minimal value by providing an example ('base=GBP, quote=USD'), but doesn't explain semantics beyond what the schema states, meeting the baseline for high coverage.

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 specific action ('Get an indicative spot FX rate') and resource ('for a currency pair'), distinguishing it from siblings like get_forward_rate (forward rates) or get_historic_best_worst (historical data). It explicitly mentions what it returns (bid, ask, mid rates) and its illustrative purpose.

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 provides clear context by stating this is for 'illustration purposes only — not for execution,' which helps differentiate it from tools like price_guard that might be for actionable pricing. However, it doesn't explicitly name when-not-to-use alternatives or compare directly to siblings like get_forward_rate.

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?

With no annotations provided, the description carries the full burden. It indicates this is a read-only operation ('List') and specifies the exact output content (the three currency pairs). However, it lacks details on behavioral traits like error handling, rate limits, or whether the list is static or dynamic, which would be helpful for a tool with no 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 a single, efficient sentence that front-loads the key information ('List all supported currency pairs') and includes necessary specifics without any wasted words. Every part of the sentence contributes directly to understanding the tool's function and scope.

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 the tool's low complexity (0 parameters, no output schema, no annotations), the description is largely complete. It clearly states what the tool does and what it returns. However, without an output schema, it could benefit from more detail on the return format (e.g., list structure), though the explicit listing of pairs partially compensates.

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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, focusing instead on the tool's purpose and output. A baseline of 4 is applied since no parameters exist, and the description doesn't attempt to compensate for non-existent gaps.

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 specific action ('List all supported currency pairs') and identifies the exact resources ('GBPUSD, GBPEUR, and EURUSD') with context ('available for Guard pricing'). It distinguishes this tool from siblings like get_spot_rate or price_guard by focusing on listing available pairs rather than pricing or rate calculations.

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 provides clear context for when to use this tool ('available for Guard pricing'), which implicitly suggests it's for discovering which currency pairs can be priced. However, it doesn't explicitly state when not to use it or name alternative tools for related functions, such as checking if a specific pair is supported elsewhere.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains key behavioral traits: that quotes are indicative, the tool requires specific formatting (Markdown table), and critical formatting rules (no HTML/JSON). It also details the Guard's mechanics (protection without locking in, settlement window usage). However, it doesn't mention error handling, rate limits, or authentication needs.

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 excessively long (over 500 words) and includes extensive agent instructions (Steps 1-6) that belong in a prompt or system context, not a tool description. While structured, it's not front-loaded with core tool purpose, and many sentences (e.g., formatting rules, historical data handling) don't directly help the agent understand the tool's function.

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 the complexity (FX hedging product) and lack of annotations/output schema, the description provides substantial context about the tool's behavior and usage. However, it's overly focused on agent workflow steps rather than tool semantics, and it doesn't explain return values or error cases. For a tool with 6 parameters and no structured output, this is adequate but has clear gaps.

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 schema already documents all parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema. It mentions parameters indirectly (e.g., 'payReceive' in Step 2), but no new syntax, constraints, or examples are provided. Baseline 3 is appropriate when the schema does the heavy lifting.

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: 'Price a Guard — CurrencyGuard's FX protection product for real future payments or receipts.' This specifies the verb ('Price') and resource ('Guard'), and distinguishes it from sibling tools like get_forward_rate or get_spot_rate. However, it doesn't explicitly differentiate from price_guard_extension, which is a close sibling.

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 provides explicit, step-by-step usage instructions, including when to call resolve_settlement_date first (if a tenor is given), when to present three choices (only if comparing options), and when to ask about historic data. It also distinguishes this tool from alternatives by explaining the Guard product vs. traditional forwards or doing nothing in Step 5.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by explaining the calculation methodology (three cost components), clarifying that pricing uses the original strike rate, and specifying the return format (breakdown of extensionCost). However, it doesn't mention potential limitations like rate limits, error conditions, or authentication requirements.

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 efficiently structured with zero wasted sentences. It front-loads the purpose, explains the calculation methodology, specifies the return format, provides usage guidance, and clarifies parameter relationships—all in a compact, well-organized paragraph that earns every word.

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 annotations and no output schema, the description does an excellent job explaining the calculation logic, return format, and usage context. The main gap is the lack of explicit output schema documentation (though the return breakdown is described), and some behavioral aspects like error handling aren't covered. Given the complexity, it's nearly complete but not perfect.

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 schema already documents all six parameters thoroughly. The description adds minimal value beyond the schema by noting 'Parameters match price_guard plus the two dates,' which provides context about parameter relationships but doesn't enhance individual parameter understanding. This meets the baseline for high schema coverage.

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 specific action ('Get an indicative price for extending a Guard'), identifies the resource ('a Guard'), and distinguishes it from the sibling 'price_guard' tool by focusing on extension rather than initial pricing. It explicitly mentions the three cost components used in the calculation.

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 provides explicit guidance on when to use this tool: 'when a customer asks "how much would it cost to extend my Guard by X months?"' It also distinguishes it from the sibling 'price_guard' tool by stating 'Parameters match price_guard plus the two dates,' clarifying the relationship and when to choose one over the other.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it resolves tenors to dates, accounts for weekends and public holidays in financial centres, and returns a settlementDate for use in other tools. However, it lacks details on error handling or rate limits, leaving some gaps in transparency.

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 well-structured and concise, with each sentence serving a clear purpose: stating the tool's function, providing usage context, explaining tenor format with examples, describing date adjustments, and linking to another tool. There is no wasted text, and information is front-loaded effectively.

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 the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, usage, parameter semantics, and behavioral aspects like date adjustments. However, without an output schema, it could benefit from more detail on the return format (e.g., date structure), slightly reducing completeness.

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 adds significant value beyond the schema by explaining the tenor format with examples (e.g., '3M' = 3 months) and clarifying that the currency pair affects holiday considerations. This enhances understanding of parameter usage and constraints.

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: 'Resolve a relative time period (tenor) to a valid business settlement date for a currency pair.' It specifies the verb ('resolve'), resource ('relative time period/tenor'), and outcome ('valid business settlement date'), distinguishing it from siblings like price_guard or get_forward_rate by focusing on date resolution rather than pricing or rates.

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 when to use this tool: 'Use this when a user says '3 months', '6 months', '1 year', etc. instead of an exact date.' It also provides an alternative context: 'Use the returned settlementDate as the exact date parameter for price_guard,' linking it to a sibling tool and clarifying its role in a workflow.

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