fiscus

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation5/5
Each tool targets a distinct data source or operation: provenance for cache keys, source_caveats for context binding, find_series for search, get_series for general fetch, and specific tools for BEA NIPA, FiscalData, file downloads, Z.1 series, and SOMA holdings. No two tools have overlapping purposes.
Naming Consistency3/5
Tool names use lowercase with underscores, but conventions vary: some are verb_noun (find_series, get_series, get_file), some are noun_noun (bea_nipa_table, fiscaldata_query, z1_series, soma_holdings), and 'provenance' is a single noun. This mix of verb-first and noun-first patterns reduces predictability.
Tool Count5/5
With 9 tools covering search, general fetch, specific data sources, file download, and metadata retrieval, the count is well-scoped for an economic data server. No tools feel redundant or missing.
Completeness4/5
The tool set covers core operations: search, fetch for multiple families (FRED, BEA, BLS, OFR, NY Fed, TreasuryDirect), specific endpoints for NIPA, FiscalData, Z.1, and SOMA, plus provenance and caveats. Minor gaps include no explicit tool for listing all available families, but find_series and get_series cover most needs.
Average 3.9/5 across 9 of 9 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
Without annotations, the description fails to disclose behavioral traits like idempotency, rate limits, or data freshness. It hints at pagination via page[size] and max_pages but lacks a safety profile.
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 at two sentences, front-loading the purpose. It is concise but could be structured better with explicit parameter explanations.
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 4 parameters, no annotations, and output schema present, the description misses critical details: parameter usage, error cases, prerequisites, and behavioral context beyond pagination.
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 coverage, the description must compensate but only mentions query keys not in the schema (fields, filter, sort, page[size]), ignoring actual parameters like params, refresh, max_pages. No mapping or explanation is provided.
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 queries a dataset from find_series, using a specific verb and resource. However, it could be more precise about the nature of 'query' and the output.
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 advises using official query keys and suggests using filter over increasing max_pages, but does not compare with sibling tools or provide explicit when-to-use guidance.
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 discloses that BEA_API_KEY is required, the route sends explicit year lists, and it returns metric labels with per-line coverage. It also distinguishes uncurated vs curated tables, providing useful behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the main purpose, but later sentences contain jargon and could be more concise. It is adequate but not optimally structured.
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?
Given an output schema exists, the description covers returned data (metrics, coverage, curation details) and authentication. Missing details on error handling and the refresh parameter, but overall fairly complete for a fetch tool.
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?
Schema coverage is 0%. The description explains table_id as canonical TableName and frequency as A/Q/M with validation, and implies year range usage. However, it does not explain the refresh parameter, leaving gaps for 1 of 5 parameters.
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 fetches a complete BEA NIPA table for a year range, specifying the resource and action. However, it does not explicitly distinguish from sibling tools like get_series or find_series, which may also retrieve BEA data.
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 mentions the tool is NIPA-only and specifies frequency constraints, but does not provide when to use this tool versus alternatives, nor does it include when-not-to-use or reference sibling tools.
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?
No annotations are provided, so the description carries the full burden. It mentions 'immutable cache identity' and weekly frequency, which adds behavioral context. However, it does not explicitly state read-only nature or other safety considerations.
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?
Two tightly written sentences with no extraneous information. The first sentence states the primary action, and the second provides essential usage constraints.
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?
Despite having an output schema, the description lacks parameter details and does not cover input validation, error cases, or the implications of 'refresh'. For a tool with no annotations and low schema coverage, this is insufficient.
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, the description should explain all three parameters. It only references 'asof' indirectly and provides no detail on 'cusip' or 'refresh' semantics, leaving the agent to infer from names.
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 the specific verb 'Fetch' and clearly identifies the resource as 'CUSIP-level SOMA Treasury holdings' for a weekly as-of date. This distinctly differentiates it from sibling tools like 'provenance', 'source_caveats', or 'find_series'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on omitting the asof parameter for the latest snapshot and notes that snapshots are weekly starting July 2003. This helps with usage timing but does not explicitly state when not to use or offer alternatives.
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?
Discloses key behaviors: prefix enforcement, refusal to misrepresent kinds, accepted formats, and error handling instructions, which is useful given no annotations.
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?
Single paragraph, front-loaded with purpose, no wasted words; efficient and structured.
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?
Covers core behavior but omits optional parameter details and usage guidelines, leaving it incomplete for a 5-parameter tool with no schema parameter descriptions.
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?
Explains semantics for 'code' (accepted formats) and 'kind' (must match prefix), but does not address 'start', 'end', or 'refresh', leaving gaps despite 0% schema coverage.
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 clearly states it fetches a Z.1 Financial Accounts series with enforced prefix semantics, providing a specific verb+resource and distinguishing it from sibling series tools.
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 on when to use this tool versus siblings like find_series or get_series; lacks usage context or exclusions.
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, description carries full burden. It discloses behavior: returns row preview for parseable CSV/TSV, provenance and artifact descriptor for binary, and mentions reading exact bytes at a cache URI. Lacks details on errors, idempotency, or side effects, but covers key behavioral aspects.
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?
Description is compact (4 sentences), front-loaded with main action, and uses bullet-style listing. It is clear and efficient, though a slight rephrase could reduce redundancy.
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 presence of an output schema, the description need not detail return values, but it adequately covers return types for different cases. However, the lack of parameter explanations leaves the tool partially incomplete for invocation.
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?
Schema description coverage is 0%, but description does not explain parameters 'dataset_id' or 'refresh.' It only mentions selection from find_series, leaving parameter purpose unclear. This is a significant gap.
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?
Description explicitly states 'Download a curated file artifact selected from find_series,' clearly indicating action and resource. It distinguishes from siblings by specifying it serves direct file types like workbooks and delimited text, and references find_series as the selection step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides context on when to use (after find_series) and what file types are served, but does not explicitly state when not to use or mention alternatives. The guidance is adequate but lacks exclusions.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns caveats and binding status, but does not mention that it is read-only, idempotent, or any error conditions. This is adequate but not comprehensive.
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 concise sentences. It front-loads the core purpose and immediately provides usage context. No redundant information is present.
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?
Given no annotations, a 5-parameter tool with low schema description coverage, the description is fairly complete: it explains the tool's output and when to use it. The presence of an output schema mitigates the need to document return values. Minor omission: 'params' object not covered.
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?
Schema description coverage is 0%, so the description must compensate. It mentions 'date range' and 'unit_classes', hinting at start/end and unit_classes parameters, but does not explain 'dataset_id' or 'params'. Some parameters gain meaning, but significant gaps remain.
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 clearly states the tool returns every catalog caveat and whether it binds to the supplied context. It is specific and implicitly distinguishes from sibling tools like 'provenance' or 'find_series' which deal with different aspects of data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it should be used when evaluating history seams and unit_classes for planned combinations of differently scaled series. It does not provide explicit exclusions or alternative tools, but the context is sufficiently clear.
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?
No annotations are provided, so the description carries the full burden. It details what curated results include (units, history start, etc.) and explains uncurated and BEA special cases. It implies read-only behavior but does not explicitly state safety properties.
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, front-loads the purpose, and every sentence adds value. No redundancy or fluff.
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 description covers purpose, behavior, and family parameter well. However, it omits details on 'query' (format) and 'limit' (pagination), which are relevant for a search tool. Given the output schema exists, return values are not needed, but input semantics are incomplete.
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?
Schema coverage is 0%, so description must compensate. It adds meaningful guidance for the 'family' parameter ('pass family="z1"'), but does not describe 'query' (required) or 'limit' (default 8). This leaves semantic gaps for the agent.
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 clearly states 'Search the curated catalog' with a specific verb and resource. It distinguishes itself from siblings by directing to call this before guessing any series or dataset ID, setting it apart from retrieval tools like get_series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Call this before guessing any series or dataset id' and specifies when uncurated results appear. It also gives a specific usage example for Z.1 with family='z1'. No explicit when-not, but context is clear.
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 fully covers behavioral traits: it resolves only immutable artifacts, states that the cache key appears in every fetch response, and accepts a unique hex prefix of at least 12 characters. No contradictions.
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 three sentences, front-loaded with the main purpose, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema, the description covers input semantics, behavioral constraints, and usage context. No gaps remain.
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?
The single parameter 'cache_key' is explained in detail: its source (fetch response), format (hex prefix), and minimum length (12 characters). This adds significant meaning beyond the schema, which has no description.
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 clearly states the action ('Re-emit the provenance manifest') and the resource ('any prior fetch by its cache key'). It also distinguishes from siblings by noting it resolves only immutable artifacts, not mutable 'latest' pointers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use: when you have a cache key from a fetch response, and it explicitly says it resolves only immutable artifacts, not mutable pointers, providing clear usage guidance. However, it does not name specific sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the weight. It discloses that the tool returns a compact preview with caveats, provenance, and artifact descriptor; explains caching via fiscus-cache://artifact/cache_key; details vintage failure modes; and notes that BOGZ1 identifiers are not auto-corrected. This is highly transparent.
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 front-loaded with a clear purpose sentence. It is somewhat verbose (a single dense paragraph) but each sentence adds distinct value. A more structured format (e.g., bullets) could improve scannability, but the content is efficiently packed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (5 params, output schema exists), the description covers core workflow (use find_series IDs), edge cases (vintage failures, uncataloged series), and behavioral specifics (refresh, BOGZ1 handling). The output schema handles return values, so the description is complete for selection and 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 adds meaning to vintage_as_of (ISO date, FRED_API_KEY required), refresh (only for new source retrieval), and start/end (observation-date bounds). The dataset_id parameter is implied but not explicitly described; a brief clarification would push to 5.
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 first sentence clearly states the tool fetches a cataloged series from specific families (FRED, BEA, BLS, etc.), distinguishing it from siblings like find_series which is for finding IDs. The verb 'Fetch' and the list of data families give a precise purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to prefer IDs from find_series, explains when to use uncataloged series (fred.SERIES_ID / bls.SERIES_ID), and gives detailed guidance on the vintage parameter and refresh flag. It also alerts about BOGZ1 identifier behavior, providing clear when-to-use and when-not-to-use context.
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:

[![fiscus MCP server](https://glama.ai/mcp/servers/smkwray/fiscus/badges/card.svg)](https://glama.ai/mcp/servers/smkwray/fiscus)

Score Badge

Copy to your README.md:

[![fiscus MCP server](https://glama.ai/mcp/servers/smkwray/fiscus/badges/score.svg)](https://glama.ai/mcp/servers/smkwray/fiscus)

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/smkwray/fiscus'

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