Seiche — world-markets evidence terminal

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.

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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: it discloses that the tool returns a composite index, a regime label, per-component decomposition, a 'Tell', and data faults – effectively describing what the output includes without relying on the output schema. It also implies this is a point-in-time snapshot ('live'), which is relevant. 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, front-loaded sentence that efficiently lays out the purpose and output components without extraneous words. Every clause adds information: 'live', '0-100 composite index', 'regime', 'per-component decomposition', 'Tell', 'data faults'. It is dense but well-structured and immediately communicates the tool's value.

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 zero parameters and an existing output schema, the description fully covers what an agent needs to know: when to use it (explicit trigger), what it returns (index, regime, decomposition, tell, faults), and that it's a safe read operation (via annotations). It even hints at the tool's breadth by listing market areas. No gaps apparent for a tool of this complexity.

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 per rubric baseline is 4. The schema description coverage is 100% (trivially, no params). The description does not need to explain parameters, and it doesn't, which is appropriate. It explains what the tool returns, which is more useful than param detail here.

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 title and description clearly state it provides 'The live money-market funding-stress reading' – a specific, measurable output (index, regime, components, tell, faults). It distinguishes from siblings like 'money_market_context' and 'oil_funding_context' by focusing narrowly on funding stress. The verb is implicit but obvious ('read' or 'get'), and the resource is precisely 'money-market funding-stress'.

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 usage trigger: 'Ask this whenever an analysis touches US dollar funding, repo, reserves, the Fed's balance sheet, or liquidity conditions.' This is clear and practical. However, it does not mention when NOT to use it or suggest alternatives (e.g., when a broader market context is needed), so it falls short of a 5.

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

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.

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.

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.

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

The description adds value beyond the annotations by explaining that on a quiet day it may return a clearly labelled historical replay, and it lists the exact return fields (headline, dek, Markdown, evidence clock, generation mode, receipt). This discloses fallback behavior and output contents, exceeding what the readOnly/idempotent hints convey.

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, front-loaded with the primary function and immediately followed by usage guidance and return details. Every clause adds value, 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 zero parameters and an existing output schema, the description covers purpose, usage, and behavioral nuances thoroughly. It explains the fallback replay mode and the return fields, leaving no significant gaps for an agent to misuse the 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?

There are zero parameters, so the description is not expected to explain parameter details. The baseline of 4 applies because the schema is trivially satisfied (no parameters to document), and the description still clarifies the tool's fixed operation.

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 returns the exact full-text Seiche editorial published today, with specific fields like headline, dek, Markdown, etc. It directly addresses 'what did Seiche write today?' and distinguishes itself by focusing on the canonical latest article without regeneration, differentiating it from sibling tools that handle other data or stress records.

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 provides explicit usage context ('Use this for what did Seiche write today? and quote it without regenerating facts'), giving a clear when-to-use. However, it does not explicitly mention alternatives or when not to use, though no sibling tool appears to serve the same purpose, so the guidance is adequate.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds valuable behavioral context: data is 'cached', 'official', 'revision-aware', and includes provenance and age. It also clarifies that 'Daily fixings, annual context and licensed gaps remain distinct', which sets expectations about data granularity. No contradiction with annotations; the description enriches the safety and data-handling story.

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 three sentences, each packed with meaning. It front-loads the core purpose and then adds scope limitations. It is efficient but not overly terse; every sentence earns its place. Slightly dense but well-structured.

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 complex with dual domains (FX and China series), and the description covers both. It mentions data provenance, age, and revision-awareness, which are important caveats. Since there is an output schema, return format is presumably defined. The description is sufficient for an agent to understand what data it will receive and what limitations exist (licensed gaps). Minor lack of parameter detail, but overall 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?

Schema description coverage is 0%, so the description must compensate. It implicitly covers base/quote ('FX reference histories', 'currency crosses'), days ('daily fixings'), and china_series ('China annual economic series'), but it does not explain the 'provider' parameter (h10 vs ecb) or the exact meaning of 'days' range. The description provides overall context but leaves some parameter semantics to inference. Given zero schema coverage, this is a moderate gap.

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 reads cached official FX reference histories and same-date currency crosses, plus China annual economic series. It specifies the exact resources and actions, and explicitly lists what it does not do (collection, model fitting, executable quotes, scoring), which differentiates it from potential siblings. The purpose is unambiguous and distinct.

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 clear context about what data is available and even provides exclusions (no collection, model fitting, etc.), but it does not explicitly name alternative tools or state when to choose this over a sibling like money_market_context. The 'Daily fixings, annual context and licensed gaps remain distinct' hint suggests scope but lacks direct routing guidance. So it's clear context without explicit alternatives.

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

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

Beyond the readOnly/idempotent annotations, the description discloses substantial behavioral detail: it never triggers collection or recomputation, freshness is re-evaluated at response time, chart history is always omitted, diagnostics do not change any score, and only a cached or persisted snapshot is accessed. There is 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 long but every sentence adds information: data scope, section usage, diagnostics semantics, return contents, chart omission, snapshot behavior, and limitations. It is front-loaded with the purpose and list of content, though a few phrases overlap ('already assembled desk' vs. 'already completed cached or persisted snapshot').

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 tool with one optional enum parameter, read-only annotations, and an output schema, the description is complete: it covers what data is returned, how to select projections, what diagnostics do, freshness behavior, chart omission, and non-claims. An agent has enough detail to invoke it correctly and understand its limitations.

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 only one optional parameter and 100% schema coverage, the schema already documents `section`. The description adds useful semantics by explaining that `section` can request a compact summary, a named desk section, diagnostics, sources, methodology, or all context, and mentions the default behavior implicitly.

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 verb-resource purpose: it 'returns' granular descriptive USD money-market context from the 'already assembled desk,' and enumerates the exact data domains (SOFR/TGCR/BGCR, repo, CP-Treasury, bills/cash, Fed facilities, MMF plumbing). It also distinguishes itself from scoring/forecasting siblings by explicitly saying 'Context only: no causal, predictive, probability, or trade claim.'

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 clear context for when to call it: to read a completed cached or persisted snapshot, request 'context only,' and never trigger computation or engine recomputation. It explicitly excludes causal, predictive, probability, and trade uses, and explains that diagnostics do not change any score, but it does not name sibling tools as alternatives.

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

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.

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.

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false, and the description adds useful behavioral context: it will not collect sources, change scores, make causal joins, or grant trading authority. It also clarifies that source metadata and funding interpretations remain 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?

The description is front-loaded with the core purpose and is dense but efficient. The second sentence adds valuable scope and exclusion information, though it is somewhat jargon-heavy with product-specific names.

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 output schema, annotations, and broad topic scope, the description covers the essential behavioral and scope information. It could be more complete by naming sibling alternatives or clarifying when to use this tool versus related context tools, but it is largely sufficient.

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 partially does by mentioning 'pagination' (relevant to limit/offset) and by listing topic categories that map to enum values like institutions, liquidity, and global_data. But it does not explain limit/offset semantics or define each parameter explicitly.

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 operation ('Explore every Palimpsest dataset by topic') and the resource scope, and it differentiates itself by listing exclusions ('No source collection, score changes, causal joins or trading authority'). However, the broader product-family scope and name 'research_network' are somewhat vague, so it is not a perfect 5.

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?

Usage context is implied rather than explicit: the description indicates this is for exploring datasets and research context, while exclusions tell the agent what it will not do. It does not name specific sibling tools as alternatives or state precise conditions for when to choose this tool over them.

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

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

The description substantially exceeds what the annotations already declare. It discloses that the tool repeats a rights check, never contacts external sources, is deterministic and bounded, is metadata-only, and does not treat stream attestations as per-order authority. This adds valuable behavioral context beyond readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, and it does not contradict any annotation.

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 but well-structured: the first sentence defines the deliverable and its contents, the second covers operational constraints, and the third clarifies exclusions. Every clause earns its place, with no filler or vague padding. The most important identity information is front-loaded.

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 available, the description is complete. It enumerates the projected output fields and documents the important safety and non-execution characteristics. An agent has enough information to invoke the tool correctly and interpret what kind of data it will receive.

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 is empty with additionalProperties false, so there are no parameter semantics to document. Schema coverage is effectively 100%, and the description correctly focuses on what the derived context contains rather than parameters. A baseline of 4 is appropriate for a zero-parameter tool.

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 identifies the tool as a deterministic, cache-only projection of the last completed Seiche board and enumerates the specific data it exposes: funding regime, stress index, coverage, staleness counts, and clocks. It differentiates itself from siblings through explicit constraints such as 'not order-bound', 'non-executable', and 'never real-money eligible'. This is far more specific than a tautology and gives an agent a concrete basis for selecting it.

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 clear context: this is cache-only derived context for trade-safety guards, and it explicitly excludes use cases involving live data, order binding, real-money eligibility, or stream-attestation authority. It does not name alternative tools or provide explicit 'use X instead' routing, but the when/when-not boundaries are strong enough for an agent to decide appropriately.

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

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

The description is unusually rich in behavioral disclosure: it states what the tool never triggers (collection, repository history reads, model fitting), what the data boundaries are (curated, partial, not a security master or consolidated tape), the copyright status of China catalog entries, freshness clauses, and exact boundary types ('observed, derived, structural, restricted, unavailable'). This adds substantial context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and long, with many stacked clauses and some jargon (e.g., 'advanced timestamp', 'Palimpsest collection', 'named-field whitelist excludes chart/history arrays'). In one pass it is hard to grasp the main action and the key use conditions. The core guidance could be front-loaded in two or three sentences, with the remaining details in a shorter, structured form. This is not concise enough for an agent to quickly parse and act on.

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 single-parameter, read-only, idempotent tool with a rich output schema, this description is extremely comprehensive. It defines the exact coverage, the boundary of what data is and isn't included, the relationship to a sibling, and the semantics of the only parameter. An agent has everything needed to select and 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?

Schema description coverage is 100% (the 'section' parameter is fully documented), so the baseline credit applies. The description further adds meaning by explaining the semantics of 'use all when verified China context and its NBS source linkage must appear together' and clarifying that 'sources' is reference-only. This is meaningful beyond the schema, so a 4 is warranted.

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 identifies a specific verb ('Unified... context') and a clear resource: it returns financial-market context across sections like money_markets, forex, macro-capital transmission, and China evidence. It explicitly distinguishes itself from the sibling Undertow for executable depth, which helps an agent know what this tool is not. However, the purpose is buried in dense prose and the opening phrase 'Unified, chartless context' is a bit abstract; it 's not as crisp as a direct 'Retrieves financial-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 provides explicit when-to-use and when-not-to-use guidance: 'Use Undertow instead when the question is specifically about executable depth, liquidity-provider concentration, or position-sized exit cost.' It also explains when to use the 'all' section (when verified China context and NBS source linkage must appear together). This is clear and actionable for an agent.

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