CurrencyGuard Guard Pricing

Price a Guard

price_guard

Read-only

Price a Guard — CurrencyGuard's FX protection product for real future payments or receipts. If a tenor like '3 months' is given, call resolve_settlement_date first to get the exact date, then call this tool. Returns: guardType (Guard-Pay or Guard-Receive), guardRate, guardFee (in the home currency), guardFeePct (a FRACTION: 0.0096 means 0.96%), guardFeePercent (the same figure written as a percentage, e.g. "0.96%" — quote this one), effectiveRate, guardAmount (the foreign amount converted at the Guard rate, in the home currency, WITHOUT the fee), foreignAmount, spotRate, settlementDate, settlementWindowFrom (the first day the Guard rate can be used; the window runs from there to settlementDate, counted in business days on the trading calendar, so over holidays it opens earlier than 14 calendar days), payLaterCreditFee (the extra charged if the fee is paid at settlement instead of up front), valid, errors, stale. Pilot limit: the Guard amount cannot exceed 1,000,000 in the home currency. Say so before quoting if the amount is clearly above it. The Guard fee is separate money. A payer funds guardAmount plus guardFee; a receiver nets guardAmount minus guardFee. effectiveRate is that all-in figure expressed as a rate. All quotes are indicative, because a Guard is bought through the customer's payment provider, who sets the final rate and fee. Say that reason when you say "indicative".

Input Schema

TableJSON Schema

Name	Required	Description
`guardRate`	No	Fixed Guard rate to price at instead of the current market rate. Leave empty to price at the current rate.
`payReceive`	Yes	PAY if paying foreign currency, RECEIVE if receiving it
`foreignAmount`	Yes	Amount in foreign currency to protect
`guardCurrency`	Yes	Home/base currency ISO code, e.g. GBP
`settlementDate`	Yes	Settlement date in ISO format YYYY-MM-DD
`foreignCurrency`	Yes	Foreign currency ISO code, e.g. USD

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedOct 16, 2026
- addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
- addedInput schema / properties / foreignAmount / exclusiveMinimum
```
Added value: +0
```
- addedInput schema / properties / foreignCurrency / maxLength
```
Added value: +3
```
- addedInput schema / properties / foreignCurrency / minLength
```
Added value: +3
```
- addedInput schema / properties / guardCurrency / maxLength
```
Added value: +3
```
- addedInput schema / properties / guardCurrency / minLength
```
Added value: +3
```
- changedInput schema / properties / guardRate / description
```
Previous value: -"Optional fixed guard rate (strike) — if set, prices at this rate instead of current market"New value: +"Fixed Guard rate to price at instead of the current market rate. Leave empty to price at the current rate."
```
- addedInput schema / properties / guardRate / exclusiveMinimum
```
Added value: +0
```
- addedInput schema / properties / payReceive / enum
```
Added value: +[
+  "PAY",
+  "RECEIVE"
+]
```
Changed1 schema field changedMay 11, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
First observedApr 22, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true/destructiveHint=false, but the description adds substantial non-obvious behavior: the 1,000,000 home-currency pilot cap, that all quotes are indicative because the payment provider sets the final rate, that the fee is separate money (payer funds guardAmount+guardFee, receiver nets guardAmount−guardFee), and that the settlement window is counted in business days on the trading calendar so holidays shift it earlier than 14 calendar days.

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

Conciseness4/5

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

Long but front-loaded: product identity, prerequisite call, then outputs, then constraints and caveats. Nearly every clause carries operational information, though the paired guardFeePct/guardFeePercent explanation is verbose and the parenthetical-heavy style is dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description assumes the burden of documenting the return contract and does so field by field (guardAmount excluding fee, guardFeePct as a fraction, settlementWindowFrom semantics, valid/errors/stale). Nothing an agent needs to call and interpret the result correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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, including the optional guardRate override. The description adds no input-side syntax or format detail beyond that and never mentions the guardRate field; its detail is spent on return-value semantics, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — pricing CurrencyGuard's FX protection product for real future payments or receipts — and the scope language distinguishes it from siblings like get_spot_rate, get_forward_rate, and compare_guard_with_forward. An agent can identify the tool's job without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit prerequisite sequencing: if a tenor like '3 months' is supplied, call resolve_settlement_date first to get the exact date. It also instructs the agent to raise the 1,000,000 pilot limit before quoting when the amount is clearly above it. It does not say when to prefer this over price_guard_extension or compare_guard_with_forward, only a clear usage context.

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

All CurrencyGuard Guard Pricing tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?