fred-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.7
Disambiguation5/5
Each tool targets a distinct resource or action: series search, metadata, data, categories, releases, sources, and related tags. Even similar pairs like get_sources and get_source are clearly differentiated by list vs single-item semantics.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern. Search operations use search_ and data retrieval operations use get_, which is a predictable and semantically meaningful convention.
Tool Count5/5
11 tools is well-scoped for an economic data server, covering search, metadata, observations, categories, releases, sources, and tags without excessive fragmentation or redundancy.
Completeness4/5
The tool surface covers the core FRED workflows: discovering series, browsing categories/releases/sources, fetching metadata and observations. Minor gaps exist around tag browsing and direct series-to-tag relationships, but these do not break typical usage.
Average 3.4/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure burden. It only adds 'if supported,' which hints that the tool may fail in some contexts but does not explain how. It does not state read-only behavior, return format, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose, followed by a single argument line. There is little waste, though 'if supported' feels like a dangling qualifier that could have been expanded or removed.
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?
The tool is simple with one well-documented parameter and no output schema. Still, the description does not clarify what kind of 'details' will be returned or what 'if supported' means in practice. It is minimally viable for invocation but leaves interpretation gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, but the description's Args block explains that category_id is the ID of the category and gives a concrete example (125). For the only parameter, this compensates for the missing schema description and adds practical value.
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 states a specific verb ('Get') and resource ('details for a specific category') and clearly names the input parameter. It is implicitly distinct from siblings like get_category_children and get_category_series, though the hedge 'if supported' and the vague 'details' prevent a 5.
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?
No when-to-use or when-not-to-use guidance is provided. The description does not reference any alternative tool, so an agent cannot tell when to choose get_category_details over get_category_series or get_category_children. The only caveat, 'if supported,' is not actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Get metadata' suggests a read operation, but there is no disclosure of return structure, error behavior, rate limits, or whether any side effects occur. The description is too thin to give an agent confidence about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the key purpose is front-loaded. The 'Args' formatting is slightly unnecessary given the schema already defined the parameter, but it does not waste much space. Overall it is efficient.
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?
For a single-parameter metadata retrieval tool, this is minimally adequate. However, with no output schema and no annotations, the description should at least mention what metadata will be returned or what happens for an invalid series_id. It is complete enough for a simple call but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does by explaining series_id as 'The ID of the series' and giving concrete examples ('GDP', 'UNRATE'), which adds semantics beyond the bare schema field name 'Series Id'. It does not explain where to find an ID, but the examples are useful.
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?
States a clear verb and resource: 'Get metadata for a specific data series.' The word 'metadata' helps distinguish it from sibling get_series_data, though it does not explicitly name any sibling. The focus on 'specific' series implies lookup by ID, which is close to full 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?
No explicit guidance on when to use this tool versus alternatives like search_series or get_series_data. The description implies it is for known series IDs, but it does not state prerequisites, exclusions, or when a sibling would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read-only intent through 'Get,' but it says nothing about response shape, error behavior, permissions, rate limits, or side effects. This is minimal behavioral transparency.
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 one short sentence that is immediately understandable, front-loaded, and free of filler. Every word earns its place, even though the overall content is thin.
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?
For a simple one-parameter retrieval tool, the description and schema are enough to construct a basic call. But with no output schema and no annotations, the agent gets little context about what 'details' it will receive, what a 'source' means in this API, or how get_source relates to sibling tools. The description is minimally adequate but not complete.
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?
The schema exposes only source_id (integer, required) with zero description coverage. The description's phrase 'a specific source' only weakly connects source_id to the resource; it does not explain how to obtain a valid source_id, what the identifier references, or any constraints. This does not meaningfully compensate for the missing schema descriptions.
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 states a clear verb and resource: 'Get details for a specific source.' The word 'specific' also signals that this is a singular-source lookup rather than a list operation like the sibling get_sources. It is not vague, but it does not specify what kinds of details are returned, so it stops short of a fuller specification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: if you need details for one particular source, use this tool. However, there is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives such as get_sources for listing all sources. The context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself, but it only says 'Get' and lists parameters. It does not mention how related tags are computed, ordering, pagination behavior beyond limit/offset, error cases, or result shape. This is a minimal, non-transparent description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, and the parameter list is direct. The only real waste is 'Offset: Offset,' which adds no signal beyond the parameter name, but overall the text is efficient.
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 no output schema and no annotations, an agent cannot know the response shape, the precise meaning of 'related tags,' or any ordering/relevance semantics. However, invocation requirements are fully covered: required tag_names with format and optional pagination. This is a minimally viable description with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args block adds meaningful guidance: 'Semicolon separated list of tag names' specifies the exact input format, and limit/offset are explained. The offset line is terse and near-tautological, which keeps this from a 5.
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 states a clear verb+resource: 'Get related tags for a set of tags.' This distinguishes it from the sibling search/get tools, which focus on series, categories, releases, and sources. It doesn't explain what 'related' means, but the core purpose is unambiguous.
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?
No when-to-use or when-not-to-use guidance is provided, and no alternative tools are mentioned. The intended use must be inferred entirely from the tool name and sibling list. There is no explicit context for choosing this over, say, search_series or get_source.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the schema by explaining that limit and offset apply to a 'preview' and that file_path saves the full list as JSON. However, with no annotations and no output schema, it does not disclose return structure, side effects of file writing, authentication, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, followed by a compact parameter list. No unnecessary words or repetition. It could be slightly richer, but it is appropriately sized for the tool's simplicity.
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 no annotations, no output schema, and a large sibling set, the description misses key context such as the shape of returned data, how to distinguish this tool from get_release_series, and when the file_path option should be used. The preview/full-list distinction is helpful, but the overall operational context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by explaining all three parameters: limit caps the preview, offset shifts the preview, and file_path optionally saves the full list. This adds meaning that the raw schema alone does not provide, though details like file overwrite behavior are absent.
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 states a specific action and resource: 'Get all releases of economic data.' It is clear enough to identify the tool's primary function. However, it does not explicitly differentiate itself from the similar sibling get_release_series, so an agent may need to infer the distinction.
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 gives no guidance about when to use this tool versus alternatives such as get_release_series or get_series_info. It only explains the parameters, with no mention of exclusions, prerequisites, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and return behavior; it only notes the optional file_path save behavior. It does not explain whether the sources are still returned when file_path is provided, nor any limits, pagination, or output structure.
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 concise with a clear lead sentence and an Args note. Every part earns its place and there is no repetition of the schema.
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?
For a simple list-all tool with one optional parameter, the description covers the basics, but it lacks return-value details, usage context, and routing among the ten sibling tools. It is adequate but leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only says file_path is string|null with a default; the description adds that it is an absolute path used to save the sources list as JSON. This meaningfully clarifies the only parameter, though it does not describe behavior when omitted.
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 uses a specific verb, 'Get', and identifies the resource as 'all sources of economic data', making the tool's purpose clear. It does not explicitly distinguish from sibling get_source or search methods, but 'all sources' signals a bulk retrieval operation.
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?
No guidance is given on when to call this tool versus siblings like get_source or search_series, and no exclusions or prerequisites are stated. The agent must infer usage from the name and general context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals useful behavioral details beyond the schema: limit and offset control the preview, and file_path optionally saves the full list as JSON. However, there are no annotations and no mention of return format, pagination semantics, or errors, so the agent is left to infer some behavior.
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 concise and well-structured: a one-sentence purpose followed by a compact args list. Every line serves a purpose, and the preview-versus-full-list distinction is communicated efficiently.
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?
All four parameters are described and the preview/full-list behavior is introduced, but there is no output schema to clarify return values and no guidance on how preview results differ structurally from the saved full list. The tool is usable, but an agent would still need to guess at the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does. It explains release_id, clarifies that limit and offset apply to preview results, and explains file_path as an optional path to save the full list as JSON. This adds real meaning beyond the raw schema.
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 gets series within a specific release, using a specific verb and resource. It does not explicitly contrast with sibling tools like get_series_info or get_category_series, but the scope is unambiguous enough for basic 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?
No guidance is given about when to use this tool versus alternatives such as get_series_data or get_category_series. The description implies its use ('Get series in a specific release') but provides no exclusions, prerequisites, or routing hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the preview-versus-full-results behavior via the limit and file_path parameters, but it does not describe the response format, pagination behavior, or any access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose sentence is front-loaded and the Args block is compact. The parameter documentation is essential given the schema's lack of descriptions, so the length is justified.
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?
Basic invocation is complete: required query, default limit and offset, optional file_path, and the preview/full-result distinction are all clear. However, the response structure is not described, and there is no guidance on how this relates to sibling tools or what an agent should do after receiving results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by explaining all four parameters: query text, limit as preview maximum, offset as skip count, and file_path as an optional full-result JSON save location. This adds substantial meaning beyond the bare schema types and defaults.
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 states a clear verb and resource: "Search for economic data series by text query." It distinguishes the tool from data-retrieval siblings like get_series_data, though it does not explicitly differentiate itself from search_related_tags.
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?
No guidance is given about when to use this tool versus the other search-related or retrieval tools. It does not mention prerequisites, exclusions, or when a sibling would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Get' signals a read operation and 'child categories' hints at a list result, but it does not disclose whether children are immediate descendants only, how results are ordered, or what error behavior occurs for a nonexistent category.
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 two compact sentences that lead with the core operation and then specify the argument. The Args block is minimal and earns its place because it adds parent semantics absent from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema, the definition covers the essential call contract: what it returns (child categories) and what input to provide (parent category ID). It is adequate, though it leaves minor ambiguity about hierarchy depth and result shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, the single parameter is fully described in the Args section as 'the parent category ID'. This adds the crucial 'parent' semantics that the schema's 'Category Id' title lacks, making the required input unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('child categories') and makes the input explicit ('for a specific category'). This clearly distinguishes it from sibling tools like get_category_details or get_category_series, which target different resources.
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 choose this tool over siblings; it only restates the operation. There is no mention of usage context, prerequisites, or exclusions, so an agent must infer applicability from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden and does add useful context: limit/offset are described as preview controls, and file_path is described as saving the full list as JSON. It stops short of explaining ordering, error cases, or whether the full list is ever returned directly, but the side-effecting file behavior is clearly disclosed.
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 compact and front-loaded with the core purpose, followed by a tidy Args block. Every sentence earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple 4-parameter list call, the description covers purpose, parameter roles, preview behavior, and optional file output. It could add more detail about the return shape or pagination semantics, but it is adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives meaningful semantics for limit ('Max results in preview'), offset ('Offset for preview'), and file_path ('save the full list as JSON'). Only category_id is described tautologically, but its role is clear from the tool purpose.
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 states a specific action ('Get') and a clear resource ('series in a specific category'). This is enough to distinguish it from sibling tools like get_category_details or get_series_info, but it does not explicitly call out those distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it — when you need series belonging to a specific category — but it provides no explicit alternatives or exclusions. It does not mention, for example, that search_series might be better for cross-category discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior disclosure. It adds valuable context: limit/offset apply only to the markdown preview, and providing file_path saves the full dataset while minimizing the response. This goes well beyond the schema, even if return format and error behavior are not fully specified.
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 front-loaded with a one-sentence purpose followed by a compact Args list. Every line adds necessary information, and there is no redundant or promotional language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description covers the main invocation concerns: series identification, pagination-like parameters, preview behavior, and optional file output. It does not spell out the exact return shape or error handling, but it is sufficient for an agent to select and call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is essential, and it delivers. Every parameter is explained with defaults and meaningful nuances: limit/offset affect only the preview, and file_path triggers full-dataset saving with a minimized response. This fully compensates for the sparse schema.
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 verb and resource: 'Get data points for a specific series.' It conveys the core purpose and implicitly distinguishes it from sibling tools like get_series_info or search_series, though it does not explicitly contrast them.
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?
There is no guidance on when to use this tool versus sibling tools, nor any exclusions or alternatives. The phrase 'for a specific series' hints at scope, but an agent is left to infer when get_series_data is preferable to get_series_info or other series-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![fred-mcp MCP server](https://glama.ai/mcp/servers/fritzprix/fred-mcp/badges/card.svg)](https://glama.ai/mcp/servers/fritzprix/fred-mcp)

Score Badge

Copy to your README.md:

[![fred-mcp MCP server](https://glama.ai/mcp/servers/fritzprix/fred-mcp/badges/score.svg)](https://glama.ai/mcp/servers/fritzprix/fred-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/fritzprix/fred-mcp'

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