Skip to main content
Glama
Sign In
DeFi Quant Multi-Protocol Yield & Risk API

DeFi Quant Multi-Protocol Yield & Risk API

by Pyrochem
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Ethena sUSDe Vesting & Whale Dilution Simulator

simulate_ethena_susde_vesting_dilution
Read-onlyIdempotent

Simulate a new USDe deposit into Ethena sUSDe staking to estimate APY dilution from unvested 8-hour epoch rewards and support pre-trade yield risk decisions.

Instructions

Use this tool when a user asks about Ethena sUSDe real-time APY, 8-hour epoch reward vesting (getUnvestedAmount), or how a large whale deposit into the sUSDe staking contract will dilute the current yield.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "simulate_ethena_susde_vesting_dilution"
  }
}

Input Schema

NameRequiredDescriptionDefault
simDepositUSDeNoSimulated new USDe deposit size to test APY dilution (default: 25000000)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.7

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered without description help. The description adds the substantive behavioral detail that the simulation is scoped to a single 8-hour vesting epoch and current yield dilution. It stops short of clarifying whether the result is derived from live onchain state or a hypothetical model, and does not describe the returned shape.

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

Conciseness5/5

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

A single sentence, front-loaded with the activation condition and packing three concrete capability hooks. Nothing is wasted and nothing needs trimming.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must carry the return-value burden for a fairly involved simulation (epoch vesting plus dilution math), and it does not describe what comes back or in what units. For a one-parameter read-only simulator that is a modest gap rather than a blocking one, but the definition is not self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the sole parameter's description already explains it as a simulated deposit size for testing APY dilution, including the 25M default. The description's 'large whale deposit' and 'dilute the current yield' phrasing reinforces the same meaning but adds no units, magnitude guidance, or interaction detail beyond the schema. Baseline 3 is correct where the schema carries the semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names the specific resources and mechanics it covers: Ethena sUSDe real-time APY, 8-hour epoch reward vesting via `getUnvestedAmount`, and whale-deposit dilution. The verb is implicit ('simulate' from the name) since the sentence is framed as a trigger condition rather than 'this tool computes X', but an agent can still tell what it returns. Sibling tools target entirely different protocols, so no further disambiguation is needed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the trigger: 'Use this tool when a user asks about...' and enumerates three query types that map to its capabilities. It does not state when-not to use it or name an alternative, but the sibling set is protocol-specific so there is no realistic ambiguity to resolve.

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

Deploy Server

Other Tools