FX protection for SMEs — price Guards, live spot/forward rates, settlement dates, and more.
Scored across 11 tools
Most tools target clearly distinct operations (spot vs forward vs historic rates, settlement-date resolution, netting, product explanation, provider checks). The main overlap is between compare_guard_with_forward and price_guard, both of which produce Guard pricing, but the compare tool's description explicitly forbids calling price_guard alongside it, mitigating the risk. price_guard vs price_guard_extension is also close but clearly delineated by extension's 'extend an existing Guard' scope.
Nearly all tools follow a predictable snake_case verb_noun pattern (get_forward_rate, price_guard, resolve_settlement_date, request_provider_availability). The only mild outlier is net_exposure, which reads as a noun rather than an explicit verb_noun, but it stays within the same snake_case convention.
Eleven tools is well within the ideal 3-15 range and each earns its place, covering distinct stages of the Guard workflow: currency discovery, date resolution, pricing, comparison, extension, netting, and provider enquiry. No tool appears redundant or filler.
The surface covers the core Guard lifecycle well: supported currencies, settlement-date resolution, spot/forward rates, historic analysis, pricing, extension pricing, forward comparison, net exposure, and product explanation. Gaps are minor — no explicit execution/booking tool, though quotes are explicitly indicative and bought through a provider, so this is consistent with the stated pricing-only purpose.
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 a payment provider may apply a margin to it or to the fee. 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, 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".
| Name | Required | Description | Default |
|---|---|---|---|
| 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 | |
| forwardMarginPct | No | 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. | |
| initialMarginPct | No | 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. | |
| scenarioMovesPct | No | Adverse market moves to show, as percentages. Default 3, 5, 10. | |
| providerForwardRate | No | 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. | |
| marginCallThresholdPct | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read operation, yet the description still adds rich context beyond them: cashNature semantics (held cash is not a cost), bidirectional outcome rows, assumptions.source provenance labels, the indicative-pricing caveat, and an explicit no-ranking obligation. This is substantial behavioral disclosure that annotations cannot carry.
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?
It is long, but front-loaded with the trigger and the ask-first protocol, then organized into distinct concerns (do not rank, cashNature, comparability, do not double-price, all-in cost). A few output-presentation instructions are verbose, but almost every sentence carries invocation-relevant guidance.
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?
With no output schema, the description takes on the burden of explaining the return shape itself (comparability.protection, comparability.pricing, assumptions.source/note, homeCurrencyAmount.guardAllIn vs .forward, rates.effectiveRate) and does so thoroughly, including how to present each figure. Nothing needed to call or interpret the result is missing.
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, but the description adds real meaning: which three values to ask the customer for, that initialMarginPct should be 0 for an unsecured line, and that providerForwardRate suppresses forwardMarginPct because the margin is inside the quote. It maps inputs to the business question rather than restating the 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 states a specific verb (compare) and three named resources (a Guard, a forward, and doing nothing), and it explicitly distinguishes itself from the sibling price_guard ('DO NOT ALSO CALL price_guard'). An agent can tell exactly what this tool produces 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use triggers ('whether a Guard is worth it'), prerequisites ('call resolve_settlement_date first'), an exclusion rule against price_guard with the reason (double-pricing seconds apart), and a fallback path when the customer cannot answer. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain the Guard product using CurrencyGuard's approved product and FAQ content. Covers: what the Guard is, how it works, who it is for, how it compares to forwards or options, and legal, regulatory, accounting, or eligibility questions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the grounding source: answers come from CurrencyGuard's 'approved product and FAQ content', which tells an agent the output is curated/authoritative rather than generated. It does not mention rate limits or response shape, but for a zero-parameter read tool that is minor.
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 sentences, front-loaded with the core action, with the covered topics enumerated compactly. The topic list is the item most open to trimming, but it does usefully signal the breadth of answerable questions rather than padding.
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, read-only informational tool with no output schema, the description supplies everything needed to invoke it correctly: what it explains, what content grounds it, and what topic range it covers. The only gap is the unaddressed boundary with compare_guard_with_forward, which matters given the overlapping comparison topic.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a 0-param tool is 4. The topic list in the description is input-adjacent guidance rather than parameter documentation, so it cannot be credited as parameter semantics.
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?
States a specific verb (explain) and resource (the Guard product), then enumerates the question topics it answers, so an agent knows exactly what this tool is for. It is not fully differentiated from siblings: it claims to cover 'how it compares to forwards or options' while a dedicated compare_guard_with_forward tool exists, leaving a routing ambiguity.
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?
Usage is implied — reach for this on conceptual/FAQ questions about the Guard rather than pricing or rate lookups — but there is no explicit when-to-use statement or exclusion. Critically, it never tells the agent when to prefer compare_guard_with_forward over this tool for comparison questions, despite the overlapping scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you need a forward FX rate. tenor accepts either a period such as 1W, 1M, 3M, 6M, 1Y, or an exact date in ISO form YYYY-MM-DD. Use an exact date whenever you need the forward for the same day a Guard settles: a period resolves to the forward curve's own date, which can be several days away, and a comparison across two different dates is misleading. Rates are taken from the market forward curve, rounded, and for illustration purposes only — not for execution. Returns: forwardRate (indicative mid outright = spot + forward points), forwardPoints (in pips, e.g. -3.1 means the forward rate is 3.1 pips below spot), spotMid (indicative spot mid rate for comparison), settlementDate (the date the rate is for). Negative forward points mean the forward rate is below spot; positive means above. Example: base=GBP, quote=USD, tenor=2026-12-29 returns the GBPUSD forward for that day.
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | Base currency ISO code, e.g. GBP | |
| quote | Yes | Quote currency ISO code, e.g. USD | |
| tenor | Yes | Tenor period such as 1W, 1M, 3M, 6M, 1Y, or an exact date as YYYY-MM-DD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe read, and the description layers on genuinely new behavioral context: rates are indicative mid, rounded, from the market forward curve, and explicitly 'not for execution'. It also dictates the sign convention for forward points and states what each returned field means. That is well beyond what readOnlyHint/destructiveHint convey.
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?
It is front-loaded with the trigger and the tenor rule before moving to caveats and return values, and each sentence carries information. It runs long (nine-plus sentences), and the currency-pair example plus field-by-field return list push it toward the verbose end of acceptable.
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?
With no output schema, the description fully compensates by enumerating forwardRate, forwardPoints, spotMid and settlementDate and explaining the sign of forward points. Combined with the usage path and the 'not for execution' caveat, an agent has everything needed to call and interpret this 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 the baseline is 3, but the description adds real meaning: the tenor's two accepted forms, the consequence of using a period (curve date can be several days off settlement), and why that mismatch misleads comparisons. Base/quote semantics come from the schema and example rather than new text.
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 states a specific resource and scope: a forward FX rate taken from the market forward curve, with the spot rate returned for comparison. It distinguishes itself implicitly from get_spot_rate through the explicit 'forward' framing and the forward-points field. It does not explicitly name a sibling, which keeps it short of a 5.
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 gives clear when-to-use context ('Use when you need a forward FX rate') and, more usefully, a decision rule for the tenor argument: pick an exact date whenever the forward must line up with a Guard settlement date, because period tenors resolve to the curve's own date. It stops short of naming alternative tools (e.g. get_spot_rate, compare_guard_with_forward) as explicit substitutes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze historic best/worst FX performance for a currency pair over a Guard's duration. Uses Bank of England historic rates. Returns a 'performances' array with 6 entries — BEST and WORST for each of three lookback periods (5, 10, 25 years). Each entry contains: type, lookbackYears, startDate/endDate, startRate/endRate, performancePercentage, startAmount, finalAmount, deltaAmount. For Guard-Pay: negative delta = cost decreased = BEST; positive delta = cost increased = WORST. For Guard-Receive: positive delta = receipt increased = BEST; negative delta = receipt decreased = WORST. Parameters must match the values used in the preceding price_guard call, including payReceive (PAY or RECEIVE).
| Name | Required | Description | Default |
|---|---|---|---|
| payReceive | Yes | MUST be the exact same payReceive value you used in price_guard (PAY or RECEIVE). Do NOT change it. | |
| guardAmount | No | Guard amount in base/home currency from the Guard quote (the guardAmount field from the price_guard response). Optional: leave it empty when there is no quote, and the tool uses today's indicative mid spot rate instead, so a risk question needs no price first. | |
| foreignAmount | Yes | Amount in foreign currency — MUST match foreignAmount from price_guard | |
| guardCurrency | Yes | Home/base currency ISO code — MUST match guardCurrency from price_guard | |
| settlementDate | Yes | Settlement date in ISO format YYYY-MM-DD — MUST match settlementDate from price_guard | |
| foreignCurrency | Yes | Foreign currency ISO code — MUST match foreignCurrency from price_guard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the data source, the exact shape of the returned 'performances' array (6 entries across 5/10/25-year lookbacks), and the semantic interpretation of delta sign under Guard-Pay vs Guard-Receive. It does not discuss rate limits or auth, but for a read-only analytic tool that is acceptable.
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?
Front-loaded with the purpose, then moves through output structure and delta semantics in a logical order. It is somewhat dense, but each sentence (data source, array contents, PAY vs RECEIVE interpretation) carries information an agent needs. No filler sentences.
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?
With no output schema, the description helpfully enumerates the return array and each field, and the semantics of delta sign — so the agent knows how to interpret results. One minor gap: it insists parameters 'must match' the preceding price_guard call, while the schema notes guardAmount is optional and a risk question can be answered with no price first; the description does not reconcile this.
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 all six parameters are already documented, including the payReceive enum and the price_guard matching constraints. The description reinforces the matching requirement and the PAY/RECEIVE semantics but adds little beyond what the schema already states. Baseline 3 applies 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?
States a specific verb and resource: 'Analyze historic best/worst FX performance for a currency pair over a Guard's duration.' It names the data source (Bank of England historic rates) and is clearly distinguishable from siblings like get_forward_rate, get_spot_rate, and compare_guard_with_forward, which address different computations.
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 establishes a clear prerequisite: 'Parameters must match the values used in the preceding price_guard call, including payReceive.' This tells the agent how this tool sequences with price_guard. However, it names no alternative tools or explicit when-not-to-use conditions, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an indicative spot FX rate for a currency pair. Returns rounded bid, ask, and mid rates for illustration purposes only — not for execution. Example: base=GBP, quote=USD returns the GBPUSD rate.
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | Base currency ISO code, e.g. GBP | |
| quote | Yes | Quote currency ISO code, e.g. USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), so the description earns credit for adding behavioral context beyond them. It discloses that the rate is indicative and rounded and that the tool returns bid, ask, and mid rates, which matters for interpreting output. It does not mention authentication or rate limits, but those are secondary here.
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?
Three tight sentences: purpose first, then output and limitation, then a concrete example. Every sentence earns its place with no filler or 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?
For a simple read operation with a fully described schema and annotations covering safety, the description adequately covers output semantics (bid/ask/mid, rounded, indicative). It omits whether unsupported currencies produce an error or should be checked via list_supported_currencies, which is 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?
Schema description coverage is 100%, establishing a baseline of 3. The description's example ('base=GBP, quote=USD returns the GBPUSD rate') adds meaning by clarifying that the base/quote ordering defines the pair, which the schema descriptions alone do not spell out.
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 gives a specific verb and resource: 'Get an indicative spot FX rate for a currency pair.' It implicitly distinguishes itself from the forward-rate sibling by saying 'spot,' but never explicitly names an alternative tool such as get_forward_rate, so it falls short of a 5.
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 phrase 'for illustration purposes only — not for execution' signals a usage context and a clear limitation. However, it offers no explicit when-to-use guidance versus alternatives like get_forward_rate, so the guidance remains implied rather than actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the currency pairs currently available for Guard pricing. Always call this rather than assuming which pairs are supported — the list is configuration-driven and changes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the read-only, non-destructive safety profile, so the bar is lower; the description nonetheless adds real behavioral context beyond them — the list is configuration-driven and changes, implying results should not be cached or hard-coded. It omits nothing safety-critical.
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 tight sentences: the first defines the resource, the second carries the actionable directive. Nothing is redundant and the operational guidance is front-loaded.
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 zero-parameter, read-only enumeration call with no output schema, the description covers purpose and usage adequately. It could briefly note the return shape (e.g., a flat list of pair codes) to fully close the loop, but nothing essential is missing.
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 tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies a parameterless enumeration and introduces no parameter concepts that would need explanation.
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?
States a specific verb (List) and resource (currency pairs) scoped to Guard pricing, which separates it cleanly from pricing tools like price_guard or get_spot_rate. An agent can tell immediately that this is the configuration/enumeration tool, not a pricing call.
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 gives an explicit directive — always call this rather than assuming supported pairs — which is exactly the routing guidance an agent needs before calling any Guard pricing sibling. It does not name a specific alternative tool or state when-not to call it, keeping it just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Net an SME's open foreign-currency bills and invoices, so that a receipt due on or before a payment in the same currency is shown as funding it. Returns the residual on every bill and invoice, a trace of which invoice funds which bill and for how much, per-bucket totals, dependency statements, and series for a ladder chart. It prices nothing: call price_guard on each residual separately, with the item's own due date as settlementDate. Never offsets across currencies. Items in base_currency are ignored. Cancelled items are excluded. Overdue items are listed separately and never netted. Set carry to true only when the client keeps receipts in a wallet or account in that currency, so a surplus can fund a later payment. If you do not know, ask the user whether they hold an account in each foreign currency before calling; do not guess. If their accounting platform is connected, offer to look up its bank accounts and their currencies there, and use what you find. If the answer is "not sure", call the tool twice, carry true and carry false, and show both charts; each carries its own scenario title, and chart_series.scenario holds the same words. THE RESULT HAS TWO PARTS: the JSON, then a PNG of the ladder chart rendered by the service. Show that image to the user as it is. PRESENTING THE RESULT: chart_series.currencies[ccy].open[] is the exposure. Present each open item on its own due date, with its label. Never add open items into one net figure, and never convert them to the base currency at spot. Do not call price_guard or show a Guard price unless the user asks for a price. If the user asks what they can do, lay out three things as facts and stop: do nothing (the amount stays exposed until paid), a forward from a bank or a payment provider (fixes the rate, provider margin inside the rate, an obligation that may need initial margin and margin calls, settled even if the payment does not happen), a Guard (fee known up front, market rate used if better, nothing further to pay if the payment does not happen). Do not rank them or say which fits. Never use the word "hedge". Do not draw a chart of your own from these numbers. DATES: the result carries today, the date the tool used. A due date the user gave without a year means the next such date on or after today, never a past year. If the result carries a warnings[] entry saying every item is before today, the dates are probably missing a year: confirm with the user and call again. Spec: docs/specs/net_exposure.md.
| Name | Required | Description | Default |
|---|---|---|---|
| carry | Yes | true when the client keeps receipts in a wallet or account in that currency, so a surplus can fund a payment in a later bucket. Surplus never rolls backward. | |
| items | Yes | Open bills and invoices | |
| bucket_days | No | Bucket length. Required for rolling_days. | |
| bucket_mode | Yes | calendar_month groups by month. rolling_days groups by bucket_days from today. guard_settlement_window makes one bucket per payable, window_days before its due date. | |
| window_days | No | Window length before each payable. Required for guard_settlement_window. | |
| base_currency | Yes | The client's home currency, e.g. GBP. Items in this currency are ignored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover read-only safety, but the description discloses a great deal more: never offsets across currencies, base-currency items ignored, cancelled items excluded, overdue listed separately and never netted, two-part JSON+PNG return, and warnings[] date heuristics. These are real behavioral traits beyond the 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?
Front-loaded with the netting purpose before the caveats, and the caps-sectioned structure (PRESENTING, DATES) aids scanning. It is very long, but given the number of destructive-adjacent rules and presentation constraints, most sentences earn their place.
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?
No output schema exists, yet the description describes the return shape (JSON plus PNG ladder chart, chart_series.currencies[ccy].open[], warnings[]), presentation rules, date handling, and a spec path. Nothing an agent needs to invoke it correctly is missing.
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 the baseline is 3, but the description adds genuine semantic guidance for carry (wallet/account condition, surplus never rolls backward, twin-scenario fallback) and clarifies base_currency exclusion and item filtering behavior beyond the schema text.
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?
States a specific verb (net) plus resource (open foreign-currency bills and invoices) and even the netting mechanism (a receipt due on or before a payment funds it). It clearly distinguishes itself from pricing siblings by declaring 'It prices nothing' and routing to 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?
Explicit when-to-use and when-not rules: call price_guard on each residual with the item's own due date; set carry only for wallet/account holders; ask the user if unknown; call twice on 'not sure'. It names alternatives (price_guard, forwards, banks) and the conditions that select them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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".
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
Get an indicative price for extending a Guard to a later settlement date. Estimates the additional cost using: (1) the guard fee difference between extended and original expiry, (2) the guard spread cost from the roll, and (3) the CurrencyGuard extension margin. Returns a breakdown: extensionCost = feeDifference + guardSpreadCost + extensionMargin. Both the original and extended quotes are priced at the same guard rate (the original quote's Guard rate), so the fee difference reflects purely the longer tenor, not market movement. Use this when a customer asks 'how much would it cost to extend my Guard by X months?' Parameters match price_guard plus the two dates.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 | |
| foreignCurrency | Yes | Foreign currency ISO code, e.g. USD | |
| extendedSettlementDate | Yes | Extended (new) settlement date in ISO format YYYY-MM-DD | |
| originalSettlementDate | Yes | Original settlement date in ISO format YYYY-MM-DD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly/destructive hints, so the description adds real behavioral value: it discloses this is an indicative estimate, enumerates the cost components, and explains the pricing convention (both quotes use the original guard rate so the fee difference reflects tenor, not market movement). It doesn't state error/edge-case behavior such as an extended date earlier than the original.
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?
Purpose is front-loaded in the first sentence, and the formula breakdown plus the pricing-convention note both earn their place. It runs slightly long with five sentences, but none is filler.
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?
With no output schema, the description compensates by describing the return shape (extensionCost = feeDifference + guardSpreadCost + extensionMargin), and annotations carry the safety profile. It is complete enough to call correctly, though it omits failure conditions and any precision/currency caveats.
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 only says parameters mirror price_guard plus the two settlement dates, adding no syntax or format detail beyond what the schema already provides.
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?
States a specific verb and resource ('Get an indicative price for extending a Guard to a later settlement date') and scopes it precisely. It is clearly distinguishable from siblings like price_guard (which prices a new guard) and compare_guard_with_forward.
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 routes the agent with the customer-facing cue 'how much would it cost to extend my Guard by X months?' and anchors itself to a sibling ('Parameters match price_guard plus the two dates'). It lacks an explicit when-not or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find out whether Guards can be bought through a particular payment provider or bank. A Guard is always bought through a payment provider, so this cannot be answered without knowing which one the user pays through — CurrencyGuard checks and replies. ASK BEFORE CALLING. Tell the user plainly that their provider, and their email address if they give one, will be sent to CurrencyGuard so they can answer. Call this only after they say yes. The email address is optional: the provider on its own is a complete enquiry, and without an address there is simply no one to reply to. Never take an email address from earlier in the conversation — only one the user has just given for this purpose. Never call this more than once in a conversation, and never after the user has declined.
| Name | Required | Description | Default |
|---|---|---|---|
| No | An email address the user has just given so CurrencyGuard can reply. Omit it unless they offered one for this purpose. | ||
| provider | Yes | The payment provider or bank the user pays foreign currency through, as they named it, e.g. Revolut, Wise, Barclays | |
| companyName | No | The name of the user's company, if they gave it. Omit otherwise. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and destructiveHint=false, which is thin. The description goes well beyond that: it names the external recipient (CurrencyGuard) that will receive the user's provider and optional email, requires an explicit consent step and a plain disclosure to the user, and imposes a hard one-call-per-conversation cap. Those are exactly the behavioral traits annotations cannot express.
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 purpose is front-loaded and every clause carries an instruction, but the consent and email rules are spread across several short sentences with some restatement (optional email, no address means no reply). Slightly denser than needed, though no sentence is truly filler.
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?
There is no output schema, so explanation of return values is not required. With three params, one required, an external-recipient disclosure, and consent/rate-limit rules fully spelled out, an agent has everything it needs to call this correctly and safely.
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 already 100%, so baseline is 3, but the description adds real meaning: provider alone is a complete enquiry, email is optional and needed only if the user just offered it, and an email must never be carried over from earlier in the conversation. That materially changes how the optional email parameter should be populated.
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?
States a specific verb and resource: find out whether Guards can be bought through a given payment provider or bank, and explicitly ties a Guard purchase to a payment provider. This is clearly distinguishable from siblings like price_guard, price_guard_extension, and get_spot_rate, which price rather than answer availability questions.
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?
Gives explicit when-to-use and when-not-to-use rules: ask the user first, call only after they say yes, never call more than once per conversation, and never call after the user declines. That is about as complete a routing/eligibility rule set as a tool description can carry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a relative time period (tenor) to a valid business settlement date for a currency pair. Use this when a user says '3 months', '6 months', '1 year', etc. instead of an exact date. The tenor format is: 1D (days), 1W (weeks), 1M (months), 1Y (years). Examples: '3M' = 3 months, '6M' = 6 months, '1Y' = 1 year. The returned date accounts for weekends and public holidays in both currencies' financial centres. Use the returned settlementDate as the exact date parameter for price_guard.
| Name | Required | Description | Default |
|---|---|---|---|
| tenor | Yes | Tenor string, e.g. 3M, 6M, 1Y | |
| currencyPair | Yes | Currency pair, e.g. GBPUSD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds substantive behavior beyond that: the result rolls forward over weekends and public holidays in both currencies' financial centres, which is exactly the context an agent needs to trust the output. Error handling for invalid tenors or pairs is not disclosed.
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 core purpose and trigger are front-loaded, and the length is reasonable for the amount of format detail conveyed. The format list and the examples ('3M' = 3 months, etc.) are partially redundant with each other, costing a little tightness.
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 two-parameter, read-only computation with no output schema, the description covers the purpose, the input format, the business-day adjustment logic and the downstream handoff. An agent has everything needed to invoke it correctly.
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 the baseline is 3, but the description goes further by enumerating valid tenor units (1D/1W/1M/1Y) and worked examples (3M, 6M, 1Y), clarifying the expected string format. The currencyPair parameter format is left largely to the schema's GBPUSD example.
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 states a specific verb and resource: converting a relative tenor into a valid business settlement date for a currency pair. It is clearly distinguishable from all siblings (none of which perform date resolution), and it names the downstream tool (price_guard) that consumes the result.
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?
Explicit trigger is given: 'Use this when a user says "3 months", "6 months"... instead of an exact date,' which also implies the when-not case. The handoff 'use the returned settlementDate as the exact date parameter for price_guard' adds routing value, but no sibling alternative for date resolution is named (there may be none).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare_guard_with_forward4 fields changedInput schema / properties / forwardMarginPct / descriptionPrevious 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."Input schema / properties / initialMarginPct / descriptionPrevious 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."Input schema / properties / marginCallThresholdPctAdded 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"
+}Input schema / properties / providerForwardRateAdded 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"
+}get_historic_best_worst2 fields changedInput schema / properties / guardAmount / descriptionPrevious value: -"Guard amount in base/home currency from the Guard quote (the guardAmount field from the price_guard response)"New value: +"Guard amount in base/home currency from the Guard quote (the guardAmount field from the price_guard response). Optional: leave it empty when there is no quote, and the tool uses today's indicative mid spot rate instead, so a risk question needs no price first."Input schema / requiredPrevious value: -[
- "guardCurrency",
- "foreignCurrency",
- "payReceive",
- "foreignAmount",
- "guardAmount",
- "settlementDate"
-]New value: +[
+ "guardCurrency",
+ "foreignCurrency",
+ "payReceive",
+ "foreignAmount",
+ "settlementDate"
+]net_exposurecompare_guard_with_forwardhello_worldrequest_provider_availabilityexplain_guard_product2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / requiredRemoved value: -[]get_forward_rate6 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / base / maxLengthAdded value: +3Input schema / properties / base / minLengthAdded value: +3Input schema / properties / quote / maxLengthAdded value: +3Input schema / properties / quote / minLengthAdded value: +3Input schema / properties / tenor / descriptionPrevious value: -"Tenor period, e.g. 1W, 1M, 3M, 6M, 1Y"New value: +"Tenor period such as 1W, 1M, 3M, 6M, 1Y, or an exact date as YYYY-MM-DD"get_historic_best_worst8 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / foreignAmount / exclusiveMinimumAdded value: +0Input schema / properties / foreignCurrency / maxLengthAdded value: +3Input schema / properties / foreignCurrency / minLengthAdded value: +3Input schema / properties / guardAmount / exclusiveMinimumAdded value: +0Input schema / properties / guardCurrency / maxLengthAdded value: +3Input schema / properties / guardCurrency / minLengthAdded value: +3Input schema / properties / payReceive / enumAdded value: +[
+ "PAY",
+ "RECEIVE"
+]get_spot_rate5 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / base / maxLengthAdded value: +3Input schema / properties / base / minLengthAdded value: +3Input schema / properties / quote / maxLengthAdded value: +3Input schema / properties / quote / minLengthAdded value: +3hello_worldlist_supported_currencies2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / requiredRemoved value: -[]price_guard9 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / foreignAmount / exclusiveMinimumAdded value: +0Input schema / properties / foreignCurrency / maxLengthAdded value: +3Input schema / properties / foreignCurrency / minLengthAdded value: +3Input schema / properties / guardCurrency / maxLengthAdded value: +3Input schema / properties / guardCurrency / minLengthAdded value: +3Input schema / properties / guardRate / descriptionPrevious 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."Input schema / properties / guardRate / exclusiveMinimumAdded value: +0Input schema / properties / payReceive / enumAdded value: +[
+ "PAY",
+ "RECEIVE"
+]price_guard_extension7 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / foreignAmount / exclusiveMinimumAdded value: +0Input schema / properties / foreignCurrency / maxLengthAdded value: +3Input schema / properties / foreignCurrency / minLengthAdded value: +3Input schema / properties / guardCurrency / maxLengthAdded value: +3Input schema / properties / guardCurrency / minLengthAdded value: +3Input schema / properties / payReceive / enumAdded value: +[
+ "PAY",
+ "RECEIVE"
+]resolve_settlement_date1 field changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"explain_guard_product1 field changedInput schema / additionalPropertiesRemoved value: -falseget_forward_rate1 field changedInput schema / additionalPropertiesRemoved value: -falseget_historic_best_worst1 field changedInput schema / additionalPropertiesRemoved value: -falseget_spot_rate1 field changedInput schema / additionalPropertiesRemoved value: -falselist_supported_currencies1 field changedInput schema / additionalPropertiesRemoved value: -falseprice_guard1 field changedInput schema / additionalPropertiesRemoved value: -falseprice_guard_extension1 field changedInput schema / additionalPropertiesRemoved value: -falseresolve_settlement_date1 field changedInput schema / additionalPropertiesRemoved value: -falseexplain_guard_productget_forward_rateget_historic_best_worstget_spot_ratelist_supported_currenciesprice_guardprice_guard_extensionresolve_settlement_dateLive FX + official central-bank rates, 110+ sources. Hosted, keyless, nothing to install.
Convert currencies and fetch blended FX rates from 50+ institutional sources.
Live & historical FX rates and currency conversion for AI agents. No API keys.
Live & historical FX rates and currency conversion for AI agents. No API keys.
Add one secure layer between your agents and this server.
