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

Morpho Blue 90% Kink & Borrow Slippage Simulator

simulate_morpho_blue_kink_slippage
Read-onlyIdempotent

Simulate a large Morpho Blue borrow or loop position to estimate how it pushes utilization past the 90% AdaptiveCurveIRM kink and raises post-trade borrow APY.

Instructions

Use this tool when a user wants to check Morpho Blue borrow rates, market utilization, or simulate how a large borrow or loop position will impact the 90% AdaptiveCurveIRM kink and push up post-trade borrow APY.

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

Input Schema

NameRequiredDescriptionDefault
marketIdNo32-byte Morpho Blue market ID hex (defaults to flagship wstETH/USDC market)
simBorrowDeltaNoSimulated additional borrow amount in loan token units (default: 2000000)

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, destructiveHint=false, and openWorldHint=true, so safety and side-effect profile are covered structurally. The description adds the useful fact that the computation centers on the 90% kink and post-trade APY, but says nothing about data freshness (live on-chain read vs cached), behavior for invalid market IDs, or whether a single call returns both pre- and post-trade values.

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 usage trigger and then the domain specifics, with no filler or repetition. Slightly dense with three comma-separated use cases, but nothing is wasted.

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?

With only two fully documented optional parameters and no output schema, the definition is close to sufficient. The remaining gap is the return shape: the agent cannot tell whether the response includes current utilization, current APY, post-trade APY, and kink distance, or just a single slippage number, which matters for a simulation tool whose whole value is the projected figure.

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 marketId and simBorrowDelta fully documented including defaults, so the schema carries the parameter burden. The description's phrase 'large borrow or loop position' loosely frames simBorrowDelta as a stress-scenario input rather than a routine amount, which is a mild addition beyond the schema's neutral wording, but it adds no units, bounds, or interpretation guidance.

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 protocol (Morpho Blue), a specific mechanism (the 90% AdaptiveCurveIRM kink), and a specific computation (post-trade borrow APY impact of a large borrow). It is clearly distinct from every sibling, which each target a different protocol. It loses a point because it bundles three loosely related capabilities ('check borrow rates', 'market utilization', 'simulate impact') without clarifying whether the tool returns current state, a projection, or both.

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?

The trigger is stated explicitly with a 'Use this tool when a user wants to...' clause covering borrow-rate checks, utilization queries, and large-borrow/loop simulation. No alternatives or when-not conditions are given, but no sibling overlaps on Morpho Blue, 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