Skip to main content
Glama
nicoloceneda

Fred St Louis MCP

by nicoloceneda

get_category

Retrieve FRED economic data categories by ID to organize and filter datasets for research and analysis.

Instructions

fred/category

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
category_idNo
realtime_startNo
realtime_endNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The main handler function for the 'get_category' MCP tool. Decorated with @mcp.tool() for registration and @_tool_error_boundary for error handling. Calls _fred_get to fetch category data from FRED API and returns the first category or an error payload if not found.
    @mcp.tool()
    @_tool_error_boundary
    async def get_category(
        category_id: int = 0,
        realtime_start: str | None = None,
        realtime_end: str | None = None,
    ) -> dict[str, Any]:
        """fred/category"""
        data = await _fred_get(
            "category",
            {
                "category_id": category_id,
                "realtime_start": realtime_start,
                "realtime_end": realtime_end,
            },
        )
        categories = data.get("categories", [])
        if not categories:
            return _error_payload(
                f"Category '{category_id}' not found",
                code="not_found",
                error_type="not_found",
                details={"resource": "category", "resource_id": category_id},
            )
        return categories[0]
  • fred_mcp/app.py:1-8 (registration)
    Creates the FastMCP instance 'mcp' which provides the @mcp.tool() decorator used to register the get_category function as an MCP tool.
    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 _fred_get helper function that makes the actual HTTP request to the FRED API. Called by get_category to fetch category data.
    async def _fred_get(endpoint: str, params: dict[str, Any]) -> dict[str, Any]:
        return await _http_get_json(FRED_API_BASE, endpoint, params)
  • The _tool_error_boundary decorator that wraps the get_category handler to catch and convert exceptions (FredServerError, ValueError, etc.) into standardized error payloads.
    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
  • The _error_payload helper function that creates standardized error response dictionaries. Used by get_category when a category is not found.
    def _error_payload(
        message: str,
        *,
        code: str,
        error_type: str,
        base_url: str | None = None,
        endpoint: str | None = None,
        status_code: int | None = None,
        retryable: bool = False,
        details: dict[str, Any] | None = None,
    ) -> dict[str, Any]:
        # Keep top-level "error" for backwards compatibility with existing clients.
        return {
            "error": message,
            "error_details": {
                "type": error_type,
                "code": code,
                "base_url": base_url,
                "endpoint": endpoint.strip("/") if endpoint else None,
                "status_code": status_code,
                "retryable": retryable,
                "details": details or {},
            },
        }
Behavior1/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. The description 'fred/category' reveals nothing about whether this is a read or write operation, authentication requirements, rate limits, error conditions, or what the tool actually returns. It provides zero behavioral context beyond the name itself.

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

Conciseness2/5

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

While technically concise (two words), this is under-specification rather than effective conciseness. The description fails to convey any meaningful information about the tool's purpose or usage, making it inefficient rather than appropriately brief. Every sentence should earn its place, but this description has no sentences to evaluate.

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

Completeness1/5

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

For a tool with 3 parameters, no annotations, and 30+ sibling tools, the description is completely inadequate. While an output schema exists, the description provides no context about what kind of category information is retrieved, how it relates to other FRED tools, or any operational considerations. This leaves the agent with insufficient information to use the tool effectively.

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

Parameters1/5

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

With 3 parameters and 0% schema description coverage, the description must compensate by explaining parameter meanings, but 'fred/category' provides no parameter information whatsoever. The agent cannot understand what category_id represents, what realtime_start/end mean, their formats, or how they affect the operation.

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

Purpose1/5

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

The description 'fred/category' is a tautology that merely restates the tool name 'get_category' in a different format, providing no meaningful information about what the tool does. It doesn't specify any verb or resource, nor does it distinguish this tool from its many siblings in the FRED API family.

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

Usage Guidelines1/5

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

The description provides absolutely no guidance about when to use this tool versus alternatives. With 30+ sibling tools available (including get_category_children, get_category_related, get_category_series, etc.), the agent has no information about when this specific category retrieval tool is appropriate versus other category-related tools.

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