Skip to main content
Glama

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. THE AMOUNT. Give exactly ONE of foreignAmount and netGuardAmount, never both. Give foreignAmount when the customer has an invoice or bill in the foreign currency and wants to know what it is worth in their own currency: "I have to pay USD 50,000 in March" is foreignAmount 50000, PAY. Give netGuardAmount when the customer names the amount they want in their OWN currency after the fee, and asks what to invoice or how much they can cover: "I need GBP 100,000 from Marco, he pays in euros, what do I quote him?" is netGuardAmount 100000, RECEIVE, guardCurrency GBP, foreignCurrency EUR. With netGuardAmount the server solves for the foreign amount, so the foreignAmount in the response IS THE ANSWER: the amount to invoice (RECEIVE) or the amount covered (PAY). Read it out as the answer to the question. 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. It opens 14 business days before settlementDate on the trading calendar, which is about three weeks in calendar days. Say "14 business days", never "14 days", and read both dates out as given), payLaterCreditFee (the extra for paying the fee at settlement instead of up front. This tool asks for a pay-now quote, so the server returns 0 here. 0 does NOT mean Pay Later is free: say that a small credit fee applies and that it is not in this quote), valid, errors, stale. Also returns netGuardAmount, what the customer ends up with in the home currency once the fee is counted (guardAmount minus guardFee for RECEIVE, guardAmount plus guardFee for PAY), and netGuardAmountNote, that figure in a sentence. Say the sentence. It tells the customer that the fee is paid now, what they get or pay at settlement, and what that nets to. 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: 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". WHEN NOT TO CALL THIS TOOL. Not for "what can I do", "what are my choices", "is it worth it", or a list of open items. Those get the three things a client can do, with no price for any of them. An amount and a date in such a question do not make it a quote request. Call this tool only when the user asks for a price, a quote, a cost, a fee, or to fix a rate.

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>",
      "settlementDate": "<settlementDate>"
    },
    "name": "price_guard"
  }
}

Input Schema

NameRequiredDescriptionDefault
guardRateNoFixed Guard rate to price at instead of the current market rate. Leave empty to price at the current rate.
payReceiveYesPAY if paying foreign currency, RECEIVE if receiving it
foreignAmountNoThe invoice or bill amount in the foreign currency. Give this OR netGuardAmount, not both.
guardCurrencyYesHome/base currency ISO code, e.g. GBP
netGuardAmountNoThe amount the customer wants in the home currency AFTER the Guard fee: what they bank (RECEIVE) or the most they pay, fee included (PAY). The server then works out the foreign amount. Give this OR foreignAmount, not both.
settlementDateYesSettlement date in ISO format YYYY-MM-DD
foreignCurrencyYesForeign currency ISO code, e.g. USD

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / foreignAmount / description
      Previous value: -"Amount in foreign currency to protect"New value: +"The invoice or bill amount in the foreign currency. Give this OR netGuardAmount, not both."
    • addedInput schema / properties / netGuardAmount
      Added value: +{
      +  "description": "The amount the customer wants in the home currency AFTER the Guard fee: what they bank (RECEIVE) or the most they pay, fee included (PAY). The server then works out the foreign amount. Give this OR foreignAmount, not both.",
      +  "exclusiveMinimum": 0,
      +  "type": "number"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "guardCurrency",
      -  "foreignCurrency",
      -  "payReceive",
      -  "foreignAmount",
      -  "settlementDate"
      -]New value: +[
      +  "guardCurrency",
      +  "foreignCurrency",
      +  "payReceive",
      +  "settlementDate"
      +]
  2. Changed9 schema fields changed
    • 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"
      +]
  3. Changed1 schema field changed
    • removedInput schema / additionalProperties
      Removed value: -false
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover only the safety profile (readOnly, non-destructive, closed-world), and the description goes well beyond that: a hard pilot limit of 1,000,000 in home currency, the fact that quotes are indicative and sourced from the payment provider, the fee mechanics (payer funds guardAmount plus guardFee; receiver nets guardAmount minus guardFee), why payLaterCreditFee returns 0 here and how to phrase it, and the settlement-window derivation from the trading calendar. None of this is inferable from the schema or annotations.

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

Conciseness3/5

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

It is front-loaded with purpose and the amount rule, which is right, but the body is roughly 450 words and drifts between tool-contract and customer-script instructions ("Say the sentence", "quote this one", "never '14 days'"), which is a lot of prose for an agent to hold. The fragment "THE AMOUNT." is a broken sentence, and several return-field explanations are dense enough to be hard to scan; useful content, but the structure costs clarity.

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 carries the full burden of explaining the response, and it does so field by field: guardType, guardRate, guardFee versus guardFeePct versus guardFeePercent, effectiveRate, guardAmount's fee exclusion, settlementWindowFrom, payLaterCreditFee, netGuardAmount and its note. An agent could construct the call and interpret the result correctly from this text alone, including the edge case where the amount exceeds the pilot limit.

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, but the description earns more by disambiguating the hardest choice in the tool: exactly one of foreignAmount vs netGuardAmount, with worked examples for each direction ("I have to pay USD 50,000 in March" vs "I need GBP 100,000 from Marco") and the crucial consequence that with netGuardAmount the returned foreignAmount is the answer to read out. It does not add anything to guardRate, settlementDate, or the currency codes beyond the schema, so it falls short of 5.

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?

"Price a Guard — CurrencyGuard's FX protection product for real future payments or receipts" gives a specific verb (price) and resource (Guard), and immediately frames it against siblings like explain_guard_product and net_exposure by scoping it to actual quoting. The description also explicitly names the product boundary (indicative, bought through the provider's payment provider), so an agent can tell it apart from get_spot_rate or get_forward_rate without opening a 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?

It states the prerequisite flow ("If a tenor like '3 months' is given, call resolve_settlement_date first"), gives an explicit WHEN NOT TO CALL section with example phrasings ("what can I do", "is it worth it"), and closes with the positive trigger ("only when the user asks for a price, a quote, a cost, a fee, or to fix a rate"). That is a full when/when-not/alternative routing rule, including the trap that an amount plus date does not itself make a quote request.

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