Verifiable, deterministic risk math for autonomous agents; re-runnable proof on every answer.
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.
Average 4.5/5 across 9 of 9 tools scored.
Each tool addresses a distinct risk domain (event volatility, execution verification, LP risk, options, perps, portfolio, attestation, sizing, treasury) with no overlap; descriptions are precise and differentiate clearly.
All tool names follow a consistent snake_case pattern combining a domain prefix with a verb or metaphor (e.g., _risk, _gate, _verify), making them predictable and easy to parse.
The 9 tools cover a broad range of DeFi risk computations without being excessive; each tool serves a clear, non-redundant purpose within the server's scope.
The tool set provides comprehensive coverage for a risk analysis server: event risk, execution quality, LP risk, options and perps greeks, portfolio stress, attestation, sizing, and treasury risk; no obvious gaps for the intended domain.
event_volEvent Implied-MoveAOptions-implied expected move around a scheduled event (FOMC/CPI/earnings/etc.). Given spot, ATM implied vol, and days-to-event, returns the 1σ move, the straddle-implied expected ABSOLUTE move (risk-neutral E|ΔS|), and the probability of exceeding move thresholds. Given the vol term structure across the event (ATM IV of the expiry before vs after), it ISOLATES the event's own priced-in move (the Wright event-day technique). Self-checked: the straddle equals a numerical integral of |S_T−S₀|. This is the magnitude that macro calendars (which give only date + impact label) leave out.
| Name | Required | Description | Default |
|---|---|---|---|
| T | No | years (or daysToEvent) | |
| spot | Yes | current spot price | |
| atmIv | No | ATM IV as a decimal (alternative to atmIvPct) | |
| atmIvPct | No | ATM IV in % (or atmIv decimal) | |
| daysAfter | No | days to the after-event expiry | |
| daysBefore | No | days to the before-event expiry | |
| ivAfterPct | No | ATM IV (%) of the expiry just AFTER the event | |
| daysToEvent | No | days until the event | |
| ivBeforePct | No | ATM IV (%) of the expiry just BEFORE the event | |
| thresholdsPct | No | move thresholds (%) for probability-of-exceeding |
| Name | Required | Description |
|---|---|---|
| ok | No | false when the engine rejected the input |
| spot | No | spot the computation is anchored on |
| proof | No | Verifiability envelope: echoed inputs, engine codeHash, contentHash of this exact result, self-checks, EIP-712 signature (EAS-ready). Re-run the open engine on `inputs` to reproduce the result byte-for-byte. |
| checks | No | Ground-truth self-checks; the result is untrustworthy if any fails. |
| method | No | technique + assumptions used |
| atmIvPct | No | ATM IV used (%) |
| horizonDays | No | horizon in days |
| expectedMove | No | 1σ move + straddle-implied expected |ΔS| (risk-neutral) |
| eventIsolation | No | the event's own priced-in move, isolated from the term structure (when before/after IVs are given) |
| probabilityMoveBeyond | No | probability of exceeding each move threshold |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is safe and non-modifying. The description adds internal details: the straddle is 'self-checked' via numerical integral, and it uses the Wright event-day technique. No contradiction; the description enriches transparency.
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 well-structured and front-loaded with the main purpose. It uses sentences efficiently, though it is slightly lengthy due to technical details. Every sentence adds value, so it 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 complexity (10 params, output schema present), the description covers the core use cases and key parameters. It does not detail the output schema but that is available separately. The description is complete enough for an agent to select and invoke 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%, so baseline is 3. The description adds meaning by explaining relationships (e.g., 'alternative to atmIvPct', grouping daysBefore/daysAfter with ivBeforePct/ivAfterPct for isolation). It also clarifies that thresholdsPct is for probability-of-exceeding.
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 computes 'options-implied expected move around a scheduled event' and lists specific outputs (1σ move, straddle-implied move, probability of exceeding thresholds). It distinguishes itself from macros that 'give only date + impact label', clarifying its unique value.
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 specifies suitable events (FOMC/CPI/earnings) and what the tool provides that others lack (isolated event move, risk-neutral absolute move). It implies when to use (event analysis) but does not explicitly exclude scenarios where it would be inappropriate. Still clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
exec_verifyExecution-Quality VerifierADeterministic execution-quality / fair-fill verification. Given a completed swap (amountIn, amountOutRealized) plus either the pre-trade pool reserves+fee (constant-product) or a fair reference price, returns how many basis points the fill lost to ADVERSE execution (sandwich/MEV/stale) beyond the unavoidable fee + own price impact. Proves that a fill "within slippage tolerance" can still have been robbed. Call after a swap to detect being sandwiched.
| Name | Required | Description | Default |
|---|---|---|---|
| feeTier | No | pool fee as fraction, e.g. 0.003 | |
| amountIn | Yes | input amount actually sent | |
| fairPrice | No | reference mode: fair out-per-in price at submit time | |
| reserveIn | No | pool reserve of input token, pre-trade (constant-product mode) | |
| reserveOut | No | pool reserve of output token, pre-trade | |
| amountOutRealized | Yes | output amount actually received | |
| slippageTolerancePct | No | the slippage setting used, to demonstrate within-tolerance-yet-robbed |
| Name | Required | Description |
|---|---|---|
| ok | No | false when the engine rejected the input |
| mode | No | constant-product or reference-price mode |
| note | No | interpretation guidance |
| proof | No | Verifiability envelope: echoed inputs, engine codeHash, contentHash of this exact result, self-checks, EIP-712 signature (EAS-ready). Re-run the open engine on `inputs` to reproduce the result byte-for-byte. |
| checks | No | Ground-truth self-checks; the result is untrustworthy if any fails. |
| verdict | No | plain-language verdict |
| midPrice | No | pre-trade mid price |
| honestOut | No | output an honest execution would have delivered |
| adverseValueOut | No | value lost to adverse execution, in output-token units |
| honestFillPrice | No | the fill price an honest execution would have produced |
| realizedFillPrice | No | the fill price actually received |
| unavoidableCostBps | No | fee + own price impact — the honest, unavoidable cost (bps) |
| adverseExecutionBps | No | bps lost to ADVERSE execution beyond the honest cost |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool is deterministic, describes what it computes (basis points lost to adverse execution), and emphasizes it proves 'within slippage tolerance can still have been robbed'. This provides useful behavioral 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 concise, front-loaded with the core purpose, and each sentence adds value. It avoids redundancy and stays within a few sentences.
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 complexity (7 parameters, 2 required, output schema exists), the description covers what the tool does, when to call it, the two input modes, and the output interpretation. It is complete enough for an agent to understand and invoke 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 coverage is 100%, so baseline is 3. The description groups parameters into input modes (amountIn, amountOutRealized plus either reserves+fee or fairPrice) but does not add new semantics beyond the schema's descriptions. It does not compensate for any gaps.
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 is a 'Deterministic execution-quality / fair-fill verification' tool that detects adverse execution (sandwich/MEV/stale) beyond unavoidable fee and price impact. It uses specific verbs and resources, and its purpose is distinct from sibling tools like risk gates or volume analytics.
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 says 'Call after a swap to detect being sandwiched' and explains the two input modes (pre-trade reserves+fee or fair reference price). It also warns that within-slippage fills can still be robbed. It could be stronger by explicitly stating when not to use it or listing alternatives, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lp_riskLP Divergence-Loss GateAForward-looking liquidity-provision risk. Given a realized price ratio (for impermanent loss) and/or a volatility + horizon (for expected divergence / LVR), returns the closed-form IL, the expected −σ²T/8 divergence, and — with a fee APR — the net forecast and breakeven volatility (the vol above which fees no longer cover the bleed). Self-checked: the IL closed form is verified at the token level against explicit constant-product amounts. Call before providing liquidity to see whether the fee yield can plausibly beat the divergence loss.
| Name | Required | Description | Default |
|---|---|---|---|
| feeAprPct | No | annualized fee yield estimate | |
| capitalUsd | No | position capital in USD — losses are also reported in USD | |
| priceRatio | No | realized P1/P0 for realized IL | |
| volatility | No | per-period vol (decimal) for expected divergence | |
| horizonPeriods | No | periods (default 1) | |
| periodsPerYear | No | default 365 | |
| concentrationFactor | No | V3 amplifier ≥1 (default 1) |
| Name | Required | Description |
|---|---|---|
| ok | No | false when the engine rejected the input |
| model | No | model assumptions used |
| proof | No | Verifiability envelope: echoed inputs, engine codeHash, contentHash of this exact result, self-checks, EIP-712 signature (EAS-ready). Re-run the open engine on `inputs` to reproduce the result byte-for-byte. |
| checks | No | Ground-truth self-checks; the result is untrustworthy if any fails. |
| realizedIL | No | closed-form impermanent loss at the realized price ratio |
| feeVsDivergence | No | net forecast and breakeven volatility vs the fee APR |
| expectedDivergence | No | expected divergence loss / LVR over the horizon (−σ²T/8 law) |
| concentrationFactor | No | V3 concentration amplifier applied |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), the description reveals computation behavior, self-verification ('Self-checked: the IL closed form is verified'), and output details. 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?
Every sentence contributes value: purpose, input/output list, verification note, usage recommendation. No wasted words; 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 tool with 7 parameters and an existing output schema, the description covers inputs, computation, verification, and usage. It is sufficiently complete for an agent to select and invoke 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 coverage is 100%, but the description adds context linking parameters (e.g., 'capitalUsd' for USD loss reporting, 'priceRatio' for realized IL). It explains how parameters combine to produce outputs, enhancing schema 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 explicitly states the tool's purpose: 'Forward-looking liquidity-provision risk.' It details inputs (price ratio, volatility/horizon) and outputs (IL, divergence, net forecast, breakeven volatility), and distinguishes itself from sibling tools by focusing on pre-liquidity assessment.
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 clear guidance: 'Call before providing liquidity to see whether the fee yield can plausibly beat the divergence loss.' It implies appropriate context but does not explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
options_riskOptions Book Risk (Greeks + SPAN)APortfolio greeks (delta/gamma/vega/theta/vanna/volga) + SPAN-style scenario margin for an options book on Black-76. Given a list of legs {type, strike, expiryDays, iv, quantity(signed)} and a forward, returns aggregate greeks, first-order P&L per underlying move, and the worst-case loss over a price×vol grid. Self-checked: analytic greeks are verified against finite-difference derivatives of the repriced book. Call to size an options book's true net risk and margin — not the sum of per-leg notionals.
| Name | Required | Description | Default |
|---|---|---|---|
| r | No | discount rate, default 0 | |
| forward | No | shared forward price (or set per position) | |
| positions | Yes | option legs of the book | |
| scanRangePct | No | SPAN price scan range, default 0.15 | |
| volShiftVolPts | No | SPAN vol shift in vol-points, default 10 |
| Name | Required | Description |
|---|---|---|
| ok | No | false when the engine rejected the input |
| model | No | Black-76 assumptions used |
| proof | No | Verifiability envelope: echoed inputs, engine codeHash, contentHash of this exact result, self-checks, EIP-712 signature (EAS-ready). Re-run the open engine on `inputs` to reproduce the result byte-for-byte. |
| checks | No | Ground-truth self-checks; the result is untrustworthy if any fails. |
| greeks | No | aggregate delta/gamma/vega/theta/vanna/volga — each verified vs finite differences |
| positions | No | per-leg pricing breakdown |
| spanMargin | No | worst-case loss over the price×vol scenario grid (SPAN-style margin) |
| portfolioValue | No | mark-to-model value of the book |
| positionsCount | No | number of legs priced |
| pnlPerUnderlyingPctMove | No | first-order P&L per % move of the underlying |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, idempotent, non-destructive. The description adds that it is self-checked against finite differences, providing extra behavioral context beyond 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 concise paragraph of four sentences, front-loading the main purpose without superfluous 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 the output schema exists, the description sufficiently covers inputs, outputs (greeks, P&L, worst-case loss), and purpose, making it complete for an agent.
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 100% schema coverage, baseline is 3. The description summarizes input fields but does not add significant new meaning beyond 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 it computes portfolio greeks and SPAN-style margin for an options book using Black-76, and explicitly contrasts with per-leg notionals. It is specific and distinct from sibling 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?
The description advises calling to size true net risk and margin, not sum of notionals, implying when to use. However, it does not explicitly discuss alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
perp_gatePerp Liquidation GateADeterministic perpetual-futures risk. Given a position (entry, size, margin/leverage, maint-margin/maxLeverage), returns the exact liquidation price, the % adverse move to liquidation, effective leverage, and (if a funding rate is given) the funding drag. Pass a Hyperliquid symbol (e.g. BTC) to auto-fill live mark price, funding, and max leverage. Includes a self-check proving the liquidation invariant. Call this BEFORE opening or sizing any leveraged perp position — an agent that knows its true liquidation distance does not get surprise-liquidated.
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | long | short (buy | sell are accepted synonyms, as is -1 for short); default long | |
| size | No | position size in base units (or pass notional) | |
| venue | No | live-data venue (default hyperliquid). The maths is venue-agnostic — for any other venue omit this and pass maxLeverage/markPrice/fundingRateHourly yourself. | |
| margin | No | isolated margin posted (or pass leverage) | |
| symbol | No | perp symbol (e.g. BTC) — auto-fills live markPrice, fundingRateHourly, and the margin source (Hyperliquid notional tiers or dYdX maintenance rate); also defaults entryPrice to the live mark | |
| leverage | No | position leverage (alternative to margin) | |
| notional | No | position notional in quote/USD | |
| markPrice | No | current mark; distance-to-liq measured from here | |
| entryPrice | No | defaults to live mark if a symbol is given | |
| maxLeverage | No | venue max leverage for the asset | |
| horizonHours | No | horizon for the funding-drag estimate, in hours | |
| maintMarginRate | No | e.g. 0.0125; or pass maxLeverage (mmr = 0.5/maxLeverage) | |
| fundingRateHourly | No | hourly funding rate (Hyperliquid funds hourly) |
| Name | Required | Description |
|---|---|---|
| ok | No | false when the engine rejected the input |
| model | No | model assumptions used |
| proof | No | Verifiability envelope: echoed inputs, engine codeHash, contentHash of this exact result, self-checks, EIP-712 signature (EAS-ready). Re-run the open engine on `inputs` to reproduce the result byte-for-byte. |
| checks | No | Ground-truth self-checks; the result is untrustworthy if any fails. |
| funding | No | funding drag over the horizon (when a funding rate is given) |
| marginTier | No | venue margin tier the notional falls into |
| liquidationPrice | No | exact price at which the position liquidates |
| effectiveLeverage | No | notional / margin actually run |
| initialMarginRatePct | No | initial margin rate applied (%) |
| moveToLiquidationPct | No | adverse % move (from mark) that triggers liquidation |
| maintenanceMarginRatePct | No | maintenance margin rate applied (%) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. Description adds value by noting the self-check, deterministic nature, and live data dependency, enhancing transparency without contradiction.
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 paragraph of ~100 words, front-loaded with key outputs and usage direction. Every sentence serves a purpose—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 13 parameters with no required ones, the description fully covers usage modes (live vs manual), venue agnosticism, and includes a self-check. The output schema exists, but description still summarizes key outputs.
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?
All 13 parameters have descriptions in the schema (100% coverage). The description goes beyond by explaining parameter groups and relationships (e.g., symbol auto-fills markPrice, funding, maxLeverage; margin vs leverage alternatives; venue-agnostic math).
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 computes perpetual-futures risk metrics (liquidation price, adverse move, effective leverage, funding drag) and explicitly distinguishes itself as a pre-trade risk check for perp positions, differentiating from sibling tools like options_risk or portfolio_gate.
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 guidance: 'Call this BEFORE opening or sizing any leveraged perp position' and explains how to use live data (pass symbol) or manual values. Does not explicitly list when not to use, 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.
portfolio_gateCross-Venue Portfolio GateACross-venue portfolio risk. Given positions across venues [{venue, asset|symbol, side, size, entryPrice, margin|leverage, maxLeverage|marginTiers}] — OR just account: a Hyperliquid 0x address, whose FULL live book (positions, margins, account equity, the venue's own liquidation prices) is pulled keylessly — returns TRUE net exposure per underlying, the leg that liquidates FIRST (the binding constraint), concentration (HHI / effective independent bets), and a correlated-crash stress counting how many legs liquidate SIMULTANEOUSLY when the market moves ±X% (correlation→1, the Oct-10-2025 crash regime). Pass Hyperliquid symbols to auto-fill live mark/leverage/margin-tiers. Self-checked (exposure reconciliation, per-leg liquidation invariant, nearest=min, monotone stress, venue-liquidation cross-check). Call to see whether independently-sized bets are secretly ONE bet that blows up together.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | OR: a Hyperliquid account address (0x…) — the full live book (positions, margins, equity, venue liquidation prices) is pulled keylessly; explicit positions take precedence. | |
| betaTier | No | beta regime for the factor stress: mild | moderate | severe — cross-event validated tiers (pre-registered). Default = worst-case single-event table; explicit betas override. | |
| positions | No | legs: {venue, asset|symbol, side long|short, size, entryPrice, markPrice?, margin|leverage, maxLeverage|maintMarginRate|marginTiers}. A Hyperliquid symbol auto-fills live mark/leverage/tiers. | |
| shockScenariosPct | No | correlated market moves (%) to stress; default [5,10,20,30] |
| Name | Required | Description |
|---|---|---|
| ok | No | false when the engine rejected the input |
| model | No | model assumptions used |
| proof | No | Verifiability envelope: echoed inputs, engine codeHash, contentHash of this exact result, self-checks, EIP-712 signature (EAS-ready). Re-run the open engine on `inputs` to reproduce the result byte-for-byte. |
| checks | No | Ground-truth self-checks; the result is untrustworthy if any fails. |
| positions | No | per-leg breakdown with each liquidation price |
| concentration | No | HHI + effective number of independent bets |
| positionsCount | No | number of legs analyzed |
| totalNetNotional | No | net notional after long/short netting |
| nearestLiquidation | No | the leg that liquidates FIRST — the binding constraint |
| netExposureByAsset | No | TRUE net exposure per underlying (longs netted against shorts) |
| totalGrossNotional | No | sum of |notional| across legs |
| correlatedShockStress | No | per-scenario: how many legs liquidate simultaneously at a correlated ±X% move |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description discloses self-checks (exposure reconciliation, liquidation invariants), auto-filling of live data, and the correlated-crash stress methodology. No contradictions.
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?
Description is somewhat long but front-loaded with purpose. Each sentence adds necessary detail about functionality, self-checks, and parameters. Could be slightly more structured, but efficient given 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?
Given the tool's complexity (cross-venue, stress testing, multiple inputs), the description fully covers purpose, inputs, behavior, and output characteristics. Output schema exists, so return values are documented separately.
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 coverage is 100%, baseline 3. Description adds value by explaining the positions array format, account behavior (keyless live pull), betaTier meaning, and default shock scenarios, enriching the schema descriptions.
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 evaluates cross-venue portfolio risk, returning net exposure, first-to-liquidate leg, concentration, and crash stress. It distinguishes from siblings like perp_gate or options_risk by focusing on multi-venue aggregation.
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 usage context: call to check if independent bets are secretly one correlated position. Explains how to input a Hyperliquid address or explicit positions. Does not explicitly list when not to use or compare to alternatives, but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
risk_attestMerkle Batch AttestationABatch the content-hashes from many Quiver proof envelopes into ONE Merkle root plus per-item inclusion proofs, so a single on-chain anchor (your wallet's tx) attests all of them at once. Self-checked for completeness (every item verifies) and soundness (a non-member does not). Use to make a batch of risk computations cheaply and permanently attestable for audit/liability, without a chain write per computation.
| Name | Required | Description | Default |
|---|---|---|---|
| items | No | proof envelopes (uses proof.contentHash) or raw content-hashes (hex) | |
| contentHashes | No | alternatively, raw content-hashes |
| Name | Required | Description |
|---|---|---|
| ok | No | false when the engine rejected the input |
| proof | No | Verifiability envelope: echoed inputs, engine codeHash, contentHash of this exact result, self-checks, EIP-712 signature (EAS-ready). Re-run the open engine on `inputs` to reproduce the result byte-for-byte. |
| anchor | No | EIP-712 (EAS-ready) attestation payload for the single on-chain anchor |
| checks | No | Ground-truth self-checks; the result is untrustworthy if any fails. |
| verify | No | how to verify inclusion against the root |
| algorithm | No | hash/tree construction used |
| leafCount | No | number of items batched |
| merkleRoot | No | the single root that attests every item |
| attestations | No | per-item inclusion proofs |
| duplicateLeaves | No | duplicate content-hashes detected in the batch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable context: self-checking for completeness and soundness, and the process of creating a single on-chain anchor. No contradictions 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 compact (two sentences) with no wasted words. It front-loads the main action and outcome, and efficiently covers inputs, process, and benefits.
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 complexity of Merkle batch attestation, the description adequately explains inputs, the process (batching, self-check), output (root and proofs), and use case. The presence of an output schema further fills in details.
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 coverage is 100%, so baseline is 3. The description adds meaning by explaining that 'items' use proof.contentHash and 'contentHashes' are raw hex alternatives, providing usage context beyond the parameter descriptions.
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 batches content-hashes into a Merkle root with inclusion proofs for on-chain attestation. It uses specific verbs ('batch') and resources ('content-hashes from Quiver proof envelopes'), and the purpose is well-differentiated from sibling tools that handle different risk operations.
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 usage: 'Use to make a batch of risk computations cheaply and permanently attestable for audit/liability'. While it does not mention when not to use or alternatives, the context from sibling tools implies it is for attestation, not for other risk tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
size_gateKelly Size GateADeterministic position sizing (fractional Kelly) + risk-of-ruin. Given an edge — discrete {winProb, winLossRatio} or continuous {expectedReturn, volatility} — and a bankroll, returns the fractional-Kelly size and the probability of ever drawing down to 50/75/90%. The direct antidote to over-betting: full Kelly rides thin edges to ruin; this defaults to quarter-Kelly. Call before sizing ANY position.
| Name | Required | Description | Default |
|---|---|---|---|
| winProb | No | discrete mode: win probability in (0,1) | |
| bankroll | No | bankroll in account units — recommended sizes are returned in the same units | |
| volatility | No | continuous mode: volatility per period (sigma) | |
| winLossRatio | No | discrete mode: net win/loss odds b | |
| kellyFraction | No | fraction of full Kelly to bet (default 0.25) | |
| expectedReturn | No | continuous mode: excess return per period (mu) |
| Name | Required | Description |
|---|---|---|
| ok | No | false when the engine rejected the input |
| mode | No | discrete or continuous |
| note | No | plain-language guidance |
| model | No | model assumptions used |
| proof | No | Verifiability envelope: echoed inputs, engine codeHash, contentHash of this exact result, self-checks, EIP-712 signature (EAS-ready). Re-run the open engine on `inputs` to reproduce the result byte-for-byte. |
| checks | No | Ground-truth self-checks; the result is untrustworthy if any fails. |
| hasEdge | No | false when the edge is non-positive (bet nothing) |
| leverage | No | implied leverage of the recommended size |
| riskOfRuin | No | probability of ever drawing down to 50/75/90% of bankroll |
| recommendedSize | No | recommended bet size in bankroll units |
| expectedLogGrowth | No | expected log-growth rate at the recommended size |
| fullKellyFraction | No | full-Kelly fraction of bankroll (the ruinous ceiling, not the recommendation) |
| kellyFractionUsed | No | fraction of full Kelly applied (default 0.25) |
| impliedPortfolioVolPct | No | portfolio volatility implied by the recommended size (%) |
| recommendedBetFraction | No | recommended bet as a fraction of bankroll |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it notes determinism, the fractional-Kelly approach, default quarter-Kelly, and drawdown thresholds (50/75/90%). Annotations already indicate read-only and idempotent, which are consistent. The description provides useful behavioral warnings (e.g., full Kelly rides thin edges to ruin).
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 long, front-loading the core purpose and key outputs. Every sentence adds critical information: what it does, inputs, outputs, and usage advisory. There is no wasted text.
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 complexity (6 parameters, output schema present), the description covers the essential behavioral and usage context. It mentions specific drawdown probabilities and the default fraction, which aids completeness. The output schema likely details return format, so the description is adequately comprehensive.
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%, so baseline is 3. The description adds value by explaining the two input modes (discrete: winProb+winLossRatio, continuous: expectedReturn+volatility) and the role of kellyFraction default. This helps agents understand parameter groupings beyond the individual descriptions.
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 performs deterministic position sizing using fractional Kelly and risk-of-ruin analysis. It specifies the input modes (discrete vs continuous) and outputs (fractional-Kelly size and drawdown probabilities), and distinguishes itself as an antidote to over-betting. This is specific and differentiates from sibling 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?
The description explicitly says 'Call before sizing ANY position' and positions the tool as a direct antidote to over-betting, implying its primary use case. While it doesn't list when not to use or compare to alternatives explicitly, the context is clear enough for an AI agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
treasury_riskTreasury Depeg & ConcentrationAStablecoin / on-chain treasury risk. Given a book of positions [{asset, amountUsd, apyPct, venue, chain, pegTarget, depegProbAnnual}], returns concentration (Herfindahl by asset/venue/chain + breaches over a limit), depeg stress (explicit scenarios + a worst-single-depeg scan), weighted and risk-adjusted yield. Self-checked: HHI == Σw², weights sum to 1, depeg-loss identity. Call to size a treasury's real risk — issuer/venue/chain concentration and depeg exposure — not just its headline APY.
| Name | Required | Description | Default |
|---|---|---|---|
| positions | Yes | treasury holdings | |
| depegFloor | No | worst-single-depeg stress floor (default 0.90) | |
| depegScenarios | No | [{asset, price}] explicit depeg stresses | |
| concentrationLimitPct | No | flag any single exposure above this (default 25) |
| Name | Required | Description |
|---|---|---|
| ok | No | false when the engine rejected the input |
| model | No | model assumptions used |
| proof | No | Verifiability envelope: echoed inputs, engine codeHash, contentHash of this exact result, self-checks, EIP-712 signature (EAS-ready). Re-run the open engine on `inputs` to reproduce the result byte-for-byte. |
| checks | No | Ground-truth self-checks; the result is untrustworthy if any fails. |
| verdict | No | plain-language verdict |
| totalUsd | No | total treasury size in USD |
| depegStress | No | explicit depeg scenarios + worst-single-depeg scan |
| concentration | No | Herfindahl (HHI) by asset/venue/chain + limit breaches |
| weightedApyPct | No | holdings-weighted headline APY (%) |
| riskAdjustedApyPct | No | yield after expected depeg loss (%) |
| expectedAnnualDepegLossUsd | No | expected annual loss from depeg probabilities (USD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by disclosing internal consistency checks (HHI identity, weight sum, depeg-loss identity) and the worst-single-depeg scan. This goes beyond what annotations provide, though it could detail rate limits or auth needs.
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 clear front-loading: first sentence defines inputs and outputs, second adds self-check and a usage call. It is efficient and well-structured, though slightly dense; a minor split could improve readability.
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 presence of an output schema, the description sufficiently covers the tool's functionality: concentration, depeg stress, risk-adjusted yield. It mentions explicit scenarios and worst-single-depeg scan. It does not detail all output fields or edge cases, but the output schema compensates.
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% (all parameters described). The description adds context by explaining how parameters like positions and depegScenarios feed into the computation: 'returns concentration... depeg stress... weighted and risk-adjusted yield.' This clarifies the role of each parameter beyond schema definitions.
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: assessing stablecoin/treasury risk. It specifies the input format (positions with fields) and outputs (concentration, depeg stress, adjusted yield). This distinguishes it from sibling tools like event_vol or lp_risk by focusing on treasury concentration and depeg exposure.
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 tells when to use the tool: 'Call to size a treasury's real risk — issuer/venue/chain concentration and depeg exposure — not just its headline APY.' This contrasts with simpler yield tools. However, it does not explicitly mention when not to use or name specific alternatives, so a perfect score is not warranted.
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.
No comments yet. Be the first to start the discussion!