Hedgr FX Risk & Treasury

get_fx_exposure

Read-only

Returns net FX exposure by currency pair, entity, and time bucket (overdue, 0-30d, 31-60d, 61-90d, 90d+, undated). An invoice with no due date has no tenor, so it stays in net exposure and sits in the undated bucket. Each exposure line distinguishes confirmed (invoices and POs from the accounting system) from forecasted, and includes a source field citing provenance ('€2.3M from 47 Xero invoices'). On multi-entity books the exposure honours the workspace inter-company mode and the response carries an intercompany block naming that mode; realised P&L does not move with that mode, and it is reported as the accounting system recorded it, so settled inter-company invoices stay inside it. On an unscoped call also returns counterparty_concentration (per contact/currency/direction with share of gross exposure), risk_snapshot (top currency and share, signed and gross net position, breach and overdue counts, worst-case as published), sensitivity (impact of a 1% move per currency) and total_net_exposure_base, all lifted from the same context the in-app Scout assistant answers from.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_fx_exposure"
  }
}

Input Schema

Name	Required	Description
`currency`	No	ISO 4217 code to filter to one currency (e.g. 'EUR', 'USD'). Omit for all currencies.
`entity_id`	No	Specific entity ID from list_entities. Omit for consolidated group exposure.
`horizon_days`	No	Forward-looking window in days.
`include_chart`	No	When true, the tool response includes an image/png content block containing a horizontal bar chart of net exposure by currency (green = receivable, red = payable). Requires no additional API calls - uses the same data as the text response.
`include_forecasted`	No	Include forecasted exposure alongside confirmed accounting-system data.

Output Schema

Name	Required	Description	Default
`data`	Yes	Tool-specific payload. Null when connection_status.state is 'setup_required'.
`connection_status`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 6, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations only declare the read-only/safe profile, and the description goes well beyond that: bucket definitions, undated-invoice handling, confirmed-vs-forecasted distinction, provenance in a source field, inter-company mode honoring, the caveat that realised P&L does not move with that mode, and the additional blocks returned on an unscoped call. This is rich behavioral context an agent could not get from the structured fields.

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?

The core purpose and bucketing scheme are front-loaded, and each sentence carries genuine behavioral content rather than filler. The remaining text is extremely dense and packs multiple concepts per sentence, which slightly hurts scannability but does not waste words.

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?

For a read-only analytical tool with a full schema and an output schema, the description is more than complete: it explains what the payload contains, how scoping changes the result, and edge-case semantics (undated buckets, inter-company mode). An agent has everything needed to call and interpret it.

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 description coverage is 100%, so the schema already documents all five parameters with formats and defaults. The description adds only indirect meaning via the scoping discussion ('unscoped call', currency/entity filtering implied), so the baseline 3 is appropriate.

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 and resource ('Returns net FX exposure') and enumerates the dimensions of the result (currency pair, entity, time bucket). It is clearly distinguishable from siblings like get_fx_guidance or get_hedge_portfolio, which cover guidance and hedging rather than raw exposure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies usage through conditional behavior ('On an unscoped call also returns counterparty_concentration...'), effectively telling the agent that omitting filters yields a broader payload. However, it never explicitly states when to choose this tool over siblings such as get_fx_guidance or get_hedge_portfolio, leaving routing to inference.

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

All Hedgr FX Risk & Treasury tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?