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.

Input Schema

TableJSON 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.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

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 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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources