Seiche is a read-only MCP research server for source-dated funding, FX, and cross-market evidence; it does not execute trades or provide executable prices.
Inspect detailed USD money-market funding metrics, country/India desks, diagnostics, sources, and methodology via money_market_context.
Get chartless cross-market summaries, FX, macro-capital, China evidence, coverage gaps, and citation URLs via world_markets_context.
Query dated official FX histories, same-date FX crosses, and accepted China annual series via market_workbench.
Read GIFT City / India–UAE funding, ECB and CBUAE FX references, and COMEX gold positioning via gift_city_context.
Run caller-supplied gold inventory financing scenarios via gold_inventory_carry; inputs are not persisted and no quote is verified.
Discover datasets and sibling research tools via research_network.
Check source freshness, provenance, and fault status via data_health.
Release scope says only eight public tools are available and that retired forecast/backtest/editorial/composite tools are unavailable; the schema also lists tools such as latest_article, funding_stress_now, historical_analogs, proof_backtest, trade_safety_risk_context, crypto_stress_record, institutional_flows, oil_funding_context, and fx_materials_passage, which the README marks unavailable or retired. Authenticated Agent Room tools are private and non-executable.
Provides access to Coinbase Exchange market data for the crypto/stablecoin basin within the dollar funding system.
Click on "Deploy 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., "@Seiche — Funding and FX Evidence What's the latest dollar funding stress evidence?"
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.
Eight public research tools are available: source_rights_status, money_market_context, market_workbench, world_markets_context, gift_city_context, gold_inventory_carry, research_network, data_health.
Start with source_rights_status. Retired forecasts, backtests, editorial,
composite and derived legacy tools are unavailable for every caller while their
source reuse rights and replacements remain unqualified. A bearer token or
payment does not unlock them. Do not reconstruct withheld observations from
metadata, cached history or prior responses. Direct publisher observations keep
their own dates; restricted inputs remain explicitly metadata-only.
Authenticated callers can additionally discover five private, non-executable
Agent Room tools. Earlier feature descriptions below are historical context
where they conflict with this release scope; they do not advertise availability.
Related MCP server: Stock MCP
Hosted Streamable HTTP MCP; no local server or API key for public read-only tools. Add the products you need to Claude Code:
claude mcp add --transport http seiche https://api.seiche.info/mcp
claude mcp add --transport http liquilens https://api.liquilens.in/mcp
claude mcp add --transport http undertow https://api.seiche.info/undertow/mcpTry this first: What is the current US funding stress regime, and which dated funding events are next? Cite source dates and missing evidence.
Try it in your browser · Cursor configuration · Codex commands · Free three-product starter kit and skill
For a connected review, ask for institution evidence → funding context → BTC exit estimates, with each source date, coverage gap and limitation kept separate. Client/model costs and fair-use limits may apply. Research calls do not execute trades.
Start with source_rights_status for feature availability and
data_health for source clocks and faults. The broader tools have different jobs:
Needed output | Tool | First arguments |
Cross-market summary and coverage gaps |
|
|
Detailed rates, spreads and funding-desk evidence |
|
|
Dated FX observations and accepted China annual histories |
|
|
Dataset catalog and links to sibling-product tools |
|
|
Compact cached funding metadata for an automated guard |
|
|
Start with the row matching the task. The tool selection guide includes all public tools, example questions and a repeatable funding-review workflow.
Public US dollar funding research from source-dated Fed and Treasury observations. Live board: seiche.info.
Dated answers to common research questions explain the numbers, source dates and limits.
LiquiLens, Seiche and Undertow are connected research products from LIQUILENS PRIVATE LIMITED, a registered company in India. Built for international review workflows: institution evidence → funding conditions → market liquidity. Market coverage, source clocks and authority remain specific to each product. Company and investors · Company profile · Try the connected workflow.
A seiche is a standing wave in an enclosed body of water — invisible from the shore, until it sloshes over the edge. Funding stress behaves the same way.
Seiche is a free, open source (AGPL-3.0-or-later) money-, foreign-exchange and capital-market evidence terminal organized around the dollar funding system — US money markets, 22 public H.10 currency reference series, the Treasury capital-market complex, the global basins connected through swap lines, and the offshore-dollar crypto basin moored to the T-bill market through stablecoins. The core US board and USD desk use free official/public APIs (FRED, NY Fed Markets, OFR STFM, Treasury FiscalData, CFTC, ECB Data Portal, DeFiLlama, Coinbase Exchange). The global market-pack catalog can also declare licensed or tenant sources, but public outputs obey each source's redistribution policy and never expose restricted raw values.
Seiche publishes a construction-PIT historical diagnostic—with misses and eligibility limits kept visible—and is now accruing a separate as-published forward record that can be verified instead of reconstructed. Licensed terminals provide much broader real-time data and execution workflows, while OFR and NY Fed dashboards provide authoritative source views. Seiche is a narrower, opinionated research layer: forward-looking, alerting-ready, and provenance-honest. It is not a Bloomberg/Reuters replacement, a real-time quote service, or an execution venue.
Seiche is one of three altitudes in a single liquidity lab that fills that gap:
Seiche reads the plumbing, LiquiLens organizes
institution evidence for review, and Undertow measures market liquidity itself
(who provides depth in each segment, what an exit at position size costs
today). The wiring between the three is real, not a brochure: the desk
assistant pulls the LiquiLens failure board over MCP, the MARKET tab renders
Undertow's published pack live, and the Windfetch engine reads the FETCH pack
built in the Undertow repo back into this board. On names: the internal
composite engine called "undertow" (critical slowing down,
engines/undertow.py) is unrelated to the Undertow sister product.
For a first connected review, start with funding context in the browser. The shared portfolio plan prioritizes a recurring reviewer task while keeping each product's evidence and authority separate.
For a recurring agent workflow, the free starter kit combines Seiche funding context with LiquiLens bank evidence and Undertow exit estimates. Use the Hermes or OpenClaw setup guide. The selected public tools need no API key; fair-use limits and separate model-provider costs apply.
Seiche is distributed as software, an MCP service, a research dataset, and
machine-readable catalog metadata. Status is receipt-based: listed means a
durable public record and receipt exist, prepared means an owner-controlled
submission or publication remains, and blocked means a named prerequisite
must clear first. “Usable in repo” describes local artifact readiness, not a
ledger status. The auditable source of truth is
distribution/submissions.csv.
Surface | What is available | Status |
OpenBB | Typed provider and | 0.1.1 published on PyPI; ecosystem PR #13 archived/unmerged; official family Marketplace application submitted, review and fee waiver pending |
Zenodo | Release deposition metadata, citation identity, and related-source records (metadata) | Prepared; no deposit or DOI claimed |
Hugging Face | Rights-reviewed direct-OFR dataset card and staging layout (dataset card) | Validated draft; upload prepared |
Kaggle | Dataset metadata and reference-only staging layout (metadata) | Validated draft; upload prepared |
Smithery | Owner-published hosted endpoint entry (live record) | Listed; authenticated refresh accepted, cached aliases may lag. Public inventory rechecked 11 October: 16 tools |
MCP directories | Official Registry, Glama, Smithery, and eight additional live indexes (dated inventory) | 11 existing records; current checks and older observations dated separately |
Research notebooks | Commit-pinned, hash-checking direct-OFR workflow (notebook) | Usable in repo |
Python / R / JavaScript | Zero-secret world-markets API clients with evidence-contract checks (clients) | Usable in repo |
Market Atlas + structured corpus | Interactive canonical market observations, rights-aware dataset receipts, full normalized BIS records, Seiche partitions, public API and MCP (contract) | Live gateway; protected exports remain restricted and bulk records use bounded snapshot cursors |
Docker | Distroless, non-root, read-only Compose image and signed GHCR publication workflow (guide) | Built and tested locally; GHCR prepared |
Academic dataset | 10 direct-OFR series and 11,163 audited observations, excluding restricted and derived rows (research kit) | Validated draft; not submitted |
Data catalogs | Native-validated Croissant/Frictionless, graph-parsed DCAT 3/RO-Crate 1.3, and a DOI-free DataCite planning draft (metadata kit) | Validated as labeled; publication prepared |
AI integrations | Hosted MCP configs for Claude Code, Cursor, VS Code, Gemini CLI, and Codex; separate OpenAI workspace/submission guidance (configs) | Configs usable; OpenAI listing prepared |
PyPI | Python package and stdio MCP server ( | 0.16.5 published on PyPI; use the immutable version when pinning an installation |
Version 0.16.3 estuary checks the four monthly OFR money-market-fund series and six quarterly BIS series daily while preserving their observation dates and native release cadence. Signed deployment and publication acceptance are required before this source change is live.
Version 0.16.2 estuary prepares the reviewed Google-Extended policy, three dated dollar-funding answers and Riptide's public paper allocation beside the Market desk. The policy permits grounding/training only on three reviewed original explanations; source data, archives and other pages remain excluded. New signed application and publication receipts are required before these changes are live. The inherited 0.16.1 release connects the UAE DONIA reference to GIFT City's AED card and retains country funding and sovereign references for China, Japan, South Korea, Taiwan, Australia, the United Kingdom, all 21 euro-area countries and seven other European countries. Official observations retain their source dates, native frequency and gaps. The eight public MCP tools expose the country catalog through money_market_context(section="countries"); add country="JP" for a country desk or use section="india" for the India desk.
New official SOFR, EFFR, IORB, overnight reverse-repo and New York Fed funding
observations can reach the daily review without waiting through the previous
four-to-twelve-hour cache windows. Failed refreshes retain the original source
dates and stale warnings. Deployment and immutable package publication remain
subject to signed release gates.
The verified NY Fed historical importer covers 34 canonical instruments. Archived observations retain unknown publication clocks and actual ingestion times, preserve existing live vintages, and remain excluded from forecast inputs that require known publication clocks. The structured funding, forex and China workbench retains exact source dates, units, capture evidence and missing states. Numerical China context requires its independent signed acceptance. Verify deployment and package availability from the release receipts and linked registries.
Eight research tools remain anonymous and free. Legacy derived tools are unavailable; client and catalog copy must preserve that boundary. See the distribution and container trust guide for verification and release invariants.
v2.3 "Letters of Marque" (built in tandem across two sessions) adds the forecast layer and the layer that makes every other layer accountable: Undertow (critical slowing down — the basin's damping, measured on ordinary days), the Swell Forecast (the funding-stress forward curve — P(pop ≥ x bp) by date, six weeks out, from the public forcing calendar), The Stack (walk-forward ensemble of every event forecaster — rule, ML, analogs, Swell — plus The Tell, with a disagreement gauge), The Book (HELM tab — explicit daily positions on 2y/10y duration proxies, S&P and BTC over a T-bill base, walk-forward P&L with costs, block-bootstrap Sharpe CIs and mandatory benchmarks, verdict printed even when it loses), a hash-chained as-published track record shipped inside the static publish (nobody, including the operator, can quietly rewrite a bad month), and the Far Basin — Palimpsest's censorship-fear channel (palimpsest.info), a policy confession signal no market data vendor carries, honestly quarantined until it accrues testable history.
Engine | Question it answers |
Kink Engine | Where does reserve scarcity start, and how many days away is it at the current drain rate? (live hockey-stick fit of SOFR−IORB vs reserves/GDP) |
Liquidity Weather | What does the reserve path look like 6 weeks out — and which auction-settlement days land on thin ice? (TGA seasonal model + Fed drift + settlement calendar + backtested error bands) |
Tail Seismograph | Are the P99 tails of SOFR/TGCR/BGCR detaching from the median — the first tell of every squeeze? |
USD Money Market Desk ★ | Seven institutional-depth sections over the US cash system: policy corridor and overnight spreads; SOFR/TGCR/BGCR distributions and tails; repo-segment rates and volumes; CP−Treasury spreads; bills; liquidity buffers and Fed facilities; and MMF repo plumbing. Cross-source arithmetic uses exact common dates, repo aggregates require a fixed component set, and the descriptive NORMAL/WATCH/STRAIN/STRESS label uses a dependence-robust family-wise adjustment rather than an uncalibrated maximum. |
Global Money Market Atlas ★ | A licence-aware, native-frequency catalog and available-evidence comparison across 19 registered monetary systems and 21 national sovereign-reference packs, plus a dated source-audited discovery ledger of 44 additional monetary areas across nine regions. Registration and discovery are not live coverage. Each available market is compared only with its own history and can be |
Echo Engine | Does today's 30-day trajectory rhyme with the run-up to any historical stress episode? |
Tide Tables ★ | What happened next, every time the water looked like this? Markets rhyme, so forecast like a tide table: the k nearest analogs of today's trailing state trajectory over ALL history (labeled or not, expanding-z — no look-ahead) publish their actual forward spread paths as a fan, the share followed by a funding event within 5bd (Wilson CI vs climatology), a NOVELTY gauge ("the board has never looked like this" is its own signal, and flags the fan as extrapolation), and a walk-forward hindcast that says honestly whether analogs beat the base rate. |
RV X-Ray | How big is the leveraged Treasury RV complex, and what does a 5/15/30bp shock do to it? |
Crowding | Where are leveraged funds most crowded relative to their own history (UST curve, SOFR/FF futures, S&P)? |
Auction Digestion | Is the market choking on Treasury supply? |
Warehouse | How full is the primary-dealer balance sheet — the shock absorber of last resort? (NY Fed PD stats by maturity bucket) |
Resonance Engine ★ | The seiche made literal: does the same calendar forcing (month-end, quarter-end, year-end, tax dates) produce a bigger slosh than it used to? Amplification = damping loss = fragility rising while levels look calm. |
Undertow ★ | The free-decay half of the resonance physics: critical slowing down (Scheffer et al.), measured continuously. Rising lag-1 autocorrelation + variance of the detrended spread/tail and a stretching recovery half-life after everyday pops = the basin losing damping on days when NOTHING is happening. Expanding percentiles only; weighted into the composite as structural evidence. |
Swell Forecast ★ | A 42-business-day funding-stress forward curve: P(SOFR−IORB pop ≥ 2/5/10/20bp) by date, built from the public forcing calendar (turn/tax/settlement days each keep their full expanding distribution of historical pops), lifted by the live damping state and announced coupon settlements. It compounds to P(event by horizon), is walk-forward scored vs climatology on final-vintage history with the reliability table printed, and self-demotes to "trust the dates, not the levels" when the levels stop earning it. |
Hydrophone Array ★ | How connected is the plumbing right now? (absorption ratio over 11 funding series + a live lead-lag map of which pipe is upstream) |
Global Basin Coupling ★ | Are the US, euro-area, UK, India (FX channel) and crypto basins moving as one tide? Plus the global confession channel: USD swap-line draws (test operations excluded). |
The Estuary / Passage ★ | Where FX settlement and physical inventory become money-market cash demand. Twenty-two H.10 currencies, advanced/emerging dollar indices, daily energy and monthly IMF commodity breadth are normalized into an upstream-pressure reading, then compared with SOFR−IORB and commercial-paper spreads. Its differentiator, The Passage, chooses each candidate target and lag on the first 60% of aligned history and calls it |
Oil × Funding ★ | The barrel's balance sheet, in both directions: WTI/Brent, CP−bill and SOFR−IORB evidence; live Cushing stocks and Brent−WTI basis kept separate from dated capacity, benchmark and chokepoint references; a rolling change-on-change coupling diagnostic; the observed mechanical carry hurdle; energy/core CPI into IORB; broad foreign-official dollar-parking proxies for the recycling channel; and an editable, explicitly scenario-only lab for cargo credit, margin calls, RBI liquidity absorption and OMC commercial-paper demand. Context only, never a composite input. |
Ballast ★ | The energy-futures cash ledger inside Oil × Funding. Exact CFTC contract codes for WTI and Henry Hub join weekly open interest, trader classes and paying-side concentration to public benchmark moves and contract multipliers; EIA commercial crude stocks supply the physical-collateral leg; SOFR−IORB and CP−bill show a separate funding-amplifier overlay. The output is a bounded gross mark-displacement proxy—not an observed margin call—and the headline takes the worst own-history commodity/physical percentile without blending or letting funding alone manufacture a commodity alert. Typed handoffs route exit cost to Undertow and named-institution exposure to LiquiLens. Context only, never a composite input. |
Stablecoin Moorings ★ | The offshore-dollar basin's tie lines: peg deviations (USDT history + live board), total-circulation flows ($200B+ of T-bills behind them), and the 24/7 BTC canary — crypto trades when funding markets sleep. |
ML Lab | Learned P(funding event within 5bd): walk-forward with a 5bd boundary embargo, benchmarked against climatology AND the rule-based index, reliability table + decision-utility scoring published. Verdict at build: ranks better than the rule (OOS AUROC 0.826 vs 0.806; 0.812 on the orthogonal feature set) but probability levels don't beat climatology — use for ranking/alerting, not literal odds. The verdict self-updates. |
Station-Keeping ★ | Orbit-determination transfer: propagate the reserve system's expected state (fiscal seasonal, calendar buckets, trailing drift), CUSUM the innovation residuals, flag unmodeled "burns" — debt-ceiling cash games, RMP pace changes — often before they're narrated. Doubles as the Weather model's health monitor. |
Riptide ★ | The pop prognosis — the one morning the whole desk asks the same question, answered: chop or current? Every declustered spread pop becomes a trial; the discriminators (RRP co-sign — a pop WITHOUT its mechanical quarter-end co-move is genuine scarcity, the 2025 signature; calendar bucket; damping state) feed a deliberately tiny walk-forward logistic that classifies the live pop as calendar mechanics or the start of a squeeze, with P(sticky) and P(escalates) scored pop-by-pop against the base rate on final-vintage history. Speaks only when there is a live pop; flat water is itself the reading. |
The Breakwater ★ | The rescuer modeled — the feature no forecaster ships: the Fed is not weather, it is a PLAYER, and every intervention in the public record is a confession of where its pain threshold sat that day. A zero-parameter revealed-preference catalog (repo ops '19, QE '20, SRF '21, BTFP '23, QT taper '24, RMPs '25) compared with the final/current-vintage construction-PIT board for the day before each announcement yields a diagnostic threshold and a live rescue proximity gauge — which cuts both ways, and the engine says so: a forecast miss after an intervention is a save, not a false alarm. |
Bathymetry ★ | The basin floor mapped from the water's motion — the physics program end to end. The daily pop statistic is treated as a diffusion and its dynamics are RECONSTRUCTED from the data (Kramers–Moyal / empirical Langevin): drift → the effective potential (the well the spread rests in, its restoring stiffness, and the escape barrier printed in units of thermal energy k_BT); the binned transition operator → the quantum-dual energy spectrum (Fokker–Planck ↔ Schrödinger: stationary density = ground state, eigenvalue moduli = energy levels, spectral gap = inverse of the slowest relaxation time — critical slowing down measured operator-theoretically, corroborating Undertow by an independent estimator); stationary probability currents → entropy production (Schnakenberg, nats/day — the arrow of time: a calm basin relaxes, a stressed one is pumped); and absorbing-boundary first passage → P(funding event within h bd |
The Stack ★ | One P(funding event, 5bd) from the whole fleet: rule index, ML Lab, Tide Tables, Swell and Bathymetry calibrated per-member and blended walk-forward (with regime dummies, ~10 params on purpose). Publishes the equal-weight mean instead whenever the fitted stack fails to beat it OOS, publishes member DISPERSION — when the fleet disagrees, conviction drops — and wraps today's number in a Venn–Abers calibrated band [p0, p1] with finite-sample validity guarantees: not "our probability is 7%" but "the calibrated probability is provably between these bounds". |
The Book ★ | The signal made accountable (HELM tab): a FROZEN rulebook maps the ensemble to explicit daily long/short/flat weights (2y/10y UST duration proxies, S&P 500, BTC over T-bill cash; hysteresis bands, a disagreement gate, vol targeting, per-sleeve cost haircuts), then walk-forward P&L — signal t earns returns t+1, enforced in one place and unit-tested — with stationary-block-bootstrap Sharpe CIs, Newey–West t-stats, per-episode attribution, doubled-cost rerun, and benchmarks through the identical pipeline. If it doesn't beat the static mix after costs, the page says so in bold. Every day's positions land in a hash-chained as-published ledger carried by the published site — tamper-evident by construction. Paper proxy; not advice. |
Merian Modes ★ | (v2.6 "Bathysphere") The seiche eigenmodes, estimated instead of assumed. Merian's formula gives a real basin's standing-wave period from its geometry; we go the other way — Hankel-DMD (a finite-dimensional estimate of the Koopman operator: classical dynamics in the Hilbert-space clothes of Koopman–von Neumann mechanics) reads the funding basin's actual modes out of the plumbing panel: period, growth rate, current excitation. A mode with |λ| > 1 is a growing oscillation — instability visible before levels move; the ~21bd mode is the month-end forcing seen a second, independent way. The linear mode-propagation forecast is scored vs persistence and self-demotes (modes are structure, not a crystal ball). |
The Gyre ★ | (v2.6) Is prediction possible at all? Takens delay embedding + empirical dynamic modeling (Sugihara): simplex-projection skill by horizon (chaos decays, noise never had skill), a phase-randomized surrogate gate for determinism beyond linear autocorrelation, the S-map θ test for state-dependent (nonlinear) dynamics, and the S-map Jacobian's local expansion rate |λ| as a live "the water is locally unstable" gauge. Tide Tables asks WHICH history rhymes; the Gyre asks whether the basin's dynamics are deterministic enough to rhyme at all. |
Rogue Wave ★ | (v2.6) The tail law. Extreme value theory is literally the mathematics of rogue waves: peaks-over-threshold GPD (probability-weighted moments, bootstrap CIs, threshold-sensitivity table printed) on the SAME declustered pop statistic as PROOF. Swell's empirical exceedance curves stop dead at the largest pop in the sample; the GPD is the honest instrument for the wave that is NOT in the sample yet — the once-a-decade pop in bp, P(pop ≥ 25bp within a quarter), and whether the tail is getting heavier as the buffers drain (annual expanding ξ refits). |
Far Basin ★ | The policy-fear channel: Palimpsest (palimpsest.info) measures what the Chinese state rushes to delete — the DDTI deletion-threat index, newly-targeted terms, the Generative Firewall Index — CI-published, keyless, mirrored on GitHub raw. A confession channel one basin further out, carried by no market data vendor. Honest scope: days old as a public series, so it accrues locally and stays QUARANTINED (context only, never in the composite, never a model feature) until it clears 250 daily observations. |
Seiche Index | One 0–100 number with full decomposition and a regime call: CALM / EROSION / STRAIN / STRESS. |
★ = methods invented for this tool.
The desk assistant: seiche ask "why is the index elevated?" (or the Ask box on
BOARD) answers strictly from a deterministic context pack of the live board — every
number cited to its engine and as-of date, "not on the board" instead of improvisation.
Routed through free-llm-router's free tiers, or any OpenAI-compatible endpoint via
SEICHE_LLM_BASE_URL; with neither configured it returns the context pack itself.
The analytics layers on top:
The Tell — plumbing percentile minus market-priced-stress percentile (VIX, HY/IG OAS, rates vol). Positive = the basin is sloshing and the screens haven't noticed. The whole thesis in one tradeable number.
The Estuary — upstream FX/material pressure minus the funding pressure already priced in SOFR and commercial paper. A positive Passage gap says the cash burden is running ahead of its usual landing zones; the discovery/holdout map then shows which links actually survived unseen history. Monthly physical breadth is never filled forward into the daily evidence, and the cash lab never pretends user assumptions are observed exposures.
The Navigator — an LLM forecaster made accountable: one committed
P(funding event, 5bd) per data-day, grounded strictly in the live board,
written into the hash-chained record. An LLM cannot be honestly backtested
(it has read the history), so its FORWARD record is its only evidence and
its weight stays zero until that record earns a hearing. seiche navigator.
The Communiqué — FOMC statements read as vintage-stamped data: frozen deterministic lexicons score policy direction, balance-sheet bias and funding-stress vocabulary per statement; the change vs the previous statement is the signal, and the Time Machine replays text as it stood.
The TED bridge — the ML Lab pretrains on the TED spread's 1990–2018 funding-stress record (2008/2011/2016) in the same feature slots, down-weighted, and publishes the transfer gain vs the SOFR-only model either way.
The Stack + The Book — the rule index, ML Lab, Tide Tables analogs, the Swell curve and Bathymetry's first-passage odds all emit P(funding event, 5bd); the Stack calibrates and blends them walk-forward (publishing the equal-weight mean whenever the fitted blend can't beat it), publishes member dispersion as a first-class ambiguity signal, and the Book converts the result into explicit daily paper positions with costs, benchmarks and bootstrap CIs. Every view's daily forecast and every position is appended to the hash-chained PIT record — a track record no reconstruction can polish.
Turn Barometer — forecasts the next month/quarter-end turn's severity with leave-one-out cross-validation, always benchmarked against a naive forecast. When the model can't beat naive, it says so and publishes naive instead.
Playbook — what S&P/VIX/OAS/yields did the last N times the board looked like this, in native units, with n printed. Decision support, not advice.
PROOF — the construction-PIT diagnostic lab: the index rebuilt with expanding-window statistics only (causal truncation is unit-tested, but source history is final/current-vintage), recall/precision with Wilson 95% intervals, run-level precision (alert days are serially correlated; runs are the honest trials), episode-by-episode lead times including the ones it missed — and the orthogonal signal test: the same event-capture with the target's own variable family (spread/tails) removed from the signal. At build: orthogonal recall 69% [CI 42–87] vs 62% full, with the structural components alone at the 98th–100th percentile 42 days before the Sep/Dec-2025 squeezes. The claim is causal structure, not autocorrelation.
Time Machine — final/current-vintage construction-PIT reconstruction using observations dated on or before any date since ~2018; it does not recreate the publication vintage visible then. Reconstructed to Sep 12 2019, the board reads EROSION with reserves $576B below the kink and flags Sep 16 2019 — the exact day the repo market broke — as a crunch window.
Principles: no naked numbers (every value carries source + as-of + staleness), fail-loud (a dead feed shows as DEAD and reduces published coverage — it never silently vanishes), honest lags (COT is T+3 by construction; shown, not hidden), and honest scope (a registered market with no qualifying public benchmark stays visible as unavailable; a policy rate or restricted input is never relabelled as a live traded benchmark).
The Market Atlas drills from nine live
market packs into canonical instruments, observations, source/publication/
knowledge clocks and rights, then continues into the shared bulk corpus at
/api/v2/corpus. Full normalized
BIS rows use bounded, generation-bound access. The engine ledger reconciles
1,118 acquisition attempts to 1,110 verified unique objects, including eight
recovered retries; its immutable public index exposes only rights-approved
metadata and structural profiles. BSE, NSE, NY Fed and restricted acquisition
recipes remain explicit metadata-only collections when values or downloads are
not publishable. Complete public BIS flows use immutable manifests and
content-addressed, byte-range-capable gzip shards so large transfers can resume
without mixing generations. Seiche request handlers do not fetch this corpus into an
analytic, and an object's data_class or acquisition review never grants
model, training, scoring, execution or redistribution permission. See
docs/MARKET_CORPUS.md for endpoints and invariants.
GET /api/v2/world-markets returns the versioned
seiche.world-markets.v1 projection of an already completed snapshot. It
connects money-market funding, 22 official daily FX reference series, three
trade-weighted dollar indexes, and a bounded macro-capital transmission view
through selected Treasury, credit, volatility, dealer, positioning and
commodity evidence, plus a signed metadata-only China macro side projection
over four release-reviewed NBS series identities. The response carries canonical citation URLs, separate
generation/evidence clocks, and observed, derived, structural,
restricted or unavailable status. Add ?section=forex (or summary,
money_markets, capital_markets, china_macro, sources, methodology, all) for a
smaller projection. The request never starts collection, scans historical
repositories or fits a model.
Crawlable citation pages live at /markets/,
/markets/forex/ and
/markets/capital-markets/,
with the signed metadata-only China catalog at
/markets/china-macro/.
They describe real public coverage and its gaps; they do not claim executable
quotes, every security or licensed redistribution rights. China raw exports,
histories and values remain restricted and never enter a gauge or score; see
docs/NBS_SIGNED_EXPORT.md for the operator and
verification contract.
GET /api/money-markets returns the full USD Money Market Desk. Every
metric carries its source, as-of date, cadence and plain-language explanation;
meaningful cards add native-series changes, a one-year robust z-score and a
three-year empirical percentile. Derived spreads use exact common observation
dates—there is no forward-fill across unrelated source clocks. The headline
displays both the raw most-extreme channel and a conservative Bonferroni-
adjusted desk-wide rank; reserve and ON-RRP stock levels remain visible
context but cannot manufacture a funding-stress label by themselves.
GET /api/v2/money-markets returns the Global Money Market Atlas from
already collected canonical observations for all 11 registered packs.
Eleven is a catalog count, not a claim of 11 live benchmarks or validated
markets. It also returns a 44-row source-audited expansion ledger with
benchmark taxonomy, authority link, access/rights caveat, confidence, review
stage and verification date. Those rows are discovery metadata, not quotes.
Query coverage, faults and per-market status for what is actually available
now; the request never starts collection.
GET /api/v2/country-funding lists country coverage; append /JP, /CN,
/KR, /TW, /AU, /GB, /DE, /FR, /ES or another catalog code for
dated policy, funding, liquidity and sovereign references. UK aliases GB.
MCP exposes the same chartless data through money_market_context with
section="countries", country="JP". Shared euro-area policy is separate from
national sovereign debt. See sources, dates and gaps.
GET /api/v2/india-funding returns the India funding desk:
RBI liquidity and policy evidence, money-market rates, dated sovereign
benchmarks, monthly maturity spreads and separately labelled bond auctions.
MCP exposes the same chartless payload through money_market_context with
section="india". Missing daily tenors remain explicit; India remains
reference context.
Atlas state is explicit. AVAILABLE means a redistributable raw observation is
present. DERIVED_CONTEXT means a restricted/derived-only input may contribute
non-reversible own-history statistics, while its raw level and history remain
withheld. POLICY_ONLY means an official policy anchor is visible but no eligible
traded benchmark is available; policy is not used as a substitute. A declared
unavailable market remains an evidence gap, not a calm reading. Changes and
history windows follow each adapter's native cadence—weekly or monthly series
are never padded into daily data—and cross-market comparison uses own-history
normalization rather than unlike rate levels.
Seiche's AGPL-3.0-or-later license covers the code. It does not override upstream terms:
allowed inputs may expose values, derived_only inputs expose bounded derived
context, metadata_only inputs can describe availability but cannot enter public
calculations, and prohibited values and source metadata are omitted.
# backend (Python 3.12+)
cd backend
python3 -m venv .venv && .venv/bin/pip install -e .
.venv/bin/uvicorn seiche.api:app --port 8787
# frontend (dev)
cd frontend
npm install
npm run dev # http://localhost:5173 (proxies /api to :8787)
# or production single-process: npm run build, then uvicorn serves frontend/dist at /First load is slow (cold fetch of several years of history); everything after is served from the SQLite cache with cadence-aware TTLs.
seiche pull # force-refresh, print the index line
seiche brief --save # this morning's desk note (markdown, archived to data/briefs/)
seiche alert # evaluate alert rules once (cron/launchd-friendly; exit 2 = fired)
seiche watch -i 1800 # pull + alert on a loop
seiche replay 2019-09-12 # Time Machine in the terminal
seiche backtest # PROOF summary
seiche ml # ML Lab: event probability + honest validation
seiche analogs # Tide Tables: nearest historical analogs + forward fan
seiche swell # the funding-stress forward curve, 6 weeks out
seiche physics # the physics board: floor, modes, determinism, tail law
seiche bathymetry # the basin floor in detail: potential, spectrum, entropy, first passage
seiche book # the Book: today's positions + walk-forward P&L verdict
seiche ask "…" # desk assistant, grounded in the live board
seiche serve # API + UI
seiche mcp # serve the board to AI agents over MCP (stdio)
seiche nbs-intake catalog # four code-owned NBS source identities; no values
seiche nbs-intake status # verify the public-only signed China revision headSeiche is also a Model Context Protocol server — any MCP-capable agent (Claude Code, Codex, your own) can read the live board as tools. Where a data feed hands an agent raw macro numbers, Seiche hands it the conclusion: a regime read, forward event odds, historical analogs, and a historical diagnostic whose status, misses, and eligibility flags stay attached. Stdlib-only, no new dependencies.
claude mcp add seiche -- seiche-mcp # Claude Code, local (stdio)
SEICHE_MCP_PUBLIC=1 seiche-mcp # free surface onlyOr, zero-install, over HTTP: the same tools are served at /mcp on the API
(https://api.seiche.info/mcp). Add the URL and start calling. Eight tools answer anonymously; see the release scope above. Retired tools in the historical catalog below are unavailable:
claude mcp add --transport http seiche https://api.seiche.info/mcp
curl https://api.seiche.info/api/gaugeThe copy-paste quickstart and live tool runner are at seiche.info/developers.
tool | what it answers |
| unavailable in this release |
| unavailable in this release |
| unavailable in this release |
| unavailable in this release |
| unavailable in this release |
| freshness and provenance for every input, before you trust a reading |
| unavailable in this release |
| unavailable in this release |
| compact, chartless USD desk summary or one requested section, plus sources/methodology selectors |
| bounded INR/USD funding, CBUAE and ECB reference FX, and weekly gold positioning with source clocks |
| caller-assumption fine-gold carrying costs, simple interest and INR breakeven; no quote retrieval |
| selectable official FX providers, matching-date crosses, dated histories and accepted Palimpsest China structural evidence |
| bounded summary or money, forex, capital, source and methodology sections with canonical citation URLs |
| unavailable in this release |
| unavailable in this release |
That is the conclusion, the precedent, the honest record, the freshness, granular
USD money-market context, unified world-market context and cross-market transmission context, and it stays
free. Five analysis tools want a bearer token because they read gated
forecasting, replay, positioning, prose, or LLM engines rather than a published
contextual conclusion:
funding_stress_forecast, replay_asof, positioning_book, desk_brief and
ask_desk. institutional_flows answers anonymously but keeps its
method_versions back for the same reason.
An authenticated hosted caller also sees five private Agent Room preview
tools: agent_room_register_key, agent_room_create,
agent_room_append_event, agent_room_list_events, and agent_room_verify.
They record client-signed, server-co-signed agent discussion in a tamper-evident
room; every record is non-executable and grants no acceptance, order, execution,
payment, settlement, or custody authority. The full bearer-authenticated hosted
catalog is therefore 24 tools (14 public evidence + five gated analysis + five
Agent Room). See the exact security and signing contract.
Nothing fails at call time over this: tools/list returns exactly the tools the
caller can run, so an agent never sees a tool it cannot use. Both surfaces are
rate-limited per caller and metered per UTC day (anonymous callers per IP).
Full setup, the tool catalogue, client config, metering, tokens, and the pay-per-call option for the five analysis tools: docs/MCP.md.
Want the board in your pocket instead of a client config? The Hermes desk-agent kit turns hermes-agent into a Seiche desk agent on Telegram/Discord/Slack: a scheduled morning brief, regime alerts with anti-noise rules, construction-PIT episode replays, and a PROOF-grounded answer to "can I trust this". Walkthrough: docs/HERMES.md.
Alerts dedupe per state in SQLite, notify via macOS notification and optional
webhook (SEICHE_WEBHOOK_URL — Slack/Telegram/ntfy style {"text": ...}).
A launchd template lives in ops/com.seiche.watch.plist.
# Existing canonical host: install or refresh the signed release controller
# without activating it, then run its gate-only acceptance cycle.
bash /home/seiche/app/ops/deploy/install-release-poller.sh
SEICHE_CONTROL_GATE_ONLY=1 /usr/local/sbin/seiche-release-pollProduction uses the operator-provisioned /home/seiche/app layout documented
in ops/deploy/RELEASE-POLLER.md; this repository intentionally has no
unattended first-VPS bootstrap. The old /opt installer is retired because its
service and state layout never matched production.
GET /api/health never starts or waits for the full board build. It returns
the last completed snapshot's health fields with HTTP 200, or an immediate
HTTP 503 with status: warming_or_unavailable while the cache is cold. The
production background warmer owns snapshot construction; deployment probes
only observe whether it has published a result.
Put a TLS reverse proxy in front. The box already serving another site (e.g. Palimpsest) just adds a vhost — nginx:
server {
listen 443 ssl http2;
server_name seiche.example.com; # certbot --nginx -d seiche.example.com
location / { proxy_pass http://127.0.0.1:8787; proxy_set_header Host $host; }
}Signed releases: the on-host release poller is the sole automatic
controller. It accepts only the reviewed SSH-signed main tip, tests that exact
SHA in isolation, and hands it to the rollback-owning deploy wrapper. The
deploy-hetzner workflow is workflow_dispatch-only break-glass recovery and
must not run while the poller is active. The API cache lives under
/home/seiche/app/backend/data; canonical market state and backup receipts live
under /var/lib/seiche and /var/backups/seiche-market. Follow the poller and
market backup runbooks rather than copying one directory as if it were the
whole track record.
LLM keys for the desk assistant/Navigator and Telegram alert credentials belong
in a root-owned production environment file, not the retired
ops/deploy/seiche.service template. On the host, create
/etc/seiche/operator.env with mode 0600, then attach it to the actual
seiche-api.service through a non-secret systemd drop-in:
sudo install -d -o root -g root -m 0755 /etc/seiche
sudo test -e /etc/seiche/operator.env || \
sudo install -o root -g root -m 0600 /dev/null /etc/seiche/operator.env
sudoedit /etc/seiche/operator.env
sudo install -d -o root -g root -m 0755 \
/etc/systemd/system/seiche-api.service.d
printf '%s\n' '[Service]' \
'EnvironmentFile=/etc/seiche/operator.env' | \
sudo tee /etc/systemd/system/seiche-api.service.d/operator-env.conf >/dev/null
sudo systemctl daemon-reload
sudo systemctl restart seiche-api.serviceUse systemd KEY=value syntax in the environment file for only the required
SEICHE_LLM_*, SEICHE_TELEGRAM_*, or webhook settings. Never commit their
values. Confirm permissions with stat, then check systemctl status seiche-api.service and the API health route after restart.
backend/seiche/config.py quarantines every judgment call: composite weights, regime
thresholds, resonance/turn/tell parameters, alert rules, the episode library, contract
DV01s. The math never hides an opinion.
The eight-tool public evidence surface needs no account and does not depend on
paid upstream data; optional licensed or tenant inputs remain explicitly bounded.
Legacy forecast, replay, positioning, prose and LLM tools are unavailable. Seiche does not claim intraday-tick coverage: daily cadence plus
operation results is the honest granularity of the public stack. Historical
reconstruction uses final/current-vintage inputs and is therefore
construction-PIT, not validated-backtest evidence. The engine blocks the
historical backtest output unless every required input has an ALFRED/as-published
vintage manifest. From v2 onward Seiche accrues a true as-published point-in-time
record (/api/pit) and stores immutable observation captures for forward vintage
reconstruction. Those forward captures cannot repair vintages that were never
retained. Not investment advice.
The Seiche research_network tool and /api/v2/research-network endpoint
connect Palimpsest's complete source catalog with separately completed funding
context and explicit research steps into LiquiLens, Undertow and NarcoScope.
Use topic, offset and limit; follow next_offset for remaining datasets.
The human desk is https://seiche.info/#RESEARCH. Telegram readers can use
/research china, /research regions or /research liquidity.
Catalog rows are references, not permission to redistribute source values or change a score. Source clocks, rights and missingness remain attached. The retrieved catalog hash is a byte identity, not a producer attestation.
Native framework tools and cited quant pipeline captures connect Seiche funding, LiquiLens bank diagnostics and Undertow market liquidity through compact read-only tables. LangChain/LangGraph, CrewAI, OpenAI Agents and Pydantic AI share one evidence contract and repeat-call revision tokens. Current published history is not an as-published vintage archive. No execution authority or institutional-adoption claim is implied.
Labelled crypto stress episodes (Black Thursday 2020, Terra, FTX, the SVB/USDC weekend, the Oct-2025 liquidation cascade, the Ethena unwind) replayed with causal truncation but final/current-vintage inputs against the dollar-funding board. External wrecks show transmission; crypto-native wrecks show the board correctly staying quiet. Use for any 'does TradFi funding stress reach crypto' question, grounded in the record.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | No | False for a tool failure. |
| reason | No | |
| status | No | |
| reading | No | |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only and idempotent, and the description adds useful behavioral context: causal truncation with final/current-vintage inputs, and the expected result pattern that external wrecks transmit while crypto-native wrecks do not move the board. Terms like 'causal truncation' and 'current-vintage' are not unpacked, which keeps this from a 5.
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?
Three sentences front-load the subject, give concrete examples, state the interpretive behavior, and end with explicit usage guidance. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, idempotent tool with an output schema, the description sufficiently covers purpose, dataset contents, behavioral interpretation, and usage context. The output schema handles return-value details, so no further structured information is missing.
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 tool has zero parameters and 100% schema coverage, so the description carries no parameter-semantics burden. The zero-parameter baseline of 4 is appropriate; no unnecessary parameter details are introduced.
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 names a specific resource — labelled crypto stress episodes replayed against the dollar-funding board — and a concrete question it answers: whether TradFi funding stress reaches crypto. The named episodes and interpretive framing distinguish it from the broader sibling market-context 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?
It explicitly says 'Use for any ... question, grounded in the record,' which gives clear when-to-use guidance. It does not name alternatives or state when not to use it, so it stops short of full exclusion/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Freshness, provenance, and fault status for every underlying series (FRED, NY Fed, OFR, Treasury). Call this to confirm the board is current before relying on a reading.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | No | False for a tool failure. |
| faults | No | |
| reason | No | |
| status | No | |
| reading | No | |
| version | No | |
| category | No | |
| provenance | No | |
| generated_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds useful context about the tool's scope (which series are covered) and that it reports 'fault status', which implies error detection. No contradiction with annotations and no additional side-effect disclosure needed for a read-only tool.
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 sentences with no wasted words. It front-loads the core purpose and then gives a usage directive, making every sentence earn its place.
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 tool is simple (0 parameters, read-only, output schema provided) and the description fully covers when and why to use it, along with the data sources involved. The output schema likely captures return details, so the description does not need to explain them.
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 input schema has zero parameters, so there is no parameter semantics to clarify. Per the baseline, a zero-parameter tool receives a 4; the description correctly implies the tool takes no inputs and runs globally, which is consistent with the schema.
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 states a specific function—reporting freshness, provenance, and fault status for underlying data series—and names the concrete sources (FRED, NY Fed, OFR, Treasury). It also gives an actionable framing ('Call this to confirm the board is current') that distinguishes it from the sibling tools, which cover market or funding contexts rather than data health.
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 a clear when-to-use directive: 'Call this to confirm the board is current before relying on a reading.' This is explicit context for its intended use, though it does not mention when not to use it or name alternatives; given the uniqueness of the tool among siblings, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the current US dollar funding-stress conclusion. Choose this for the headline regime and its drivers; use money_market_context for detailed rate and liquidity metrics, or data_health to inspect input freshness. Returns a 0-100 composite index, the regime (CALM/EROSION/STRAIN/STRESS), per-component decomposition, the market-stress 'Tell', and any data faults. Preserve the source dates and missing evidence when reporting the reading.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | No | False for a tool failure. |
| tell | No | |
| as_of | No | |
| proof | No | |
| faults | No | |
| reason | No | |
| schema | No | |
| status | No | |
| reading | No | |
| version | No | |
| category | No | |
| delivery | No | |
| headline | No | |
| composite | No | |
| editorial | No | |
| conclusion | No | |
| data_quality | No | |
| generated_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds real behavioral value beyond that: it tells the agent the reading is a 0-100 composite with named regimes and per-component decomposition, and instructs it to preserve source dates and missing evidence when reporting — a non-obvious reporting constraint.
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?
Three sentences, front-loaded with the purpose, then routing, then reporting constraint. Dense but every clause carries distinct information — no restatement of the name or title.
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?
An output schema exists, so return values need not be enumerated, yet the description still summarizes the payload shape (index, regime, decomposition, Tell, data faults) and adds the evidence-preservation rule. With annotations covering safety, nothing an agent needs to call this correctly is missing.
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 tool takes no parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly presents this as a zero-argument read rather than implying hidden inputs.
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?
States a specific verb and resource: 'Read the current US dollar funding-stress conclusion.' It further names the headline scope (regime and drivers), which distinguishes it from the metric-detail tools in the same family.
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?
Explicit routing: 'Choose this for the headline regime and its drivers; use money_market_context for detailed rate and liquidity metrics, or data_health to inspect input freshness.' Both alternatives are named with the condition that selects them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The live upstream FX and physical-material pressure read versus funding already priced in SOFR and commercial paper, with the Passage's discovery/holdout ledger, de-clustered analogs, dollar-system context and settlement scenarios. Use for currency weakness, commodity working capital, FX settlement, or whether trade-flow cash pressure is reaching money markets. Context only; an earned link is stable association, not causation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | No | |
| as_of | No | |
| reason | No | |
| schema | No | |
| status | No | |
| analogs | No | |
| caveats | No | |
| leaders | No | |
| passage | No | |
| reading | No | |
| sources | No | |
| category | No | |
| headline | No | |
| scenario | No | |
| fx_breadth | No | |
| context_only | No | |
| generated_at | No | |
| dollar_system | No | |
| coverage_matrix | No | |
| materials_breadth | No | |
| settlement_structure | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false DNA, so the safety profile is covered. The description adds value by stating 'Context only' and clarifying that an earned link is association, not causation, which is a meaningful behavioral caveat. It does not contradict 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and jargon-heavy (e.g., 'de-clustered analogs', 'discovery/holdout ledger'), requiring interpretation. It packs much information into two sentences and does not start with a crisp one-liner, making it more complex than necessary for quick comprehension. Still, it avoids 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?
The tool has no required parameters and includes an output schema, so return values are covered. The description integrates multiple context signals (funding, analogs, dollar-system) and provides enough scope for an agent to decide when to invoke it relative to its niche. It does not explicitly mention caveats like latency or data refresh, but given the complexity of the tool, it is sufficiently complete.
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 tool takes no parametersaint, so there is nothing to explain beyond that. The description provides context about what the tool outputs (pressure signals, ledger details), which indirectly conveys purpose, but since schema coverage is 100% (empty), the baseline for zero params is 4. The description adds enough context to compensate.
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 specifies the tool as a live view of upstream FX and physical-material pressure relative to funding metrics, with a distinct scope including Passage ledger and analogs. It does not use a sharp verb+resource structure but is clearly distinguished from siblings like funding_stress_now and world_markets_context by its unique focus on trade-flow cash pressure and settlement scenarios.
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 use cases: currency weakness, commodity working capital, FX settlement, and trade-flow cash pressure reaching money markets. It cautions that context is not causal. However, it does not explicitly contrast with sibling tools or state when not to use it, so it is informative but not fully comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read dated USD/INR funding, separate ECB and CBUAE VAT FX references, and CFTC COMEX gold positioning. Cache-only research with source clocks; no executable prices or regulatory eligibility determination.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | No | False for a tool failure. |
| gold | No | |
| forex | No | |
| reason | No | |
| schema | No | |
| status | No | |
| funding | No | |
| sources | No | |
| category | No | |
| eligibility | No | |
| methodology | No | |
| context_only | No | |
| generated_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds meaningful context beyond that: cache-only operation, source clocks, and the limitation that no executable prices or regulatory eligibility determination are provided. It does not cover auth or rate limits, but those are less central here.
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 sentences are front-loaded with purpose and then bounded by constraints. Every clause contributes needed scope or limitation, with no filler or repetition.
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?
With no input parameters, an output schema present, and rich annotations, the description supplies enough context to select and invoke the tool correctly. It clarifies the research-only, cache-only nature and data domains, though it could be slightly more explicit about how the source clocks affect use.
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 tool has zero input parameters, so there are no parameter semantics to clarify. Per the scoring baseline for a parameterless tool, a 4 is appropriate; the description adds no contradictory or misleading parameter information.
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 a specific verb ('Read') and enumerates distinct resources: dated USD/INR funding, ECB/CBUAE VAT FX references, and CFTC COMEX gold positioning. The GIFT City and India–UAE framing plus the cache-only research limitation distinguishes it from broader siblings like funding_stress_now or world_markets_context.
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 states a clear context ('Cache-only research with source clocks') and an exclusion ('no executable prices or regulatory eligibility determination'), telling the agent when this tool is appropriate. However, it does not name a sibling alternative to use instead when executable or regulatory data is needed, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate fine gold, simple financing cost and INR per fine gram from explicit decimal-string assumptions. All inputs are caller supplied, no quote is verified, and inputs are not persisted.
| Name | Required | Description | Default |
|---|---|---|---|
| days | Yes | ||
| fees_usd | Yes | ||
| fineness | Yes | ||
| day_count | No | ||
| quantity_kg | Yes | ||
| fx_inr_per_usd | Yes | ||
| annual_rate_pct | Yes | ||
| price_usd_per_oz | Yes |
| Name | Required | Description |
|---|---|---|
| ok | No | False for a tool failure. |
| inputs | No | |
| reason | No | |
| schema | No | |
| status | No | |
| outputs | No | |
| category | No | |
| persisted | No | |
| assumptions | No | |
| eligibility | No | |
| context_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds substantive non-annotation behavior: no external quote verification and no persistence of inputs, which is exactly what an agent needs to know about a simulation tool.
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 tight sentences, no padding. The primary output statement comes first, followed by the crucial caveat about verification and persistence.
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?
An output schema exists, so return values need no explanation, and statelessness is clearly disclosed. The main residual gap is that with 8 parameters at 0% schema coverage, the description does not define units or semantics for the inputs beyond the string-format convention.
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 flags the crucial convention that inputs are decimal strings, which matters given the string patterns, but says nothing about individual parameters such as day_count (enum 360/365), fineness scale, or unit conventions for fees/days.
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?
States a specific verb ('Calculate') with concrete outputs (fine gold, simple financing cost, INR per fine gram) and the basis (explicit decimal-string assumptions). Sibling tools are mostly unrelated domains, so no routing conflict, though no explicit differentiation is offered.
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 clause 'All inputs are caller supplied, no quote is verified, and inputs are not persisted' tells the agent this is a self-contained deterministic calculation rather than a data lookup, which implies usage. It does not state when to prefer this over alternatives or any prerequisites (e.g., all amounts must be supplied as strings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The historical days most similar to today's funding conditions, and how often those analogs led to a stress event, plus a novelty flag for whether today has any close precedent. Use to ground a 'what usually happens from here' question in real history.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | No | False for a tool failure. |
| as_of | No | |
| reason | No | |
| status | No | |
| novelty | No | |
| reading | No | |
| category | No | |
| event_odds | No | |
| horizon_bd | No | |
| forward_fan | No | |
| hindcast_skill | No | |
| nearest_analogs | No | |
| historical_evidence | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by explaining what the tool returns (how often analogs led to stress, novelty flag) and its purpose in grounding future prediction in history, which goes beyond the annotation metadata.
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, well-structured sentence that efficiently conveys the core function, the output components, and a usage hint. Every clause adds necessary information with no redundancy or filler.
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 no parameters, clear annotations, and an output schema (not shown but indicated), the description is complete. It explains what it does, what it returns, and when to use it, covering all necessary aspects for a read-only historical-analog lookup 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?
The tool has zero parameters, so the baseline is 4. The description implicitly states that it uses 'today's funding conditions' as input context, which clarifies the conceptual basis even though no parameters are exposed in the schema.
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 identifies historical days most similar to today's funding conditions and provides stress-event frequency and a novelty flag. It names the specific resource ('historical analogs') and the action (finding nearest analogs), which distinguishes it from siblings like 'funding_stress_now' and 'money_market_context'.
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 explicitly says to use it to ground 'what usually happens from here' questions in real history, providing a clear usage context. It doesn't explicitly list when not to use it or name alternative tools, but the purpose is specific enough that the intended use is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hedge-fund / pension / sovereign positioning nowcast from public prints: the Treasury basis-trade size proxy (CFTC leveraged-fund net short, with a funding-fragility flag), asset-manager duration demand, foreign-official custody flows (H.4.1), a mixed-frequency fused positioning index with uncertainty bands, and how self-exciting stress events currently are (Hawkes branching ratio). Weekly cadence, point-in-time. Ask this when a question involves hedge fund leverage, the basis trade, pension duration bids, or sovereigns buying/selling Treasuries. Built from free public data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | No | False for a tool failure. |
| as_of | No | |
| reason | No | |
| status | No | |
| reading | No | |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint, so the safety profile is covered. The description adds valuable behavioral context: data source (public prints), frequency (weekly), point-in-time nature, and internal components like funding-fragility flag and Hawkes branching ratio. It does not mention rate limits or auth, but those are less critical for a read-only tool. No contradiction with 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?
The description is a single, dense paragraph but every sentence earns its place: first defines the core function, second lists the specific metrics, third gives usage guidance and data source. It is front-loaded with the purpose and avoids fluff. Appropriately concise for the complexity.
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?
With zero parameters and an output schema present, the description need not detail return values. It covers data source, cadence, usage scenarios, and some internal characteristics (uncertainty bands, Hawkes ratio). For a complex financial data tool, it provides sufficient context for an agent to decide when to call it and what to expect.
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 tool has zero parameters, so the baseline is 4 per guidelines. The description does not need to explain parameters because there are none. The schema coverage is 100% (empty), so no gaps exist.
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 provides a nowcast of institutional positioning (hedge fund, pension, sovereign) from public data, and enumerates specific components like basis-trade size proxy, duration demand, and custody flows. It distinguishes itself from siblings by naming unique metrics (CFTC leveraged-fund net short, H.4.1 flows) and specifies usage domains.
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 states when to use: 'Ask this when a question involves hedge fund leverage, the basis trade, pension duration bids, or sovereigns buying/selling Treasuries.' It also mentions weekly cadence and point-in-time nature, which implies freshness constraints. However, it does not name alternatives or provide when-not-to-use exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The latest available full-text Seiche editorial, which may predate today. Returns the canonical headline, dek, Markdown, publication date, evidence clock, generation mode and passing publication receipt. Report its publication and evidence dates; do not describe an older edition as today's analysis. Use funding_stress_now for current funding conditions, and quote the article without regenerating facts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| id | No | |
| ok | No | False for a tool failure. |
| url | No | |
| title | No | |
| reason | No | |
| status | No | |
| summary | No | |
| category | No | |
| content_text | No | |
| _liquidity_lab | No | |
| date_published | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so safety is covered. The description adds genuine non-structured context: the article may predate today, must not be mislabeled as current analysis, and should be quoted rather than regenerated. It does not add rate limits or auth notes, but the staleness caveat is meaningful.
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?
Three front-loaded sentences: identity and scope first, then a return-field enumeration, then usage constraints. The return-field list slightly duplicates the existing output schema, but the rest is tight and each instruction earns its place.
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?
With an output schema present, return values need no explanation, yet the description still gives an agent everything required to call and correctly report the result: identity, staleness caveat, and usage rules. Nothing material is missing for a zero-parameter read 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?
The tool takes zero parameters, so the baseline is 4 and there is no parameter semantics to compensate for. The description correctly omits parameter discussion.
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?
Names a specific resource (the latest full-text Seiche editorial) and its scope, including the caveat that it may predate today. It distinguishes itself from sibling funding_stress_now by explicitly routing current-conditions queries there, so an agent can tell the two apart without opening schemas.
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?
States when to use it (quote the editorial), when to redirect (funding_stress_now for current funding conditions), and how to use the output (report publication and evidence dates, don't present an older edition as today's analysis). No condition is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query dated observations for a selected currency pair and optional accepted China annual series. Choose this for a time series, same-date FX cross, or observed-interval change; use world_markets_context for a chartless overview and money_market_context for funding-desk metrics. Read cached official FX reference histories and same-date currency crosses, with native units, provenance, age and observed-interval changes. Inspect owner-accepted Palimpsest China annual economic series and revision-aware history beside the CNY reference. Daily fixings, annual context and licensed gaps remain distinct. No collection, model fitting, executable quotes or scoring.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base currency: each returned value is quote-currency units per one base unit. Must differ from quote. | USD |
| days | No | Calendar-day FX lookback from today, not an observation count. Only cached observations on shared dates are returned; gaps are not filled. | |
| quote | No | Quote currency for the selected pair's dated history; must be supported by provider and differ from base. | CNY |
| provider | No | Official FX reference source. Both currencies must be supported by this provider; the response lists its currencies. | h10 |
| china_series | No | Optional exact cn.wdi.* identifier from the response's china.series catalog. Omit to select the first accepted series, if available; never invent an ID or infer withheld values. |
| Name | Required | Description |
|---|---|---|
| ok | No | False for a tool failure. |
| china | No | |
| forex | No | |
| reason | No | |
| schema | No | |
| status | No | |
| category | No | |
| selection | No | |
| eligibility | No | |
| context_only | No | |
| generated_at | No | |
| money_markets | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world access. The description adds real behavioral context beyond that: data is cached, gaps are not filled, return values carry native units, provenance and age, and China series are revision-aware with daily fixings and licensed gaps kept distinct. It stops short of noting any rate limits or freshness caveats, so it is useful but not exhaustive.
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?
Front-loaded with the core action and the when-to-use routing before the supporting detail, and every sentence carries content. It is slightly dense with domain jargon ('owner-accepted Palimpsest China annual economic series') but not padded.
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?
With an output schema present, the description need not explain return values, and it correctly explains where the china_series identifier comes from ('the response's china.series catalog') and that providers list their supported currencies. Coverage of the closed-world, no-scoring boundary makes it complete enough for a zero-required-param query 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 description coverage is 100%, so base, quote, days, provider and china_series are all documented in the schema (including the calendar-day-not-count semantics of days and the cn.wdi.* constraint on china_series). The description repeats the general intent of these params but adds no new syntax, defaults, or format detail beyond the schema, so the baseline 3 applies.
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 names a specific verb (query), resources (dated FX observations plus optional accepted China annual series), and the exact output modes (time series, same-date FX cross, observed-interval change). It also carves out scope against siblings, so an agent can distinguish this from world_markets_context and money_market_context without reading either schema.
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?
Explicit selection guidance: 'Choose this for a time series, same-date FX cross, or observed-interval change; use world_markets_context for a chartless overview and money_market_context for funding-desk metrics.' Both the trigger and the two alternatives are named, plus a negative scope list (no collection, model fitting, executable quotes or scoring).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a funding desk's rates, spreads, policy corridor, liquidity buffers and source-level evidence. Choose this for detailed funding metrics; use funding_stress_now for the headline US stress regime, world_markets_context for a cross-asset overview, or market_workbench for FX and accepted China time series. Start with section='summary' for USD. Use section='countries' for the public-source country catalog, or add country='JP' (a supported ISO alpha-2 code; UK is an alias for GB) for dated policy, funding, liquidity and sovereign references. Country coverage is partial and monthly references are explicitly separate from daily curves. Granular, descriptive USD money-market context from the already assembled desk: policy corridor and overnight spreads; SOFR/TGCR/BGCR distributions and tails; repo-segment rates and volumes; CP-Treasury spreads; bills and cash curve; liquidity buffers and Fed facilities; and MMF repo plumbing. Use section='india' for the India funding, RBI liquidity, policy and sovereign-curve desk from a bounded canonical observation read. It keeps benchmark identities, date alignment, curve movements and mechanism hypotheses separate. India defaults to view='full' for compatibility; prefer view='summary' for findings, constraints and an exact metric ID catalog, then view='metric' with metric_id for one complete evidence card. These India-only views are independent reads, not a pinned snapshot or pagination. Otherwise use optional section to request a compact summary, one named USD desk section, diagnostics, sources, methodology, or all context. Diagnostics count funding persistence, compare secured/unsecured benchmarks and show calendar cohorts with sample limits, without changing any score. Returns exact-date alignment, native-cadence changes, empirical own-history statistics, freshness, coverage, formulas, sources, and caveats as applicable. Chart history is always omitted. USD reads only an already completed cached or persisted snapshot; it never triggers collection or engine recomputation, while freshness is re-evaluated at response time. Context only: no causal, predictive, probability, or trade claim.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | India only: legacy full desk, compact findings/catalog, or one exact metric card. | full |
| country | No | Country code for section=countries only. Omit to list supported countries; UK aliases GB. | |
| section | No | Projection to return; defaults to the compact desk summary. | summary |
| metric_id | No | Exact ID from the India summary metric_catalog; required only for view=metric. |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| asof | No | |
| india | No | Legacy full India desk, or opt-in summary with metric_catalog and freshness_summary, or exact metric with selection_status and selection_context. Missing/restricted cards retain their original status. |
| reason | No | |
| regime | No | |
| schema | No | |
| status | No | |
| caveats | No | |
| sources | No | |
| category | No | |
| coverage | No | |
| formulas | No | |
| sections | No | |
| countries | No | |
| freshness | No | |
| selection | No | |
| quant_read | No | |
| countercase | No | |
| diagnostics | No | |
| methodology | No | |
| context_only | No | |
| legal_notices | No | |
| plain_language | No | |
| section_catalog | No | |
| source_metadata | No | |
| strongest_signal | No | |
| available_selectors | No | |
| snapshot_generated_at | No | |
| chart_history_included | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/non-destructive annotations, it discloses that USD reads only a cached/persisted snapshot and never triggers collection or recomputation, that freshness is re-evaluated at response time, that chart history is always omitted, and that diagnostics never change scores. These are real behavioral traits the annotations do not convey. It stops short of a 5 only because these facts are buried in dense prose rather than crisply stated.
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?
Purpose and the sibling routing are front-loaded, which is good, but the remainder is a wall of prose interleaving USD, India, diagnostics, and output concerns across long run-on sentences. Most content earns its place given 14 enum sections, yet readability and scannability suffer.
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?
For a complex multi-modal inspection tool with four params and an output schema, the description covers routing, section semantics, freshness guarantees, coverage caveats, and the 'context only, no causal/predictive/trade claim' boundary. An agent has everything needed to call it correctly without the output schema explaining returns.
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 100% schema coverage the baseline is 3, but the description adds genuine routing meaning: view='full' exists for compatibility while 'summary' then 'metric' is the preferred path, metric_id must come from the India summary catalog, and country is only valid with section=countries (UK aliases GB). It interprets defaults and dependencies rather than repeating enum values.
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 names a specific verb ('Inspect') and resource set (a funding desk's rates, spreads, policy corridor, liquidity buffers, source-level evidence), then explicitly distinguishes itself from three named siblings. An agent can select it against funding_stress_now, world_markets_context, and market_workbench without opening any schema.
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 gives explicit when-to-use routing for every sibling, then prescribes exact section/view choices ('Start with section=summary for USD', 'use section=india... prefer view=summary... then view=metric'). It even names exclusions and the country-coverage limitation, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Observed WTI/Brent, commercial-paper and SOFR−IORB evidence; Ballast's WTI/Henry Hub CFTC positioning, gross mark-displacement proxy, paying-side concentration and EIA inventory ledger; live Cushing stocks and the Brent−WTI spread kept separate from dated capacity, benchmark and chokepoint references; the change-on-change oil/CP association; plus explicitly scenario-only cargo-credit, margin and India cash arithmetic. Use when a question asks how oil or energy futures can transmit cash pressure into dollar funding. Ballast is not an observed margin call; dated structure is not live transit data; nothing here is a forecast, trade signal, or Seiche composite input.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | No | |
| oil | No | |
| as_of | No | |
| india | No | |
| reason | No | |
| schema | No | |
| status | No | |
| ballast | No | |
| caveats | No | |
| funding | No | |
| reading | No | |
| sources | No | |
| category | No | |
| coupling | No | |
| scenario | No | |
| context_only | No | |
| generated_at | No | |
| inflation_policy | No | |
| market_structure | No | |
| channel_directions | No | |
| official_dollar_parking | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable caveats about data provenance (e.g., 'Ballast is not an observed margin call', 'dated structure is not live transit data', 'nothing here is a forecast, trade signal, or Seiche composite input') which clarify the nature of the information beyond the annotations. It also notes that certain items are 'scenario-only' arithmetic, adding transparency about the data's reliability and limitations.
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, dense run-on sentence packed with many semicolon-separated clauses and specialized jargon. While it is information-dense, it is not concise or well-structured for quick comprehension. It would benefit from breaking into separate sentences or bullet points. The sheer volume of detail makes it harder to parse, and every word is not earning its keep due to redundancy (e.g., listing every data category in a list-like manner without clear hierarchy).
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?
With no parameters and an output schema already present, the description's job is to explain the tool's context and content. It extensively lists the data elements and explicitly marks what is scenario-only versus observed, which provides a comprehensive picture. It does not need to explain return values because the output schema covers that. The description is thorough and leaves little ambiguity about what the tool provides, despite being verbose.
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 tool has zero parameters and an empty schema, so there is nothing to explain. According to the rubric, 0 parameters yields a baseline score of 4. The description does not need to compensate for schema gaps since there are none. It provides a rich description of the data content, which effectively conveys what the tool returns, even though there are no parameters to document.
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 defines the tool's purpose: to provide oil/energy futures transmission context into dollar funding. It enumerates specific data types (WTI/Brent, CP, SOFR-IORB, CFTC positioning, etc.) and explicitly states when to use it ('Use when a question asks how oil or energy futures can transmit cash pressure into dollar funding'). This distinguishes it from sibling tools like 'funding_stress_now' and 'money_market_context' by focusing on oil-specific transmission mechanics.
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 an explicit when-to-use condition ('Use when...') which serves as clear usage guidance. However, it does not explicitly mention when not to use it or suggest alternative tools, but the condition is precise enough. The exclusions (e.g., 'Ballast is not an observed margin call') are more about data interpretation than tool selection, so they don't fully cover usage alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The backtest scoreboard, stated honestly: recall and precision with 95% confidence intervals over labelled funding events, an orthogonal robustness test, every named episode (hits and misses), and the caveats. Use to judge how much to trust the readings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | No | False for a tool failure. |
| as_of | No | |
| reason | No | |
| sample | No | |
| status | No | |
| caveats | No | |
| reading | No | |
| category | No | |
| episodes | No | |
| orthogonal | No | |
| event_capture | No | |
| historical_evidence | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. The description adds content details (recall, precision, confidence intervals, robustness test, episodes, caveats) and honesty framing, which goes beyond the safety profile without contradicting it.
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 well-structured sentence that front-loads 'backtest scoreboard' and lists components concisely. Every element earns its place, no 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 tool has an output schema (not shown but assumed) and annotations cover safety, the description fully explains what the tool provides: metrics, episodes, caveats. No missing information for an agent to decide 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?
No parameters exist, so schema coverage is trivially 100%. Baseline for 0 params is 4, and description doesn't need to add parameter info. It doesn't, so score is 4.
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?
Explicitly states it's a 'backtest scoreboard' with specific metrics (recall, precision, confidence intervals) and components (robustness test, episodes, caveats). Clearly distinct from sibling tools like crypto_stress_now or latest_article by focusing on the track record.
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 a clear when-to-use directive ('Use to judge how much to trust the readings'), but does not explicitly state exclusions or name alternative tools. The context is clear enough, though not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover which published datasets and sibling-product tools can answer a research question. Choose this for catalog discovery and handoff links, not for market observations: use world_markets_context for a market overview or market_workbench for supported FX and China histories. Explore the Palimpsest dataset catalog by topic, with source clocks, rights, freshness and pagination. Includes Seiche's separately completed funding context and explicit research steps into institution filings, exit liquidity and NarcoScope's granular global data. Source metadata and funding interpretations stay distinct. May fetch the published catalog; does not retrieve underlying dataset values or call the suggested sibling tools. No source collection, score changes, causal joins or trading authority.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum dataset metadata entries per page; suggested research steps are separate from this page size. | |
| topic | No | Research topic used to filter dataset metadata and select suggested sibling-product tools. This does not query those tools or retrieve dataset values. | all |
| offset | No | Zero-based offset within the filtered catalog. Use the returned next_offset while keeping topic and limit unchanged. |
| Name | Required | Description |
|---|---|---|
| ok | No | False for a tool failure. |
| reason | No | |
| schema | No | |
| source | No | |
| status | No | |
| category | No | |
| datasets | No | |
| selection | No | |
| next_steps | No | |
| context_only | No | |
| funding_context | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld=false/idempotent/non-destructive, and the description adds real behavioral boundaries beyond them: 'May fetch the published catalog; does not retrieve underlying dataset values or call the suggested sibling tools' plus 'No source collection, score changes, causal joins or trading authority.' It also flags an output distinction ('Source metadata and funding interpretations stay distinct').
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?
Front-loads purpose and alternatives in the first two sentences, and every sentence carries distinct scope information. Dense but not padded; the middle sentence listing funding/institution/liquidity data is the least readable but still informative.
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?
For a read-only discovery tool with a full output schema, the description covers scope, exclusions, alternatives, and explicit non-behaviors. Return values need not be explained since an output schema exists, so nothing an agent needs is missing.
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 100%, so the baseline is 3. The description adds semantic mapping the enum alone lacks, tying topics to meaning ('funding context', 'institution filings, exit liquidity and NarcoScope's granular global data') and describing pagination intent via the catalog-by-topic framing.
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?
States a specific verb and resource ('Discover which published datasets and sibling-product tools can answer a research question') and names the sibling tools it is distinct from (world_markets_context, market_workbench). An agent can route to or away from it without opening any schema.
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 frames the selection condition: 'Choose this for catalog discovery and handoff links, not for market observations,' then names alternatives for each excluded case. Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a small, fixed funding-state payload for an automated guard's freshness and coverage checks. Choose this only when that integration needs the bounded metadata contract; use funding_stress_now for research explanations and data_health for per-source diagnostics. A deterministic, bounded projection of the last completed Seiche board: funding regime, 0-100 stress index, coverage, source staleness counts, snapshot clock, and conservative evidence clock. It repeats the rights check and never collects, fits, calls a network source, reads a notary ledger, or contacts a broker. This is metadata-only derived context, not order-bound, non-executable, never real-money eligible, and it does not evaluate stream attestations or treat them as per-order authority.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | No | |
| state | No | |
| clocks | No | |
| reason | No | |
| regime | No | |
| schema | No | |
| status | No | |
| category | No | |
| staleness | No | |
| disclaimer | No | |
| executable | No | |
| source_url | No | |
| attestation | No | |
| fault_count | No | |
| limitations | No | |
| context_only | No | |
| coverage_pct | No | |
| stress_index | No | |
| rights_status | No | |
| evidence_class | No | |
| projection_mode | No | |
| canonicalization | No | |
| executable_quote | No | |
| attestation_state | No | |
| projection_sha256 | No | |
| can_authorize_order | No | |
| real_money_eligible | No | |
| request_time_broker | No | |
| request_time_notary | No | |
| request_time_network | No | |
| request_time_collection | No | |
| source_snapshot_version | No | |
| request_time_model_fitting | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world, but the description adds substantial context beyond them: it 'repeats the rights check' and never collects, fits, calls a network source, reads a notary ledger, or contacts a broker. It also declares the payload is metadata-only, non-executable, non-order-bound, and never real-money eligible.
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?
Front-loaded with purpose and routing before the payload enumeration, and the operational constraints are grouped sensibly. The final clause on stream attestations and per-order authority is dense and somewhat redundant with the earlier 'not order-bound / non-executable' phrasing, costing a little efficiency.
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?
An output schema exists, so return values need not be spelled out, yet the description still enumerates the payload fields for routing purposes. Combined with the explicit safety and non-execution guarantees, an agent has everything needed to call it correctly.
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?
Zero parameters, so the baseline is 4. The schema coverage is 100% and additionalProperties is false, and the description correctly implies a no-argument call by describing the payload as a fixed, deterministic projection.
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?
States a specific verb and resource ('Read a small, fixed funding-state payload') and scopes it to automated guard freshness/coverage checks. It then names the payload contents (funding regime, stress index, coverage, staleness, clocks), making it unmistakable relative to siblings.
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?
Explicit routing: 'Choose this only when that integration needs the bounded metadata contract; use funding_stress_now for research explanations and data_health for per-source diagnostics.' Both the condition for use and the alternatives with their own conditions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize the available money-market, FX, macro-capital and China evidence when a question spans markets or its scope is not yet clear. Start with section='summary', then select a relevant section. For detailed funding metrics use money_market_context; for dated FX/accepted China observations use market_workbench; for external dataset discovery use research_network. This chartless overview is not a time-series query. It projects only completed/public state into money_markets, forex, macro-capital transmission, China macro evidence, official references, methodology, or a compact summary. Every response carries snapshot/as-of clocks, canonical Seiche citation URLs, and explicit observed, derived, structural, restricted, and unavailable boundaries. The China structural catalog is unsigned; only status=restricted represents a verified Seiche owner-attested revision; both states keep NBS values, raw evidence, and history withheld. A separately operator-accepted economic_context may publish licensed World Bank WDI values with annual/structural freshness, distinct release, Palimpsest collection, and Seiche acceptance clocks. Those values are context only and never a live print, score, gauge, forecast, or signal. The sources selector is reference-only; use all when verified China context and its NBS source linkage must appear together. Coverage is curated and partial rather than exhaustive or uniformly live. It never triggers collection, repository history reads, or model fitting. Its named-field whitelist omits chart and history arrays for data minimization; that is not a per-record licensing audit. Capital coverage is limited to public positioning proxies, Treasury primary-market absorption, market stress, official liquidity and global dollar credit—not a security master, issuer-data service or consolidated tape. Use Undertow instead when the question is specifically about executable depth, liquidity-provider concentration, or position-sized exit cost.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Projection to return; defaults to the compact cross-market summary. | summary |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| as_of | No | |
| forex | No | |
| scope | No | |
| clocks | No | |
| reason | No | |
| schema | No | |
| status | No | |
| sources | No | |
| summary | No | |
| category | No | |
| citation | No | |
| coverage | No | |
| selection | No | |
| disclaimer | No | |
| china_macro | No | Metadata-only NBS catalog. Structural is an unsigned code-owned catalog; restricted means a Seiche owner-attested revision was verified. A separate optional economic_context contains only operator-accepted annual World Bank WDI observations and remains ineligible for scores and gauges. |
| methodology | No | |
| context_only | No | |
| generated_at | No | |
| money_markets | No | |
| canonical_urls | No | |
| capital_markets | No | |
| status_definitions | No | |
| available_selectors | No | |
| chart_history_included | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive/closed-world, but the description adds substantial context: it never triggers collection, history reads, or model fitting; it carries snapshot/as-of clocks and citation URLs; the China structural catalog is unsigned and only status=restricted is owner-attested; NBS values and history are withheld; and capital coverage is explicitly bounded. This is rich disclosure well beyond the structured hints.
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?
Front-loaded with purpose and usage in the first two sentences, with routing and boundaries following. Every sentence carries information, but the middle section is dense with licensing/clock/WDI minutiae that an agent selecting (not interpreting) the tool could skim, so it is slightly over-full rather than wasteful.
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?
An output schema exists, so return values need not be explained, and the description still covers coverage limits, data-minimization whitelist, confidentiality boundaries, and sibling exclusions. For a multi-section overview tool with a single optional enum parameter, nothing needed to call it correctly is missing.
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 100%, so the baseline is 3, but the description adds genuine selection semantics: default to section='summary', then pick a relevant section, and 'sources is reference-only; use all when verified China context and its NBS source linkage must appear together.' That is meaningful guidance the enum description alone does not provide.
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?
Opens with a specific verb and resource: 'Summarize the available money-market, FX, macro-capital and China evidence' for cross-market or ambiguous-scope questions. It explicitly distinguishes itself from named siblings (money_market_context, market_workbench, research_network, Undertow), so an agent can route without opening schemas.
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?
Gives explicit when-to-use ('question spans markets or its scope is not yet clear') and a recommended entry sequence ('Start with section=summary'). It names three alternatives with the exact conditions that select each, plus a fourth (Undertow) for executable-depth/liquidity questions, so when-not-to-use is also covered.
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.
v0.16.6-glama.1market_workbench5 fields changedInput schema / properties / base / descriptionAdded value: +"Base currency: each returned value is quote-currency units per one base unit. Must differ from quote."Input schema / properties / china_series / descriptionAdded value: +"Optional exact cn.wdi.* identifier from the response's china.series catalog. Omit to select the first accepted series, if available; never invent an ID or infer withheld values."Input schema / properties / days / descriptionAdded value: +"Calendar-day FX lookback from today, not an observation count. Only cached observations on shared dates are returned; gaps are not filled."Input schema / properties / provider / descriptionAdded value: +"Official FX reference source. Both currencies must be supported by this provider; the response lists its currencies."Input schema / properties / quote / descriptionAdded value: +"Quote currency for the selected pair's dated history; must be supported by provider and differ from base."research_network3 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum dataset metadata entries per page; suggested research steps are separate from this page size."Input schema / properties / offset / descriptionAdded value: +"Zero-based offset within the filtered catalog. Use the returned next_offset while keeping topic and limit unchanged."Input schema / properties / topic / descriptionAdded value: +"Research topic used to filter dataset metadata and select suggested sibling-product tools. This does not query those tools or retrieve dataset values."v0.16.5crypto_stress_recorddata_healthfunding_stress_nowfx_materials_passagegift_city_contextgold_inventory_carryhistorical_analogsinstitutional_flowslatest_articlemarket_workbenchmoney_market_contextoil_funding_contextproof_backtestresearch_networktrade_safety_risk_contextworld_markets_contextScored across 16 tools
The descriptions do heavy explicit lifting, each naming sibling tools to prefer for adjacent questions (e.g., money_market_context vs funding_stress_now vs world_markets_context). Domains are mostly distinct (funding, FX, oil, gold, crypto, discovery, editorial), though the cluster of '*_context' tools still creates some residual overlap that only careful reading resolves.
All names are consistently snake_case and thematically readable. However, the convention is not a uniform verb_noun pattern—it mixes domain_context names with noun phrases (data_health, latest_article, historical_analogs, proof_backtest, institutional_flows)—so it is recognizable but not fully predictable.
16 tools is slightly heavy but each maps to a genuinely distinct evidence artifact (stress index, backtest, analogs, flows, health, article, several market desks). Nothing appears redundant enough to warrant removal, but it sits just above the comfortable 3-15 range.
The surface covers the funding/FX lifecycle well: current stress, historical analogs, backtest trust, flow proxies, data health, discovery and editorial. Minor gaps (e.g., no explicit alerting/threshold or user-preference operation) are workable around, and there is clear guidance to external sibling products for adjacent needs.
FRED macro data, Treasury yields, FX rates & macro indicators for AI agents. Pay-per-query via x402.
75 MCP tools: SEC financials, FRED economics, IRS 990, FDA, FX, UK Companies House.
China A-share market data over MCP: 22 tools for quotes, K-line, financials, money flow, top-trader boards, sectors, macro, convertible bonds and factor screening. Five tools need no API key, so you can connect and try it immediately.
Financial data and research MCP for US/CN/JP equities: filings, statements, ownership, signals.
