Ava Advisor

Macro Series + Analysis (FRED)

fred_series

Read-only

"What is / is it high vs history / how has it moved" — ONE FRED series, feature-extracted. Pass a macro CONCEPT (the server resolves it to the canonical series_id + the right transform) or an exact id. Returns series (transformed points) + an analysis block: latest (+date — always say as-of-when), trend, change (vs prior/YoY/window), peak/trough, and 🔑 percentile+z_score vs the window's own history (the money-shot for "high or low?" — e.g. unemployment 8th pct = historically very low), volatility, a one-line read. 🔵 transform matters and is auto-picked from the resolved series ("inflation" = pc1 YoY % of a price index, a rate = lin) — override only deliberately. QUOTE the read; narrate the percentile. Compare two = call once per concept and diff. A concept that isn't a FRED series (ISM/PMI, a commodity SPOT price → pulse(kind='commodity')) → honest no_match, not a fabrication. US-govt series are public domain (_license_note).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "q": "<q>"
    },
    "name": "fred_series"
  }
}

Input Schema

Name	Required	Description
`q`	Yes	A macro CONCEPT (any language — 'inflation', 'core PCE', 'unemployment rate', '10y yield', 'อัตราว่างงาน') OR an exact FRED series_id you already hold (CPIAUCSL). The SERVER resolves a concept → the canonical series + the RIGHT transform (no separate lookup). 🌐 a macro concept is safest in ENGLISH (a native concept may drift). 🔴 Pass the user's FULL request in `context` so the server picks the right VARIANT (headline vs CORE CPI, SA vs NSA, PCE vs CPI). ⛔ ONE concept per call — compare two = call twice + diff. For a NON-US concept put the country in `country`, NOT in this field ('Japanese inflation' → series_id='inflation', country='JP').
`to`	No	End — ISO date. Omit → latest.
`from_`	No	Start — ISO date or relative window `10y`/`5y`/`qtd` (dynamic, anchored to today).
`context`	No	OPTIONAL but RECOMMENDED — the user's FULL request VERBATIM (any language). Used to pick the right series VARIANT (headline vs core, SA vs NSA). e.g. 'is US core inflation still sticky?'
`country`	No	OPTIONAL ISO-2 to bias a CONCEPT to a country's series (JP, DE) — the nationality from the question goes HERE, not in `series_id`. FRED intl coverage is uneven; omit for US (default).
`transform`	No	FRED units transform — `lin` (level: a rate/ratio) · `pc1` (YoY %: inflation/price index) · `pca` (annualized %: real GDP) · `pch` (period %) · `chg`/`ch1` (abs Δ). Omit → the resolved series' suggested transform.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true, so the description carries the rest and does so: it discloses the returned blocks (series, latest, trend, change, peak/trough, percentile, z_score, volatility, read), the auto-selection of transform, the honest no_match behavior instead of fabrication, and the public-domain license note. That is behavioral context well beyond the annotations.

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 leading question-shapes are front-loaded well, but the body is a run-on of emoji-marked clauses, parentheticals and mid-sentence directives (🔑, 🔵, ⛔) that cost readability. Nearly every clause carries information, yet the formatting noise and sentence length keep it from being a clean, scannable definition.

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?

With no output schema, the description must explain the return payload, and it does so field by field including the percentile/z_score framing that answers 'high or low?'. Combined with the transform auto-pick, no_match honesty and license note, an agent has everything needed to call and narrate results correctly.

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 100%, so the baseline is 3; the description earns an extra point by adding cross-parameter routing rules the schema does not state as a whole — put the nationality in `country` not `q`, pass the user's verbatim request in `context` so the variant is chosen, and override `transform` only deliberately. It does not add anything about `from_`/`to` beyond the schema.

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 opens with a concrete verb/resource statement: fetch ONE FRED series and return feature-extracted analysis. It distinguishes itself from siblings by routing commodity spot prices to pulse(kind='commodity') and by explicitly forbidding multi-concept calls. An agent can tell this apart from price_series/wb_series without opening a schema.

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?

It enumerates the exact question shapes the tool serves ('what is <indicator>', 'is it high vs history', 'how has it moved') and states the alternative path for non-FRED concepts (ISM/PMI, spot prices → pulse). The comparison workflow is spelled out: 'Compare two = call once per concept and diff', which is explicit when-to-use guidance rather than an inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Ava Advisor tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.