Skip to main content
Glama

spectra_stress_test_vault

Simulate a large redemption on a MetaVault to evaluate withdrawal liquidity. Computes maximum safe redemption size with minimal loss to remaining depositors.

Instructions

Simulate a large redemption on a MetaVault to assess withdrawal liquidity.

Builds a liquidity waterfall — sources of cash ordered by cost: Tier 1: Unallocated Cash (undeployed, no external — instant, no cost) Tier 1b: Avant Redemption Queue (avUSDx → avUSD burn, ~1 week cooldown per Avant docs, no price impact — emitted only when avant external positions exist; EXCLUDED from within-epoch max-safe calculation due to the delay, INCLUDED in the separate within-1-week metric) Tier 2: Naturally maturing Spectra LP positions (no cost, time-dependent) Tier 3: LP removal from Curve/Pendle pools (low-medium impact) Tier 4: PT sale on Curve pool (higher impact)

Note: "Unallocated" replaces the old "Idle" label. External positions (avant burn, pendle LP) are NOT counted in Tier 1 — they surface as Tier 1b (avant) or are excluded from all tiers (pendle external, conservative error mode).

Computes total coverage, cost to remaining depositors, and maximum safe redemption size (< 1% loss to remaining holders).

ERC-7540 constraint: once redemption is requested, the vault MUST fulfill it. There is no cancelRequest. This makes withdrawal liquidity critical.

Use spectra_get_curator_dashboard for operational overview before stress testing. Use spectra_get_pool_capacity to assess individual pool depth. Use morpho_monitor_risk for Morpho position risk.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainYesThe blockchain network where the MetaVault lives.
metavault_addressYesThe MetaVault contract address. Use spectra_list_metavaults to discover addresses.
redemption_pctNo% of TVL redeemed in one epoch (default 30)
market_stressNoIf true, assume 2x normal price impact on LP exits (correlated sell pressure)
verify_onchainNoReplace the API-derived `idleCapitalUsd` (Tier 1 unallocated cash) with a chain-truth equivalent computed from the Safe + infraVault state. Off by default — chain reads add latency and RPC pressure. When true, reads via the same engine that powers spectra_get_curator_dashboard (5-min cache shared with the dashboard, so a curator who just rendered the dashboard hits cache for free). The chain-truth formula is `safe.assetBalance + max(0, infraVault.totalAssets - sum(positions) - sum(external))`. The API derivation MISSES `safe.assetBalance` (curator-transit cash held DIRECTLY at the Safe, NOT counted in infraVault.totalAssets), which can be material when the curator is staging cross-chain inflows. Failures (RPC, timeout, missing bytecode) degrade to the API path. When `mv.underlying.price.usd === 0` the USD chain-truth is unverified; the output surfaces underlying-denominated chain-truth and falls back to API USD math for the waterfall. Dissolution: if telemetry shows zero verify_onchain=true invocations within 60 days of ship, the flag is fossil — consolidate by making chain-truth always-on for the cash derivation.
Behavior5/5

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 exhaustively explains the liquidity waterfall tiers, what is included/excluded (e.g., Tier 1b nuances), the ERC-7540 constraint (no cancelRequest), and the detailed behavior of the verify_onchain parameter, including failure modes and caching. No contradictions are present.

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?

The description is lengthy but well-structured with bullet points and clear sections. It front-loads the purpose and uses concise language. Every sentence adds value, though some redundancy (e.g., repeating the tier descriptions) could be trimmed. Overall, it is appropriately detailed without being rambling.

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?

Given the tool's complexity (simulation with multiple parameters, no output schema), the description is remarkably complete. It explains what the tool computes (total coverage, cost, max safe redemption), describes the liquidity waterfall in detail, and provides usage guidance. No gaps are apparent.

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?

Schema description coverage is 100%, so baseline is 3. The tool description adds significant context beyond the schema for the verify_onchain parameter, explaining its effect, caching, and behavior on failure. For other parameters, the schema descriptions are sufficient, but the overall description provides a richer understanding of how parameters interact in the simulation.

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 clearly states the tool's purpose: 'Simulate a large redemption on a MetaVault to assess withdrawal liquidity.' It uses a specific verb ('simulate') and resource ('large redemption on MetaVault'), and differentiates from sibling tools by mentioning related tools like spectra_get_curator_dashboard and spectra_get_pool_capacity.

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?

The description provides explicit guidance on when to use this tool: 'Use spectra_get_curator_dashboard for operational overview before stress testing.' It also lists alternatives for other tasks, such as spectra_get_pool_capacity and morpho_monitor_risk. Additionally, it highlights the ERC-7540 constraint, making the importance of pre-stress liquidity checks clear.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Finanzgoblin/spectra-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server