MCP server for accessing FRED (Federal Reserve Economic Data) API
FRED MCP Server provides 2 tools with clear verb-based naming (search, series) and complete input schemas with proper type definitions and descriptions. Descriptions are adequate (145-180 chars, within the 10-1024 baseline range). Parameter descriptions are present and mostly detailed. However, output schemas are entirely undocumented, callers cannot see what fields to expect from responses. Error handling is minimal (generic HTTP errors with no recovery guidance or retry classification). Parameter relationships and constraints are inconsistently documented. No input validation, pagination metadata, or result limits are mentioned. The server follows basic MCP structure but lacks production-grade polish in output definition and error guidance.
Search for FRED data series with advanced filtering options
Get observations for a specific FRED data series with advanced options
Output schemas completely undocumented. Tools return `data.seriess` (search) and `data.observations` (series) but callers cannot know what fields these arrays contain, what types they are, or how to chain results to downstream operations.
No result limits documented or enforced. search() defaults to limit=1000 (mentioned in param description) but does not cap or paginate. series() offers limit and offset but no guidance on maximum safe values. Large result sets will blow token budgets and degrade reasoning.
Error handling is generic and non-actionable. Both handlers throw 'FRED API error: <statusText>' with no recovery guidance, retry classification, or context on what failed. LLM has no signal on whether to retry, ask the user, or try a different tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Parameter constraints underdocumented. 'orderBy' enum is comprehensive but no guidance on FRED series availability or how to discover valid tags for 'tagNames'. 'frequency' enum is cryptic (d=daily, etc.), explanation is in description but not standardized. 'outputType' enum (1,2,3,4) is opaque and will confuse LLMs.
No tool annotations (readOnlyHint, idempotentHint, etc.). Both tools are read-only and safe to retry, but this is not declared. LLMs cannot infer safety without explicit hints.
Tool composition and chaining data missing. After search() returns results, what field contains the series ID to pass to series()? (Likely 'id' but not documented.) After series() returns observations, what structure do they have? This forces LLMs to guess or fail mid-chain.