Skip to main content
Glama
nicoloceneda

Fred St Louis MCP

by nicoloceneda

fred_v2_request

Query FRED API v2 endpoints to access economic data for research and analysis.

Instructions

Call any FRED API v2 endpoint path directly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endpointYes
params_jsonNo{}

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The main handler function for the fred_v2_request tool. It is decorated with @mcp.tool() to register it as an MCP tool and @_tool_error_boundary for error handling. Takes endpoint and params_json parameters, parses the JSON params, and delegates to _fred_v2_get to make the actual API call.
    @mcp.tool()
    @_tool_error_boundary
    async def fred_v2_request(endpoint: str, params_json: str = "{}") -> dict[str, Any]:
        """Call any FRED API v2 endpoint path directly."""
        params = _parse_json_object(params_json)
        return await _fred_v2_get(endpoint, params)
  • The _fred_v2_get helper function that executes the HTTP request to the FRED API v2 endpoint. It calls _http_get_json with the FRED_V2_API_BASE URL, passes the API key via headers (instead of query params), and handles the actual API communication with retry logic and error handling.
    async def _fred_v2_get(endpoint: str, params: dict[str, Any]) -> dict[str, Any]:
        return await _http_get_json(
            FRED_V2_API_BASE,
            endpoint,
            params,
            headers={"api_key": _fred_api_key()},
            include_api_key_query=False,
        )
  • The _parse_json_object helper function that validates and parses the params_json string input. It ensures the JSON is valid and is a dictionary object, raising a ValueError if either condition is not met.
    def _parse_json_object(raw: str) -> dict[str, Any]:
        try:
            parsed = json.loads(raw)
        except json.JSONDecodeError as exc:
            raise ValueError(f"Invalid JSON: {exc}") from exc
        if not isinstance(parsed, dict):
            raise ValueError("JSON value must be an object")
        return parsed
  • The _tool_error_boundary decorator that wraps tool handlers with comprehensive error handling. Catches FredServerError, ValueError, and other exceptions, returning appropriate error payloads. Ensures CancelledError propagates correctly and logs unhandled exceptions.
    def _tool_error_boundary(
        func: Callable[..., Awaitable[dict[str, Any]]],
    ) -> Callable[..., Awaitable[dict[str, Any]]]:
        @wraps(func)
        async def wrapper(*args: Any, **kwargs: Any) -> dict[str, Any]:
            try:
                return await func(*args, **kwargs)
            except asyncio.CancelledError:
                raise
            except FredServerError as exc:
                return exc.payload
            except ValueError as exc:
                return _error_payload(
                    str(exc),
                    code="validation_error",
                    error_type="validation_error",
                )
            except Exception as exc:
                logger.exception("Unhandled tool error in '%s'", func.__name__)
                return _error_payload(
                    "Internal server error",
                    code="internal_error",
                    error_type="internal_error",
                    details={"exception_type": type(exc).__name__},
                )
    
        return wrapper
  • fred_mcp/app.py:3-8 (registration)
    The FastMCP instance creation that provides the @mcp.tool() decorator used to register fred_v2_request as an MCP tool. The instance is configured with the name 'fred-mcp' and instructions describing the available API endpoints.
    mcp = FastMCP(
        "fred-mcp",
        instructions=(
            "Query FRED API v1, GeoFRED maps API, and FRED API v2 release observations."
        ),
    )
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool calls API endpoints but doesn't mention authentication requirements, rate limits, error handling, or what the output looks like. For a tool that interacts with an external API, this is a significant gap in transparency, as agents need to understand these behavioral traits to use it effectively.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise and front-loaded with a single sentence: 'Call any FRED API v2 endpoint path directly.' It wastes no words and immediately conveys the core functionality, making it easy for an agent to parse and understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (direct API calls with 2 parameters) and the presence of an output schema, the description is somewhat complete but lacks crucial details. The output schema likely handles return values, but without annotations and with low parameter coverage, the description should provide more context on usage, authentication, or error handling to be fully adequate for an agent.

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?

The description adds minimal meaning beyond the input schema. It implies 'endpoint' refers to a FRED API v2 path and 'params_json' is for parameters, but with 0% schema description coverage, it doesn't explain the format or examples (e.g., endpoint syntax, JSON structure). Since schema coverage is low, the description should compensate more but only provides basic context, meeting the baseline for moderate value addition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Call any FRED API v2 endpoint path directly.' It specifies the action ('Call') and resource ('FRED API v2 endpoint path'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate itself from sibling tools like 'fred_request' or 'geofred_request', which appear to be similar API-calling tools, so it misses full sibling differentiation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., 'fred_request', 'get_series', 'search_series'), there's no indication of when this direct API call is preferred over more specific tools. This lack of context leaves the agent guessing about appropriate usage scenarios.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nicoloceneda/mcp-fred'

If you have feedback or need assistance with the MCP directory API, please join our Discord server