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

Sky sUSDS Continuous RAY Leveraged Carry Simulator

simulate_sky_susds_leveraged_carry
Read-onlyIdempotent

Simulates leveraged sUSDS/USDC carry loops on Morpho to estimate return on equity and breakeven USDC borrow rate using Sky ssr/chi compounding.

Instructions

Use this tool when a user asks about Sky Protocol (MakerDAO) sUSDS savings rate, continuous per-second RAY compounding (ssr and chi), or wants to calculate leveraged sUSDS/USDC loop ROE and breakeven borrow rates on Morpho.

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_sky_susds_leveraged_carry"
  }
}

Input Schema

NameRequiredDescriptionDefault
leverageNoTarget loop leverage multiplier (default: 5)
borrowRateOverrideNoOptional manual USDC borrow APY override in percent (e.g. 6.5)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.7

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that compounding is continuous per-second via ssr/chi and that borrow rates come from Morpho, which helps. It says nothing about whether rates are fetched live versus assumed, what fees/gas/slippage assumptions apply, or what the simulation reports, which are the traits that matter for a simulator.

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?

A single front-loaded sentence that leads with the trigger condition, then enumerates the covered concepts. No filler, though the parenthetical alias and backticked identifiers make it dense on first read.

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 return-value and modeling-assumption context. It hints at the return values (loop ROE, breakeven borrow rate) but omits whether live on-chain rates are queried under openWorldHint, and what defaults/assumptions (fees, gas, entry slippage, rate source) shape the numbers. Adequate to select the tool, thin for interpreting results.

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 description coverage is 100%, with both parameters documented (leverage default 5, bounds 1-10; optional USDC borrow APY override). The description adds only implied context - that the override relates to Morpho borrow rates - and no syntax or interaction detail. Baseline 3 applies when the schema already carries the parameter meaning.

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?

The description names a specific subject domain: Sky/MakerDAO sUSDS savings rate, RAY per-second compounding (ssr/chi), and leveraged sUSDS/USDC loop ROE with breakeven borrow rates on Morpho. This is concrete enough to distinguish it from siblings, which cover different protocols (Morpho Blue kink slippage, Ethena sUSDe, Pendle, Euler, Fluid). It stops short of stating the exact output shape, but the analytical purpose is unambiguous.

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?

It opens with an explicit trigger: 'Use this tool when a user asks about Sky Protocol (MakerDAO) sUSDS savings rate...'. That is clear when-to-use guidance tied to user intent. It gives no when-not conditions or named alternatives, but the sibling set is separated by protocol, so the routing risk is low.

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