Seiche — Funding and FX Evidence

Read cached funding metadata for automated guards

trade_safety_risk_context

Read-onlyIdempotent

Fetch a bounded funding-state snapshot for automated guard freshness and coverage checks: funding regime, 0-100 stress index, coverage, staleness counts, and clocks. Metadata-only; not executable.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`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

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.16.5Oct 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server