Skip to content

Treasury Fiscal Data

Three read-only tools over market-data-hub's Treasury Fiscal Data reader functions: daily cash balances, daily debt totals, and auction results. No live HTTP call happens here at all -- the hub owns downloading, ingestion, and storage; this connector only translates the hub's Python-facing reader API into a shape an LLM tool can call.

from lazybridge import Agent, LLMEngine
from lazytools.connectors.treasury_fiscal import TreasuryFiscalTools

agent = Agent(name="treasury", engine=LLMEngine("deepseek-v4-flash"),
              tools=[TreasuryFiscalTools()])

No extra to install and no key to configure -- this is a thin translation layer, not a network client. It needs the hub's market_data_hub.reader module importable at call time (see Depends on the hub landing first below).

What it is, and what it is not

Read-only throughout, by construction, not by policy. The hub's ingestion job writes this data; nothing here ever does. There is no write tool to gate, unlike the messaging connectors -- allow_write is simply accepted and ignored wherever this connector is mounted through the MCP server, the same convention econ_calendar documents for the same reason: the calendar (and this data) is written by the ingestion job, and a tool that let an agent edit a published figure would defeat the point of recording who published it.

Why these methods restate their arguments instead of wrapping the hub's readers directly. Same reasoning as econ_calendar: a model cannot supply an open database connection, and Python types such as Optional[str] do not express absence reliably in a JSON tool schema. Each method binds the configured database path, accepts plain strings, and translates "" to "no filter" before forwarding to exactly one hub reader function. Every method does its from market_data_hub.reader import read_treasury_... import inside the method body rather than at module load time, so importing this connector never requires the hub reader functions to exist yet -- only calling a tool does.

The tools

Tool What it does Required args
treasury_cash_balance Daily Treasury cash balances in a date range start, end
treasury_debt Daily Treasury debt totals in a date range -- debt held by the public, intragovernmental holdings, and total public debt outstanding start, end
treasury_auctions Treasury auction results in a date range, optionally filtered to one security type (Bill, Note, Bond, TIPS, FRN) start, end

start/end are required, inclusive, YYYY-MM-DD dates on every tool -- each raises ValueError if either is missing, before any hub import or call happens. account_type (on treasury_cash_balance) and security_type (on treasury_auctions) default to "", which is translated to None -- "no filter" -- before it reaches the hub; the hub never sees an empty string.

account_type groups several figures per day, not one

treasury_cash_balance returns rows, not columns: account_type is a label on each row, and a single record_date carries several rows, one per account/figure the source publishes for that day -- opening balance, closing balance, deposits, withdrawals, and so on all live under different account_type labels on the same date, not different columns of one row.

A caller who wants "the TGA balance on day X" must filter to the exact account-type label (e.g. 'Treasury General Account (TGA) Opening Balance') and the date -- filtering by date alone returns every account_type published that day mixed together, which is not the same answer and does not fail loudly. There is no vocabulary-lookup tool here (unlike calendar_vocabulary on the econ calendar) to enumerate valid labels; the exact strings come from the hub's own source data.

Through the MCP server

Mounted (once registered) the same way as econ_calendar and earnings_calendar: always read-only, so --allow-unsafe changes nothing about it.

Depends on the market-data-hub treasury_fiscal source module

This connector calls read_treasury_cash_balance, read_treasury_debt, and read_treasury_auctions from market_data_hub.reader -- merged into market-data-hub's main (PR #67). An installation pinned to an older market-data-hub ref won't have these functions yet, and calling any tool here raises an ImportError from that local import; bump the pin to pick them up. This connector's own tests intercept that import boundary directly (by injecting a fake market_data_hub.reader module) rather than depending on a live hub install, so they exercise this connector's translation logic in isolation and do not by themselves prove a given installation's hub pin is new enough.