another fred mcp server?

When I built ferric-fred — a typed Rust client for FRED, with a CLI and an MCP server — I did the sensible thing only afterwards, and looked around. FRED MCP servers already exist. Several of them: Stefano Amorelli’s in TypeScript, a handful in Python, enough that they turn up in the round-ups of finance MCP servers. So the fair question is: why another?

what the others do well

The existing servers cover the path most people want — search for a series, pull its observations, maybe transform the units — and several install with nothing more than npx or uvx: no build, no binary to keep track of. If that is your need, they are a quick and genuinely good way to hand an assistant some economic data. I am not writing this to knock them; I reach for FRED more because tools like them exist.

ferric-fred started from a different place — a strongly-typed library, with the MCP server as one consumer of it — and three differences fell out of that.

it covers the whole read API

FRED is a good deal more than series and observations. There is a category tree, a release calendar, the sources behind each release, a tag vocabulary you can pivot through, the dates on which a series was revised, and the nested release-table tree. fred-mcp wraps all of it — thirty-one tools — so an assistant can browse and discover, not only fetch a series whose id it already knows. Ask it which releases the Bureau of Labor Statistics puts out, or which tags sit alongside “unemployment”, and there is a tool for that. The release-table tree and the vintage (revision) dates in particular are corners most wrappers skip.

it is a single binary

Being Rust, fred-mcp compiles to one self-contained executable — no Node or Python runtime, no package resolution at launch. That is the flip side of the npx convenience: you install a binary (or cargo install it), and in return the thing that runs is fixed and dependency-free. For a server a client spawns afresh on every session, I like that trade.

the core is typed, and shared

The server is a thin shell over the same library the CLI uses. Ids are newtypes, FRED’s value sets are enums, and a malformed response is a typed error rather than a panic. So the three ways in — library, terminal, MCP — cannot quietly disagree about what a release, or a tag, or a date actually is.

on speed

I was curious enough to run the race. Spawning each server on the same machine and timing it from launch to a completed MCP handshake — twenty times apiece, the same little harness for all three:

So ferric-fred starts roughly thirty times quicker than the Node server and a hundred times quicker than the Python one, and idles seven-to-ten times lighter — which is what you would expect from a compiled binary with no runtime to load, now measured rather than assumed. On disk it is one 8 MB file, against a 26 MB node_modules or a Python venv.

Two caveats keep it honest. First, this is startup and memory, not answer latency: every FRED server makes the same HTTP call to the Fed, and that round-trip — plus the model’s own thinking — dwarfs the milliseconds the server itself spends. You will not feel 8 ms against 800 mid-conversation. Where it shows is in spawning and restarting, running a few servers at once, a small box, and the footprint. Second, each of these is one implementation among several, measured on one machine; the harness and full method are in the repo if you would rather run your own.

if it suits you

If you want breadth across the whole FRED surface, a single binary to deploy, or the same data outside an agent — in a shell script, a terminal chart, or a Rust program — ferric-fred may be the better fit. If you only need search-and-observations with zero install, the existing servers have you covered, and that is perfectly fine.

Grab a free API key, then:

cargo install ferric-fred-mcp   # the fred-mcp server

Point your client at the fred-mcp binary with FRED_API_KEY in its environment, and you are away. The repository has the full tool list and the reasoning behind the design.