Seiche — funding-stress terminal
Server Details
Funding stress early warning for US money markets from free public data, with an honest backtest.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 10 of 10 tools scored. Lowest: 3.1/5.
Each tool addresses a unique aspect of funding stress analysis: current state, forecast, historical analogs, backtest, data health, narrative, query, replay, crypto-specific episodes, and positioning. No two tools have overlapping purposes, ensuring clear differentiation.
All tool names use consistent snake_case with a noun-based structure (e.g., funding_stress_now, historical_analogs). No mixing of conventions like camelCase or inconsistent verb styles, making the pattern predictable.
With 10 tools, the server covers essential functionalities for a specialized domain (funding stress monitoring) without unnecessary bloat. Each tool serves a distinct purpose, and the count feels well-scoped for the terminal's purpose.
The tool set comprehensively covers the funding stress domain: real-time reading, forward forecasting, historical analogs, backtest verification, data health, narrative synthesis, and historical reconstruction. No critical gaps are apparent for typical analytical workflows.
Available Tools
10 toolsask_deskAsk the desk assistant (grounded)AInspect
Ask a natural-language question answered strictly from the live board, with the grounding cited. Requires an LLM endpoint configured on the server. Subscriber tool.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Your question about funding conditions (1-600 chars). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that answers are 'strictly from the live board' with cited grounding, indicating a RAG (retrieval-augmented generation) behavior rather than free-form generation. It also mentions the requirement for an LLM endpoint. No side effects or destructive actions are indicated, which is appropriate for a read-only tool. However, it could mention that answers may be unavailable if the LLM endpoint is misconfigured.
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 concise, consisting of two sentences. It front-loads the core purpose and behavior, then appends essential prerequisites. Every sentence adds value without redundancy. No wasted words.
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 single parameter, lack of output schema, and no annotations, the description covers the tool's purpose, behavior, and prerequisites adequately. It does not describe the output format or example responses, but that is acceptable since there is no output schema to complement. The description is sufficiently complete for the tool's 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 single parameter 'question' has 100% schema coverage (the schema already provides a description). The description adds additional context: 'about funding conditions (1-600 chars),' which clarifies the scope and length constraint beyond the schema's type definition. This helps the agent formulate appropriate queries.
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's purpose: answering natural-language questions strictly from a live board with grounded citations. The verb 'ask' and resource 'desk assistant (grounded)' are specific, and the mention of 'grounding' and 'live board' distinguishes it from sibling tools like 'desk_brief' (likely a summary tool).
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 notes prerequisites ('Requires an LLM endpoint configured on the server. Subscriber tool.') but does not explicitly state when to use this tool versus alternatives (e.g., when to use 'desk_brief' instead) or when not to use it. Usage context is implied but not detailed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
crypto_stress_recordWrecks: crypto episodes vs the funding boardAInspect
Labelled crypto stress episodes (Black Thursday 2020, Terra, FTX, the SVB/USDC weekend, the Oct-2025 liquidation cascade, the Ethena unwind) replayed point-in-time 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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full transparency burden. It explains that external wrecks show transmission while crypto-native wrecks show the board staying quiet—adding behavioral insight beyond a simple list. However, it omits details like return format, data source, or any side effects (e.g., no mention of performance or authentication).
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, front-loaded with key purpose and examples. Every phrase earns its place, no redundancy or fluff. Highly efficient.
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 no output schema and simple parameterless design, the description sufficiently explains what the tool does. However, it does not describe the output format (e.g., dataset, chart, text), which could be useful for an agent. Slightly incomplete, but not critically.
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 no parameters, so the description cannot add meaning to them. Baseline for 0 parameters is 4. No compensation needed; the description is adequate.
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's purpose: it replays labelled crypto stress episodes against the dollar-funding board to answer whether TradFi funding stress reaches crypto. It lists specific episodes (e.g., Black Thursday, Terra, FTX) and distinguishes between external and crypto-native wrecks, making the function unmistakable.
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 directs use for 'does TradFi funding stress reach crypto' questions. However, it does not specify when not to use this tool or mention alternatives among siblings (e.g., funding_stress_forecast, funding_stress_now), so it's clear but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
data_healthData freshness & provenanceAInspect
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It specifies the data sources and that the tool returns freshness, provenance, and fault status. However, it does not explicitly state that the operation is read-only or non-destructive, which would be helpful.
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 short, front-loaded sentences that convey essential information without any filler. Every phrase is purposeful.
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 and no output schema, the description provides adequate context: what data sources are covered, what information it returns, and when to use it. It could potentially mention the output format or any limitations, but overall it's 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 input schema has no parameters, so schema coverage is 100%. The description adds value by explaining the tool's purpose without needing to document any parameters, earning a baseline 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?
The description clearly states the tool provides freshness, provenance, and fault status for specific data series (FRED, NY Fed, OFR, Treasury). It distinguishes itself from sibling tools by focusing on data health, not analytics or queries.
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 advises calling this tool 'to confirm the board is current before relying on a reading.' This gives a clear when-to-use context, though it does not specify when not to use it or provide alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
desk_briefThis morning's desk note (markdown)AInspect
The full human-readable desk brief for today as markdown — the narrative summary of the whole board. Good when you want prose to quote or summarise rather than structured fields. Subscriber tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the output format (markdown) and scope (today's brief), implying a read-only snapshot. However, it doesn't detail freshness or caching behavior, which would be helpful.
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, no wasted words. The first sentence front-loads the core purpose, the second adds usage guidance. Every sentence 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?
Given the tool has no parameters, no output schema, and no annotations, the description is fully complete. It explains what the tool returns, when to use it, and its format.
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. The description adds meaning by stating the output is markdown prose, which is sufficiently beyond the empty schema. Baseline is 4, and the description meets it.
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 returns 'the full human-readable desk brief for today as markdown', which is a specific verb+resource. It distinguishes from sibling tools by contrasting with 'structured fields' and labels itself as a 'subscriber tool'.
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 guidance: 'Good when you want prose to quote or summarise rather than structured fields.' This tells when to use it rather than other tools that return structured data. It could explicitly name a sibling, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
funding_stress_forecastForward odds of a funding-stress eventAInspect
Forward odds of a funding-stress event over the next 5/10/21 business days from six independent views: three P(event) models (term-structure, first-passage physics, ML) and three stochastic scenarios on the index (regime-transition Markov, OU+jump analytic marginal, Monte Carlo path fan). Agreement is the signal. Use for forward-looking liquidity-risk questions. Subscriber tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It explains that the tool outputs odds from six models and that 'Agreement is the signal', and notes it is a 'Subscriber tool'. However, it does not explicitly state if the operation is read-only, requires authentication, or other behavioral traits like rate limits or data freshness.
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, front-loading the key purpose and structure. Every sentence adds value: first sentence defines the output, second explains the signal, third gives usage and access context. No wasted words.
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 lack of output schema and zero parameters, the description provides a good conceptual overview: six models, time horizons, and the agreement signal. It also notes subscription requirement. It could be more detailed on output format, but it sufficiently contextualizes the tool's role.
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 zero parameters, and schema_description_coverage is 100%. According to guidelines, 0 parameters yields a baseline of 4. The description adds no parameter-specific info, but the time horizons mentioned (5/10/21 days) are not parameters, so no additional semantics are needed.
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 that the tool provides forward odds of a funding-stress event over specific business days, identifying the verb 'provides' and resource 'funding-stress event odds'. It distinguishes itself from siblings like 'funding_stress_now' by focusing on forward-looking odds, but does not explicitly differentiate from all 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?
The description advises 'Use for forward-looking liquidity-risk questions', providing a clear context for use. However, it does not explicitly mention when not to use the tool or suggest alternatives like the sibling 'funding_stress_now' for current stress, so guidance is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
funding_stress_nowCurrent funding-stress readAInspect
The live money-market funding-stress reading: a 0-100 composite index, the regime (CALM/EROSION/STRAIN/STRESS), per-component decomposition, the market-stress 'Tell', and any data faults. Ask this whenever an analysis touches US dollar funding, repo, reserves, the Fed's balance sheet, or liquidity conditions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the output components (index, regime, decomposition, tell, faults) and implies it is a live, read-only operation. No side effects or destructive behavior are mentioned, but the lack of annotations is not the description's fault. It covers the key behavioral traits.
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, front-loaded with the most critical information (what the tool outputs) followed by usage context. Every sentence adds value with no redundancy or unnecessary detail.
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 no parameters, no output schema, and no annotations, the description provides sufficient context: output composition and usage triggers. It could optionally mention update frequency or authentication needs, but for a simple, no-param retrieval tool, it is adequately 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 has zero parameters, and the input schema coverage is 100% (no parameters). Per guidelines, baseline is 4. The description does not need to add parameter semantics since there are none, and it does not attempt to mislead.
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 provides a live 0-100 composite index, regime classification, per-component decomposition, a market-stress 'Tell', and data faults. It explicitly ties the tool to US dollar funding, repo, reserves, Fed balance sheet, and liquidity conditions, making its purpose highly specific and distinguishable from siblings like funding_stress_forecast.
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 includes explicit guidance: 'Ask this whenever an analysis touches US dollar funding...' This clearly signals when to use. However, it does not explicitly mention when not to use or contrast with alternatives like funding_stress_forecast, which would strengthen the dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
historical_analogsNearest historical analogsAInspect
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool returns historical analogs, stress event frequency, and a novelty flag. This adequately describes behavior for a read-only data retrieval 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. The first sentence explains what the tool provides, and the second gives usage guidance. It is front-loaded and efficient.
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 and no output schema, the description is complete. It explains the outputs (historical analogs, stress event frequency, novelty flag) and the intended use case, leaving no gaps.
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 baseline score of 4 applies. The description adds value beyond the empty schema by explaining what the tool does without needing parameter details.
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 finds historical days similar to today's funding conditions and shows how often those analogs led to a stress event, plus a novelty flag. It distinguishes from sibling tools like funding_stress_forecast by focusing on historical analogs rather than forecasts.
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 states the use case: 'Use to ground a 'what usually happens from here' question in real history.' While it doesn't specify when not to use, the context from sibling tools implies alternatives exist, providing adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
positioning_bookThe Book: implied stance & positionsBInspect
The stance (risk_on / risk_off / neutral) and positions implied by the stress read, with walk-forward Sharpe and the live as-published record. Not investment advice. Subscriber tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions the tool is not investment advice and shows outputs, but lacks details on how data is computed, required permissions, or whether it mutates state. The reliance on 'stress read' is ambiguous.
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 highly concise: two sentences and a disclaimer. It front-loads the core purpose ('The stance...positions implied by the stress read') and adds key details concisely. No wasted words.
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 description covers the output components adequately but lacks clarity on input context. Without parameters, the agent may not know that the tool relies on a pre-existing 'stress read' state. Missing explanation of terms like 'walk-forward Sharpe.'
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 schema coverage is 100% with no param details needed. The description implies the tool uses an implicit 'stress read' as context, but does not explicitly confirm that no parameters are required or clarify how the context is set.
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 provides 'stance (risk_on/risk_off/neutral) and positions implied by the stress read' along with walk-forward Sharpe and live record. It specifies the resource and output, but does not explicitly differentiate from sibling tools like 'desk_brief' or 'historical_analogs'.
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?
No explicit guidance is given on when to use this tool versus alternatives. The description implies it relates to a 'stress read' but does not state prerequisites or preferred contexts. The phrase 'Subscriber tool' hints at access restrictions but offers no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proof_backtestPROOF: the honest track recordAInspect
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently lists all behavioral details: what it returns (recall/precision, confidence intervals, robustness test, episodes, caveats). It discloses the honest nature, implying no destructive effects.
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-loading the main value proposition. Every sentence adds necessary information without 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 no output schema and no annotations, the description provides a comprehensive list of outputs (recall/precision, confidence intervals, robustness test, episodes, caveats). It is complete for a read-only reporting 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 input schema has zero parameters (schema coverage 100%), so the description adds meaning by explaining the purpose and output. It compensates fully for the lack of parameters by describing what the tool produces.
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 provides a backtest scoreboard with specific metrics (recall, precision, confidence intervals, robustness test, episodes, caveats). It distinguishes itself from siblings by emphasizing honesty and trustworthiness for judging readings.
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 'Use to judge how much to trust the readings,' providing a clear context for when to use it. It does not explicitly exclude alternatives, but the purpose is distinct from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
replay_asofTime Machine: the board on a past dateAInspect
Reconstruct the entire funding-stress board as it read on a historical date, point-in-time with no lookahead. Use to test whether Seiche would have flagged a past liquidity episode, or to align a backtest with what was knowable then. Subscriber tool (the Time Machine).
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Calendar date as YYYY-MM-DD (e.g. 2019-09-17). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Clearly discloses the tool reconstructs a past state without lookahead, implying read-only, non-destructive behavior. No annotations provided, so the description carries the full burden and meets it well.
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 succinct sentences deliver all essential information without redundancy. Every phrase adds value: purpose, use cases, and subscription status.
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's simplicity (one parameter, no output schema, no annotations), the description fully covers what an agent needs to know: what it does, when to use it, and key nuances (no lookahead, subscriber 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% with a clear format. The description adds context by specifying 'historical date' and 'point-in-time,' slightly surpassing the baseline of 3.
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 ('Reconstruct') and resource ('the entire funding-stress board') with clarity, and explicitly differentiates the tool from siblings by focusing on historical point-in-time reconstruction without lookahead.
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 explicit use cases: testing if Seiche would have flagged a past liquidity episode, or aligning a backtest with knowable information. Identifies as a subscriber tool, and the context of sibling tools (funding_stress_now, proof_backtest) reinforces when to use this historical variant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!