Skip to main content
Glama

CurrencyGuard Guard Pricing

Net Foreign-Currency Items

net_exposure
Read-only

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.

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": {
      "base_currency": "<base_currency>",
      "items": "<items>",
      "bucket_mode": "<bucket_mode>",
      "carry": "<carry>"
    },
    "name": "net_exposure"
  }
}

Input Schema

NameRequiredDescriptionDefault
carryYestrue 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.
itemsYesOpen bills and invoices
bucket_daysNoBucket length. Required for rolling_days.
bucket_modeYescalendar_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_daysNoWindow length before each payable. Required for guard_settlement_window.
base_currencyYesThe client's home currency, e.g. GBP. Items in this currency are ignored.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations declare a safe read operation, and the description adds substantial non-obvious behavior: cancelled items excluded, overdue items listed but never netted, base-currency items ignored, no cross-currency offsetting, and the two-part return (JSON plus a service-rendered PNG ladder chart). It also discloses edge-case handling such as the warnings[] entry for items all before today.

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?

Purpose and scoping are front-loaded, which is good, but the bulk of the text is output-presentation policy and conversational instructions (never say 'hedge', lay out three options as facts and stop, do not draw your own chart) rather than tool-selection information. Much of that belongs in a system prompt, and the result is a dense block far longer than the tool contract requires.

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?

There is no output schema, yet the description names the key return fields (chart_series.currencies[ccy].open[], chart_series.scenario, warnings[], the today date) and the attached PNG, so an agent knows what comes back and how to use it. Edge cases around missing years and multi-currency questions are covered.

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 coverage is 100%, so the schema already documents all six parameters and the baseline applies. The description adds some meaning beyond it for carry (only true when the client holds an account in that currency, surplus funds a later payment) and for due-date interpretation, but says nothing extra about bucket_mode, bucket_days or window_days.

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?

The opening sentence states a specific verb and resource: net an SME's open foreign-currency bills and invoices, with a clear scoping rule (receipts due on or before a payment in the same currency fund it). It is clearly distinguishable from siblings such as price_guard, which the description explicitly defers pricing to.

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?

Explicit routing guidance: call price_guard on each residual separately with the item's own due date as settlementDate, and do not call it unless the user asks for a price. It also gives the carry=true condition, tells the agent to ask the user rather than guess, and prescribes a two-call comparison when the answer is 'not sure'.

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