As MCP adoption accelerates, teams are no longer asking whether to use MCP. They are asking which transport to use, where the server should run, and how to secure it for production workloads.
This guide compares the practical connection models you can use with FXMacroData: a local STDIO server, the hosted remote server, and the authentication choices (OAuth or an API key) that sit on top of either.
The Two MCP Transports in Practice
The MCP specification defines two standard transports:
- STDIO: the client launches the MCP server as a local subprocess and exchanges JSON-RPC messages over stdin/stdout.
- Streamable HTTP: the client talks to a remote server over HTTPS. The server may answer each request with a plain JSON response or stream a sequence of messages, and may optionally track a session through an
Mcp-Session-Idheader.
The older HTTP+SSE transport from the 2024-11-05 specification has been superseded by Streamable HTTP. If a client asks you to pick between "SSE" and "Streamable HTTP" for a new server, choose Streamable HTTP.
Both transports can expose the same tools. The tradeoff is operational shape: who runs the process, where credentials live, and how updates roll out.
1. STDIO: Best for Local Development and Tight Tooling Loops
STDIO is the simplest model to reason about. Your MCP client spawns a local process and communicates over stdin/stdout, so there is no listening port on your machine.
FXMacroData publishes an open-source STDIO server on PyPI as mcp-server-fxmacrodata. It runs with uvx, so there is nothing to install permanently. A Claude Desktop entry in claude_desktop_config.json looks like this:
{
"mcpServers": {
"fxmacrodata": {
"command": "uvx",
"args": ["mcp-server-fxmacrodata"],
"env": {
"FXMACRODATA_API_KEY": "YOUR_API_KEY"
}
}
}
}
Without the FXMACRODATA_API_KEY variable the server still works for public USD data, so you can evaluate it before adding a key. With a key, it unlocks the currencies and datasets on your plan.
When to choose STDIO: single-user desktop sessions, local coding assistants, and environments where you want the server process and its credentials under your own control.
2. Remote Streamable HTTP: Best for Teams and Hosted Agents
The hosted FXMacroData MCP server lives at https://mcp.fxmacrodata.com and uses Streamable HTTP. There is no local process to keep updated, new tools appear for every user at once, and authentication is handled by the server rather than by an environment variable on each laptop.
A multi-step workflow, such as checking release calendar events, pulling recent macro prints, then drafting a note for USD/JPY, runs as a sequence of tool calls against the same endpoint.
In Claude Code, add the remote server from the command line. Clients that support MCP OAuth will open a browser sign-in the first time a protected tool is used:
claude mcp add --transport http fxmacrodata https://mcp.fxmacrodata.com
If you prefer to send an API key instead of signing in, pass it as a bearer header:
claude mcp add --transport http fxmacrodata https://mcp.fxmacrodata.com \
--header "Authorization: Bearer YOUR_API_KEY"
The equivalent project-scoped .mcp.json entry for Claude Code uses "type": "http":
{
"mcpServers": {
"fxmacrodata": {
"type": "http",
"url": "https://mcp.fxmacrodata.com",
"headers": {
"Authorization": "Bearer ${FXMD_API_KEY}"
}
}
}
}
Referencing an environment variable keeps the key out of a file that may be committed. In Claude Desktop and on claude.ai, remote servers are added as a custom connector in Settings by pasting the server URL, after which the OAuth sign-in runs in the browser.
For your own agent code, the official MCP Python SDK connects with its Streamable HTTP client:
import os
from mcp import ClientSession
from mcp.client.streamable_http import streamablehttp_client
async def list_tools():
headers = {"Authorization": f"Bearer {os.environ['FXMD_API_KEY']}"}
async with streamablehttp_client("https://mcp.fxmacrodata.com", headers=headers) as (read, write, _):
async with ClientSession(read, write) as session:
await session.initialize()
tools = await session.list_tools()
return [tool.name for tool in tools.tools]
When to choose remote: shared team setups, hosted agents and backend orchestrators, browser-based assistants, and any environment where you would rather manage access through sign-in than distribute keys.
Local vs Remote: A Common Hybrid
Many teams use both. Developers prototype prompts and tool sequences against the local STDIO server, then point integration tests and production agents at the hosted endpoint so every environment sees the same tool set and the same access policy.
Ways to Connect to FXMacroData
- MCP for tool-based AI workflows and protocol-native clients.
- The REST API for scripts, batch jobs, caching layers, and deterministic service-to-service integrations.
REST requests send the API key in the X-API-Key header:
curl -H "X-API-Key: YOUR_API_KEY" "https://api.fxmacrodata.com/v1/announcements/usd/inflation"
To check what a tool should return, compare against the indicator pages, such as US inflation, the Federal Reserve policy rate, and US Non-Farm Payrolls.
Security Models: OAuth vs API Key
Transport choice and authentication choice are separate decisions. The hosted server accepts either.
OAuth
OAuth 2.0 with PKCE is the better default for interactive clients. The user signs in through the browser, the client receives a revocable access token, and no long-lived secret is copied into a config file. Clients that implement the MCP authorization specification discover the OAuth endpoints from the server URL automatically.
Good practices: let the client manage token storage and refresh, revoke access from your account when a device or tool is retired, and review which clients you have approved.
API Key
An API key is simple for machine-to-machine use: CI jobs, scheduled agents, and backend services where no person is present to sign in. Send it as Authorization: Bearer YOUR_API_KEY to the MCP server, or in the X-API-Key header for REST.
Good practices: keep keys in a secret manager or environment variable rather than in committed files, use separate keys per environment where your plan allows, and rotate a key immediately if it appears in logs or a repository.
Choosing Between Them
- Use OAuth when a person is using an assistant interactively.
- Use an API key for unattended, server-owned workloads.
- Avoid putting keys in URLs. Query-string credentials end up in proxy logs, browser history, and screenshots; a header is safer whenever the client supports one.
Threat Model Checklist by Transport
STDIO: the server runs with your user's permissions, so install packages only from the publisher's official source, pin versions in shared setups, and keep the API key in the client's env block or your environment rather than in shell history.
Remote HTTP: connect only over HTTPS to the publisher's documented hostname, prefer OAuth for people and bearer keys for services, and log which tools your agents call.
Across both, apply least privilege and keep an audit trail of tool calls that can influence trading or risk decisions, including those informed by COT positioning and cross-asset context from commodities.
Practical Recommendation
- Start with the hosted server and OAuth if your client supports it. It is the fastest path with no local install.
- Use the STDIO package when you want a local, self-contained process or your client only supports STDIO.
- Use API keys as bearer headers for unattended agents, and the REST API for batch jobs and caching layers.
Treat transport as an operational decision and authentication as a trust decision. Keeping them separate lets your MCP setup change as your team and tooling grow.
Get Started
The MCP server documentation has setup steps for Claude, ChatGPT, Codex, Cursor, VS Code, and other clients. Once connected, validate a first data path with a concrete series such as inflation or the policy rate, then build out one end-to-end agent workflow around a single pair before expanding scope.
