Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fiscus find the TGA Wednesday level series"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
US economic data MCP server — curated catalog of macro, Treasury, and financial sources with the caveats attached
fiscus leads with the plumbing that generic macro-data wrappers usually omit: Treasury FiscalData, MSPD, DTS, SOMA, Z.1 semantics, TIC, and OFR money-fund monitors — alongside BEA national accounts, BLS labor series, CBO baselines, NY Fed reference rates, TreasuryDirect auctions, and selected FRED series. Curated fetches are catalog-selected and labeled with reviewed units and known footguns; explicitly uncurated routes remain labeled as such. Fetches are cached with immutable provenance. Sources that reject automated clients (bls.gov tables, cbo.gov workbooks) are cataloged as browser-download-only so agents get an explicit diagnosis instead of a mysterious 403.
uv tool install fiscusFor a one-off invocation without installation:
uvx fiscus find-series "Treasury General Account"Related MCP server: econstats-mcp
FRED public CSV and Treasury FiscalData work without credentials.
uvx fiscus find-series "TGA Wednesday level"
uvx fiscus get-series fred.wdtgal --start 2024-01-01
uvx fiscus fiscaldata-query fiscaldata.dts_operating_cash_balance \
--param 'filter=record_date:gte:2024-01-01' \
--param 'sort=record_date' \
--max-pages 2Set FRED_API_KEY to use the official FRED observations API instead of the public graph CSV path and to request historical ALFRED information snapshots, BEA_API_KEY for BEA national-accounts tables (required), and BLS_API_KEY to raise BLS query limits (optional). Keys are read from environment variables only; the MCP server can be launched with uv run --env-file pointing at a private env file.
For a FRED series, --vintage-as-of YYYY-MM-DD selects the information available
to ALFRED on one closed past date. --start and --end remain inclusive
observation-date bounds; they are never treated as vintage dates. Today and future
information dates are rejected because today's information set remains mutable.
The server has a dedicated executable so an interactive fiscus command never appears to hang on stdio:
uvx --from fiscus fiscus-mcpGeneric client configuration:
{
"mcpServers": {
"fiscus": {
"command": "uvx",
"args": ["--from", "fiscus", "fiscus-mcp"]
}
}
}From a checkout, use uv run fiscus-mcp instead.
Cache-backed tool results contain an artifact descriptor, not a server-local pathname. MCP clients read the exact payload through the read-only resource template
fiscus-cache://artifact/{cache_key}. The resource returns byte-exact content, including binary workbooks and archives; use the descriptor's mime_type and filename when saving or interpreting it. This keeps the nine read-only tools focused on economic-data operations rather than adding a server-side export tool whose path would still be inaccessible to a remote MCP client.
fiscus find-series QUERY
fiscus get-series DATASET_ID [--start DATE] [--end DATE] [--vintage-as-of DATE]
fiscus bea-nipa-table TABLE_ID {A,Q,M} START_YEAR END_YEAR
fiscus fiscaldata-query DATASET_ID [--param KEY=VALUE] [--max-pages N]
fiscus get-file DATASET_ID
fiscus z1-series CODE KIND [--start DATE] [--end DATE]
fiscus soma-holdings [--asof DATE] [--cusip CUSIP]
fiscus source-caveats DATASET_ID
fiscus provenance CACHE_KEY
fiscus cache export CACHE_KEY --out PATH
fiscus cache migrate-v1 [--from PATH]
fiscus catalog lint
fiscus mcpCall find-series before a fetch command. Dataset identifiers are curated catalog IDs — but coverage is not limited to the catalog:
Uncataloged passthrough: any FRED or BLS series is fetchable as fred.<SERIES_ID> / bls.<SERIES_ID>. Keyed FRED requests derive units, seasonal adjustment, annualization, and a conservative unit_class from official series metadata. Detected annual-rate series receive an explicit interpretation caveat; the keyless FRED graph route and current BLS data route report annualization as unknown and warn the caller to verify before treating observations as period flows. Every passthrough remains marked "uncataloged — no curated caveat review." The catalog is for caveats, not coverage.
Upstream search fallback: when find-series has no complete catalog match, it appends candidates from FRED's own search (requires FRED_API_KEY), clearly marked uncurated, so an empty result is a lead rather than a dead end.
Curated release files: Census vintage files and archived BLS releases carry a logical release id and representation. Their immutable source identity appends the SHA-256 of exact downloaded bytes, so a correction at the same URL creates a new revision while ETag and Last-Modified remain transport metadata.
Z.1 package discovery: find-series QUERY --family z1 searches the current official package data dictionary without a key and returns the exact z1-series CODE KIND call for uncataloged matches.
BEA NIPA table access: find-series QUERY --family bea falls back to BEA's source-reported NIPA table inventory. The inventory is cached in Fiscus's platform SQLite cache and refreshed once before an apparent table/frequency miss is rejected. bea-nipa-table fixes datasetname=NIPA, requires explicit inclusive years, and returns per-line observed coverage. Uncurated results and responses omit reviewed history, units, and verified_on; an exact cataloged table/frequency pair adds a separate curation overlay. get-series bea.nipa_t10106 remains a deprecated one-release alias.
Local artifacts: private overlay entries can register files already on disk via the local_file executor (endpoint.local_path) — served in place with a content-hash provenance block, never copied. See catalog/CONTRIBUTING.md.
z1-series additionally accepts any mnemonic from the official Z.1 CSV package (including FRED-style BOGZ1 aliases) and enforces the mnemonic's official series-type prefix, including transactions, levels, changes, revaluations, other volume changes, seasonal factors, growth rates, and indexes. One package download per release serves every series, and uncataloged mnemonics are labeled from the package's own data dictionary. soma-holdings resolves the latest weekly snapshot date before consulting the cache, so "latest" never freezes to a stale snapshot. provenance re-emits the immutable manifest and artifact descriptor for a full cache key or unique prefix.
For z1-series, KIND must be the mnemonic's matching official prefix: FA, FC, FG, FI, FL, FR, FS, FU, FV, LA, LM, or PC. The deliberate redundancy prevents one economic concept from being relabeled as another.
Cache-backed fetches return a small head/tail preview, row count, date coverage, units, binding caveats, a provenance block, and an opaque artifact descriptor:
{
"artifact": {
"cache_key": "<64 lowercase hex characters>",
"filename": "data.csv",
"mime_type": "text/csv",
"sha256": "<payload digest>",
"byte_count": 1234
}
}full_data_path and manifest_path are deliberately absent from cache-backed responses. The SQLite row is the cache artifact; fiscus does not create a per-request file forest or a temporary materialization tree. The descriptor is duplicated only where useful: its identity and integrity fields also remain in the provenance block.
Python callers can obtain full content without relying on a path:
from pathlib import Path
from fiscus import FiscusService
with FiscusService() as fiscus:
result = fiscus.get_series("fred.wdtgal", start="2024-01-01")
key = result["artifact"]["cache_key"]
payload = fiscus.read_bytes(key) # exact bytes
rows = list(fiscus.iter_csv_rows(key)) # canonical CSV only
receipt = fiscus.export_artifact(key, Path("wdtgal.csv"))read_bytes, iter_csv_rows, provenance, and cache export accept either the full key or a unique hexadecimal prefix of at least 12 characters. iter_csv_rows rejects non-CSV artifacts instead of guessing how to parse a workbook or archive.
Expected failures have stable Python/CLI codes. In particular, HTTP 404/410 is
source_removed, HTTP 403/451 is source_access_denied, and a statically declared
nonmachine route is browser_download_only. A transient access denial is not
silently promoted into a permanent catalog fact.
The cache defaults to the platform's device-local cache directory and can be relocated with FISCUS_DATA_DIR. Its quiescent cache/v2 surface is one fiscus.sqlite3 file; payloads, manifests, and latest pointers are rows in that database. SQLite uses rollback-journal DELETE mode, so a journal may exist during a write but no persistent WAL/SHM sidecars or artifact directories remain at rest.
The cache is durable across fiscus processes but is still a cache: operating-system cleanup, an explicit user deletion, or a replaced device can remove it. cache export / export_artifact creates a caller-owned file at the requested destination when archival or handoff durability matters. Conversely, a local_file catalog entry already points to caller-owned content, so its response keeps the real in-place full_data_path and manifest_path: null and never enters SQLite.
--refresh bypasses the latest pointer and re-reads the source. Current FRED responses use HTTP validators or retrieval UTC as immutable identity; their default real-time dates remain metadata. Historical FRED requests use alfred-as-of:DATE, and the date also enters canonical request parameters. Bytes already stored under one dataset/canonical-params/vintage identity are never mutated.
A legacy filesystem cache is migrated only by the finite, explicit command:
fiscus cache migrate-v1
# or
fiscus cache migrate-v1 --from /path/to/cache/v1Migration reads v1 without deleting or rewriting it, inserts valid artifacts directly into SQLite, preserves each usable authoritative latest.json pointer, and reports path-specific diagnostics for corrupt or incomplete legacy artifacts. It never materializes cache-owned files and does not enable dual-write.
Set FISCUS_EXTRA_CATALOG to one or more YAML files or directories separated by the operating-system path separator. Overlay entries merge by id; mapping fields merge recursively and lists replace. New entries must be complete after merging.
FISCUS_EXTRA_CATALOG=./local-catalog uv run fiscus catalog lintSee catalog/SCHEMA.md and catalog/schema.json.
uv sync --frozen --group dev
uv run fiscus catalog lint
uv run pytest
uv run ruff check .The unit suite is offline-first and uses tiny recorded response fixtures. A separate weekly workflow makes one cheap live request for each implemented family and opens or updates a single issue if a source fails.
This is an alpha, solo-maintained public-data utility. Source endpoints can drift; catalog entries carry verified_on dates, and the project makes no support or uptime promise.
Fetch a complete BEA NIPA table for an explicit inclusive year range.
table_id is BEA's canonical TableName (for example T10106). frequency must be
A, Q, or M and must be advertised for that table in BEA's source inventory.
The route is NIPA-only, sends an explicit Year list rather than Year=X, and
returns source-observed metric labels plus per-line coverage. Uncurated tables
omit reviewed units, history, and verified_on claims; exact curated pairs add
a separate catalog overlay. BEA_API_KEY is required for a source retrieval.
| Name | Required | Description | Default |
|---|---|---|---|
| refresh | No | ||
| end_year | Yes | ||
| table_id | Yes | ||
| frequency | Yes | ||
| start_year | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Search the curated catalog. Call this before guessing any series or dataset id.
Curated results include units, history start, access needs, supported fetch tool,
and caveat count so the next call can select the right concept. When the catalog has
no match, uncurated candidates from the source's own search are returned under
uncurated_upstream. BEA inventory candidates intentionally omit reviewed history,
units, and verified_on. For keyless discovery across the Z.1 package data dictionary,
pass family="z1".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| family | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Query a curated Treasury FiscalData dataset selected from find_series.
Use official FiscalData query keys such as fields, filter, sort, and page[size].
Narrow large requests with a filter instead of raising max_pages indiscriminately.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | ||
| refresh | No | ||
| max_pages | No | ||
| dataset_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Download a curated file artifact selected from find_series.
Serves sources published as direct files (workbooks, delimited text, archives).
Parseable csv/tsv files return a row preview; binary formats return provenance and
an artifact descriptor. Read exact bytes at fiscus-cache://artifact/<cache_key>.
| Name | Required | Description | Default |
|---|---|---|---|
| refresh | No | ||
| dataset_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Fetch a cataloged series (FRED, BEA, BLS, OFR, NY Fed, TreasuryDirect families).
Prefer ids from find_series. Uncataloged FRED and BLS series are also served as
fred.<SERIES_ID> / bls.<SERIES_ID>. Their source unit metadata is labeled when
available; otherwise annualization is explicitly unknown. These passthroughs carry
interpretation warnings instead of curated review. Returns a compact preview,
binding caveats, provenance, and an artifact descriptor. Read full bytes through
fiscus-cache://artifact/<cache_key>. Set refresh only for a new source retrieval.
For a FRED/ALFRED snapshot, set vintage_as_of to a closed past ISO date; start and
end remain observation-date bounds, and FRED_API_KEY is required. Vintage failures
distinguish an unset key, a rejected credential, no ALFRED history, a request before
the first ALFRED vintage, and a source identifier that does not exist. A failed BOGZ1
identifier is not auto-corrected because its two-letter prefix encodes the concept.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| refresh | No | ||
| dataset_id | Yes | ||
| vintage_as_of | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Re-emit the provenance manifest for any prior fetch by its cache key.
The cache key appears in every fetch response's artifact and provenance blocks; a unique hex prefix of at least 12 characters is accepted. Resolves only immutable artifacts, never a mutable "latest" pointer.
| Name | Required | Description | Default |
|---|---|---|---|
| cache_key | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Fetch CUSIP-level SOMA Treasury holdings for a weekly as-of snapshot date.
Omit asof for the latest published snapshot; the resolved date becomes part of the immutable cache identity. Snapshots begin July 2003 and are weekly, not daily.
| Name | Required | Description | Default |
|---|---|---|---|
| asof | No | ||
| cusip | No | ||
| refresh | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Return every catalog caveat and whether it binds to the supplied context.
Supply a date range to evaluate history seams and unit_classes when checking a planned
combination of differently scaled, adjusted, or annualized series.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| params | No | ||
| dataset_id | Yes | ||
| unit_classes | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Fetch a Z.1 Financial Accounts series with enforced official prefix semantics.
kind must match the series prefix. This includes FR revaluations and the other official FA/FC/FG/FI/FL/FS/FU/FV/LA/LM/PC types. The call refuses to present one kind as another. Accepts bare mnemonics, .Q/.A suffixes, and FRED-style BOGZ1 aliases. If an official mnemonic is refused or absent, follow the server issue-reporting instruction before bypassing Fiscus.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| code | Yes | ||
| kind | Yes | ||
| start | No | ||
| refresh | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.4.0bea_nipa_tablefind_seriesfiscaldata_queryget_fileget_seriesprovenancesoma_holdingssource_caveatsz1_seriesEach 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Fetch US Bureau of Labor Statistics data — CPI, unemployment, wages, JOLTS, and more via MCP.
Query US Treasury national debt, interest rates, exchange rates, and fiscal datasets via MCP.
MCP access to the U.S. federal procurement graph: contracts, opportunities, entities, and more.
Econdata MCP — wraps BLS (Bureau of Labor Statistics) public API v2
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