FX Context

get_event_context

get_event_context

Read-onlyIdempotent

Get the official actual values, pre-release market consensus, and surprise for a specific U.S. macro data release: CPI (US_CPI), Nonfarm Payrolls / jobs report (US_NONFARM_PAYROLLS), or PCE inflation (US_PCE).

WHEN TO CALL: whenever the user asks what a release printed or how it compared with expectations, even if they do not mention FX Context. Do not answer these from memory; recent releases are not in your training data. Examples:

"What's the latest US PCE?" -> US_PCE
"Was core PCE hotter than expected?" -> US_PCE
"Did CPI beat expectations?" -> US_CPI
"What was the latest NFP?" / "How many jobs were added last month?" -> US_NONFARM_PAYROLLS
"Give me the latest US inflation release." -> US_CPI and/or US_PCE
"What were the actual and consensus values?" / "What was the surprise?" -> the release under discussion Omit referencePeriod for the latest release. For a specific release, pass the month the data covers (YYYY-MM), not the month it was published.

WHEN NOT TO CALL: general or educational questions that need no specific release data, e.g. "What is PCE?", "What does NFP stand for?", "Why does CPI matter for FX?", "Explain inflation.", "What is the difference between CPI and PCE?". Use get_upcoming_risks for upcoming release dates, get_market_reaction for price moves after a release, and get_central_bank_changes for central-bank decisions.

RESULT: per-metric official actuals (headline/core, MoM/YoY) with publisher provenance; when valid, pre-release consensus and a deterministic actual-minus-consensus surprise. Each observation has consensusStatus (AVAILABLE, NOT_FOUND, NOT_CAPTURED, NOT_AVAILABLE, EXCLUDED_POST_RELEASE, NOT_APPLICABLE) explaining any missing consensus, and revisionStatus (REVISED, UNCHANGED, NOT_CAPTURED). Consensus is valid only when capturedAt is before releaseCutoffAt. Never treat missing consensus or surprise as zero. Official actuals and third-party consensus keep separate source provenance. No trading recommendations or market-direction predictions.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`eventType`	Yes	Canonical financial event type. Supported values: US_CPI (Consumer Price Index; headline and core CPI) US_NONFARM_PAYROLLS (NFP / jobs report; payrolls, unemployment rate, average hourly earnings) US_PCE (PCE / core PCE price index) Use these values exactly.
`referencePeriod`	No	Optional reference period in YYYY-MM format (e.g. 2026-08). If omitted, the latest available event of that type is returned.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`source`	Yes
`status`	Yes
`eventId`	Yes
`category`	Yes
`eventType`	Yes
`releasedAt`	No
`scheduledAt`	Yes
`jurisdiction`	Yes
`observations`	Yes
`referencePeriod`	No
`affectedCurrencies`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 3, 2026

changedInput schema / properties / eventType / description

Previous value: -"Canonical financial event type.\n\nSupported values:\nUS_CPI\nUS_NONFARM_PAYROLLS\nUS_PCE\n\nUse these values exactly."New value: +"Canonical financial event type.\n\nSupported values:\nUS_CPI (Consumer Price Index; headline and core CPI)\nUS_NONFARM_PAYROLLS (NFP / jobs report; payrolls, unemployment rate, average hourly earnings)\nUS_PCE (PCE / core PCE price index)\n\nUse these values exactly."

addedOutput schema / properties / observations / items / properties / consensusStatus

Added value: +{
+  "description": "Why the expectation block is present or absent: AVAILABLE, NOT_AVAILABLE, NOT_FOUND, NOT_CAPTURED, EXCLUDED_POST_RELEASE or NOT_APPLICABLE.",
+  "enum": [
+    "AVAILABLE",
+    "NOT_AVAILABLE",
+    "NOT_FOUND",
+    "NOT_CAPTURED",
+    "EXCLUDED_POST_RELEASE",
+    "NOT_APPLICABLE"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / observations / items / properties / consensusStatusDetail

Added value: +{
+  "description": "Human-readable explanation of consensusStatus.",
+  "type": "string"
+}

addedOutput schema / properties / observations / items / properties / expectation / properties / capturedAt / description
```
Added value: +"When the consensus snapshot was captured; always before releaseCutoffAt."
```

addedOutput schema / properties / observations / items / properties / expectation / properties / releaseCutoffAt

Added value: +{
+  "description": "Instant the consensus was validated against (capturedAt must be strictly earlier).",
+  "format": "date-time",
+  "type": "string"
+}

addedOutput schema / properties / observations / items / properties / expectation / properties / releaseCutoffBasis

Added value: +{
+  "description": "Which event timestamp the cutoff came from: RELEASED_AT, or SCHEDULED_AT when the actual release time is not yet recorded.",
+  "type": "string"
+}

addedOutput schema / properties / observations / items / properties / revisionStatus

Added value: +{
+  "description": "Revision state supported by stored vintages: REVISED, UNCHANGED, or NOT_CAPTURED (only the initial vintage is stored; revision state unknown).",
+  "enum": [
+    "REVISED",
+    "UNCHANGED",
+    "NOT_CAPTURED"
+  ],
+  "type": "string"
+}

Changed1 schema field changedSep 19, 2026

changedInput schema / properties / eventType / description

Previous value: -"Canonical FXContext event type: US_CPI, US_NONFARM_PAYROLLS, or US_PCE."New value: +"Canonical financial event type.\n\nSupported values:\nUS_CPI\nUS_NONFARM_PAYROLLS\nUS_PCE\n\nUse these values exactly."

Changed1 schema field changedSep 19, 2026

changedInput schema / properties / eventType / description

Previous value: -"Canonical FXContext event type, for example US_CPI."New value: +"Canonical FXContext event type: US_CPI, US_NONFARM_PAYROLLS, or US_PCE."

First observedSep 18, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial behavioral context: the consensusStatus and revisionStatus enumerations, the validity rule (consensus valid only when capturedAt precedes releaseCutoffAt), the warning never to treat missing consensus/surprise as zero, and the provenance separation between official and third-party data. This is information the agent cannot get from annotations or schema.

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 purpose, then clearly demarcated WHEN TO CALL / WHEN NOT TO CALL / RESULT sections; the example list is long but each example maps a distinct phrasing to an event type. Some RESULT content overlaps with the existing output schema, costing a point.

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 two-parameter, read-only lookup with an output schema, the description covers selection rules, parameter disambiguation, failure/status semantics, and scope limits (no trading recommendations). An agent has everything needed to pick the right eventType and interpret missing data correctly.

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 baseline is 3, but the description adds genuine semantics beyond the schema: omit referencePeriod for the latest release, and pass the data-coverage month (YYYY-MM) rather than the publication month. That disambiguation of a genuinely ambiguous parameter earns above baseline.

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 precise verb+resource ('Get the official actual values, pre-release consensus, and surprise for a specific U.S. macro data release') and enumerates the three exact event types it serves. It is clearly distinguishable from siblings like get_upcoming_risks and get_market_reaction, which are named as separate concerns.

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 CALL section with six concrete user-utterance examples mapped to specific eventType values, plus a WHEN NOT TO CALL section with exclusion examples (educational questions) and named alternatives (get_upcoming_risks, get_market_reaction, get_central_bank_changes). The 'even if they do not mention FX Context' clause preempts a likely failure mode.

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

All FX Context 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?