Skip to main content
Glama
nicoloceneda

Fred St Louis MCP

by nicoloceneda

fred_request

Access FRED economic data by calling API endpoints directly to retrieve financial datasets and observations for research.

Instructions

Call any FRED API v1 endpoint path directly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endpointYes
params_jsonNo{}

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The fred_request tool handler function. It takes an endpoint string and optional JSON params, parses the params, and delegates to _fred_get to make the FRED API v1 call. Decorated with @mcp.tool() for MCP registration and @_tool_error_boundary for error handling.
    @mcp.tool()
    @_tool_error_boundary
    async def fred_request(endpoint: str, params_json: str = "{}") -> dict[str, Any]:
        """Call any FRED API v1 endpoint path directly."""
        params = _parse_json_object(params_json)
        return await _fred_get(endpoint, params)
  • The _fred_get helper function that makes the actual HTTP call to the FRED API v1 base URL. Called by the fred_request handler.
    async def _fred_get(endpoint: str, params: dict[str, Any]) -> dict[str, Any]:
        return await _http_get_json(FRED_API_BASE, endpoint, params)
  • The _parse_json_object helper function that parses the params_json string argument into a dictionary. Validates that the JSON is an object.
    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
  • fred_mcp/app.py:1-8 (registration)
    Creates the FastMCP instance named 'fred-mcp' which is imported and used via @mcp.tool() decorator to register tools like fred_request.
    from mcp.server.fastmcp import FastMCP
    
    mcp = FastMCP(
        "fred-mcp",
        instructions=(
            "Query FRED API v1, GeoFRED maps API, and FRED API v2 release observations."
        ),
    )
  • The _tool_error_boundary decorator that wraps the fred_request handler to catch exceptions (FredServerError, ValueError, etc.) and convert them to error payload dictionaries for graceful error handling.
    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
Behavior1/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 fails to mention critical traits such as authentication requirements, rate limits, error handling, or the fact that it's a direct API call (which implies it might bypass built-in validation or safety checks). The description is minimal and offers no behavioral context beyond the basic action.

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 a single, efficient sentence that front-loads the core purpose without unnecessary words. It earns its place by clearly stating the tool's function, making it appropriately sized for a generic API tool.

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

Completeness2/5

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

Given the complexity of calling arbitrary API endpoints (which requires understanding endpoint paths, parameter formats, and potential side effects), the description is inadequate. No annotations exist to cover safety or behavioral aspects, and while an output schema is present, the description doesn't address critical context like authentication, error cases, or when to prefer specialized tools over this generic one.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for the two parameters, the description adds no semantic information beyond what the schema provides. It doesn't explain what 'endpoint' should contain (e.g., path format, examples) or how 'params_json' should be structured (e.g., JSON string details). The description fails to compensate for the lack of schema documentation, leaving parameters largely unexplained.

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 action ('Call') and target ('any FRED API v1 endpoint path directly'), providing a specific verb+resource combination. It distinguishes itself from sibling tools by being a generic API caller rather than a specialized function, though it doesn't explicitly contrast with 'fred_v2_request' which is a notable omission.

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 the many specialized sibling tools (e.g., 'get_series', 'search_series') or the 'fred_v2_request' alternative. It lacks context about appropriate use cases, prerequisites, or exclusions, leaving the agent to infer usage from the generic nature of the tool.

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