Seiche — Funding and FX Evidence

Inspect USD, India and country funding metrics

money_market_context

Read-onlyIdempotent

Inspect detailed funding desk metrics: policy corridor, overnight spreads, SOFR/TGCR/BGCR distributions, repo rates, and liquidity buffers. Use for granular USD or India money-market context.

Instructions

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.

Input Schema

TableJSON Schema

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.

Output Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.16.5Oct 17, 2026

TDQS

A4.5/5.0

Behavior4/5

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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server