Skip to main content
Glama

CurrencyGuard Guard Pricing

Compare a Guard with a Forward and with No Protection

compare_guard_with_forward
Read-only

Use when a user asks whether a Guard is worth it, how it compares with a forward contract from their bank or provider, or what happens if they do nothing. ASK BEFORE YOU CALL. The forward side of this comparison should be the customer's own numbers, not CurrencyGuard's guesses. Ask three things first: (1) the forward rate their provider last quoted them for this payment, (2) whether the provider gives them an unsecured line with no deposit, or asks for an initial margin and at what percentage, and (3) at what adverse move the provider demands more cash. Pass what they give you as providerForwardRate, initialMarginPct (0 for an unsecured line) and marginCallThresholdPct. Only call with none of them when the customer cannot answer, and then say in your answer that the forward figures are illustrative defaults. DO NOT RANK. Present every row in the order the output gives it: rates, home-currency amount, cash up front, cash demanded under adverse moves, outcomes under favourable and adverse moves, cancellation, market improvement, worst case. Do not say which one wins, which looks bad, which is cheaper overall, or which the customer should choose. State the numbers. The decision is the customer's. cashNature says what kind of money each figure is: the Guard fee is spent, a forward's deposit and margin calls are held and returned at settlement. Say so when you show them. Held cash is not a cost. outcomes runs each move in both directions. In the favourable rows the Guard lapses and the fee is spent for nothing, and the forward is locked out of the better rate. Show both directions, not only the adverse one. READ OUT comparability.protection AND comparability.pricing beside the cost row, every time. A Guard and a forward are different kinds of protection, and the Guard rate here is mid-market while, bought through a payment provider, it is the rate the provider gives. The cost row is therefore not a like-for-like price comparison. If a tenor like '3 months' is given, call resolve_settlement_date first. DO NOT ALSO CALL price_guard. This returns the Guard rate, fee and amount itself, priced in the same moment as the forward it is compared against. Calling both prices the Guard twice seconds apart, and the market moves between them — the answer then shows two different fees for one Guard. In the cost row, QUOTE THE ALL-IN COST, NOT THE RATE ROW. homeCurrencyAmount.forward already contains the provider margin, because the margin is in the rate, but homeCurrencyAmount.guard does NOT contain the Guard fee. Compare homeCurrencyAmount.guardAllIn with homeCurrencyAmount.forward: those two both carry every cost of their own product. Comparing guard with forward overstates the Guard, by the whole fee. rates.effectiveRate is the same all-in figure expressed as a rate, for setting beside a provider's quoted rate. assumptions.source says, figure by figure, whether the forward side is the customer's data (CUSTOMER, PROVIDER_QUOTE) or ours (DEFAULT, MARKET_CURVE_PLUS_MARGIN). Read assumptions.note out with the answer. Say "your provider's rate" for the customer's figures and "an assumed 5% deposit" for ours. Never present a default as a quote. The Guard figures are indicative: a Guard is bought through the customer's payment provider, and the Guard rate is the rate the provider gives them. Say that when you say "indicative".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "guardCurrency": "<guardCurrency>",
      "foreignCurrency": "<foreignCurrency>",
      "payReceive": "<payReceive>",
      "foreignAmount": "<foreignAmount>",
      "settlementDate": "<settlementDate>"
    },
    "name": "compare_guard_with_forward"
  }
}

Input Schema

NameRequiredDescriptionDefault
payReceiveYesPAY if paying foreign currency, RECEIVE if receiving it
foreignAmountYesAmount in foreign currency to protect
guardCurrencyYesHome/base currency ISO code, e.g. GBP
settlementDateYesSettlement date in ISO format YYYY-MM-DD
foreignCurrencyYesForeign currency ISO code, e.g. USD
forwardMarginPctNoMargin a provider embeds in a forward rate, as a percentage. Used only when providerForwardRate is absent. Default 1. Only set it if the user knows theirs.
initialMarginPctNoDeposit a provider demands at the start, as a percentage of the forward amount. Ask for it. Pass 0 when the provider gives the customer an unsecured line with no deposit. Default 5 when the customer does not know.
scenarioMovesPctNoAdverse market moves to show, as percentages. Default 3, 5, 10.
providerForwardRateNoThe forward rate the customer's own provider last quoted them, as foreign currency per unit of home currency, e.g. 1.3122 for GBPUSD. Ask for it. When given, it replaces the market curve estimate and forwardMarginPct is ignored, because a provider's quote already has the margin inside it.
marginCallThresholdPctNoThe adverse move, as a percentage, at which the provider starts to demand more cash. Ask for it. Below it the scenarios show no cash call on the forward. Leave empty when the customer does not know; the comparison then shows a call on every move, which is the conservative reading.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / forwardMarginPct / description
      Previous value: -"Margin a provider embeds in a forward rate, as a percentage. Default 1. Only set it if the user knows theirs."New value: +"Margin a provider embeds in a forward rate, as a percentage. Used only when providerForwardRate is absent. Default 1. Only set it if the user knows theirs."
    • changedInput schema / properties / initialMarginPct / description
      Previous value: -"Deposit a provider demands at the start, as a percentage of the forward amount. Default 5. Only set it if the user knows theirs."New value: +"Deposit a provider demands at the start, as a percentage of the forward amount. Ask for it. Pass 0 when the provider gives the customer an unsecured line with no deposit. Default 5 when the customer does not know."
    • addedInput schema / properties / marginCallThresholdPct
      Added value: +{
      +  "description": "The adverse move, as a percentage, at which the provider starts to demand more cash. Ask for it. Below it the scenarios show no cash call on the forward. Leave empty when the customer does not know; the comparison then shows a call on every move, which is the conservative reading.",
      +  "maximum": 100,
      +  "minimum": 0,
      +  "type": "number"
      +}
    • addedInput schema / properties / providerForwardRate
      Added value: +{
      +  "description": "The forward rate the customer's own provider last quoted them, as foreign currency per unit of home currency, e.g. 1.3122 for GBPUSD. Ask for it. When given, it replaces the market curve estimate and forwardMarginPct is ignored, because a provider's quote already has the margin inside it.",
      +  "exclusiveMinimum": 0,
      +  "type": "number"
      +}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare a safe read (readOnlyHint true, destructiveHint false), and the description adds substantial context well beyond that: the Guard figures are indicative, the Guard rate is mid-market versus a provider's rate, held cash is not a cost, and the fee is spent. It also explains how outputs relate (homeCurrencyAmount.guardAllIn versus forward) and how to label CUSTOMER versus DEFAULT assumptions rather than presenting a default as a quote.

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?

Front-loaded with the trigger and the ask-first procedure, then output-reading rules, with caps used sparingly for emphasis. Some material repeats, notably that the Guard rate is the provider's rate and that held cash is not a cost, but the length is largely justified by a complex comparison with no output schema.

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?

No output schema exists, so the description must carry the return-structure burden, and it names the specific fields to read (cashNature, outcomes, comparability.protection, comparability.pricing, rates.effectiveRate, assumptions.source/note) and how to narrate each. For a ten-parameter, multi-output comparison tool, nothing an agent needs to call and present it correctly is missing.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description adds real meaning: the three things to ask, that initialMarginPct 0 signals an unsecured line, that providerForwardRate supersedes forwardMarginPct, and that absence of marginCallThresholdPct yields the conservative reading. The added value is workflow and precedence guidance rather than finer per-field semantics, which the schema already carries.

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?

Opens with a specific use case ("whether a Guard is worth it, how it compares with a forward contract from their bank or provider, or what happens if they do nothing") that names the exact resource and scope. It explicitly contrasts with siblings, forbidding price_guard use and routing tenor input through resolve_settlement_date, so an agent can distinguish it 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 Guidelines5/5

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

Gives explicit when-to-use triggers, a mandatory pre-call sequence (ask three named questions, with the fields to map answers into), an explicit fallback for when the customer cannot answer, and explicit exclusions ("DO NOT ALSO CALL price_guard") with a reason. It also states the ordering of presentation and forbids ranking or recommending.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources