Real-time risk-weighted USDC lending APY across Aave, Compound, Morpho, Moonwell, Euler and Fluid on Base. Every reading tagged with its data source (onchain/api/defillama). Pay-per-call via x402, $0.01 USDC, 3 free calls/day.
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.4/5 across 5 of 5 tools scored.
Each tool targets a distinct analytical question (current yield, sustainability, decision, rate sensitivity, exit liquidity). The descriptions are detailed and clearly separate the tools, though get_exit_capacity and get_rate_sensitivity both involve utilization and could be superficially confused by an agent.
All tools follow a consistent 'get_' verb-noun pattern, with descriptive nouns like 'yield_signal', 'yield_durability', 'yield_decision', 'rate_sensitivity', and 'exit_capacity'. The pattern is predictable and readable.
Five tools is well-scoped for a specialized yield analytics server. Each tool earns its place by covering a distinct aspect of yield assessment, avoiding bloat while providing sufficient functionality.
The set covers the core yield analysis lifecycle: signal, durability, decision, rate sensitivity, and exit capacity. Minor gaps exist, such as no explicit tool for historical comparisons or protocol discovery, but the described tools handle the main workflows.
get_exit_capacityAInspectExit capacity for a Base lending market: per-protocol utilization and withdrawable liquidity read from the protocol's own books (Aave, Compound), plus — if you pass amountUsd — whether that size can be withdrawn right now and what share of the market it would be. High APY at high utilization means the market pays well and will not let you out; this tool separates the two. Protocols that do not expose borrowed-vs-supplied are marked unmeasured and are never recommended as executable. USDC only for USD figures; WETH returns utilization without USD (no price oracle in the paid path).
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Which Base lending market to measure: USDC (full USD figures) or WETH (utilization only). Defaults to USDC. | |
| amountUsd | No | Position size in USD to test for exit. Omit to get utilization and free liquidity without an exit verdict. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: it discloses the data source (protocol's own books), the optional exit verdict via amountUsd, limitations for WETH (no USD price oracle), and handling of unmeasured protocols. This is rich behavioral context.
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 dense but front-loaded with the core purpose. Every sentence contributes value, covering asset differences and limitations. Slightly long but not wasteful.
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 no output schema and no annotations, this description provides a complete picture: what the tool does, how parameters affect behavior, key limitations (asset-specific, price oracle), and how it relates to yield concerns. It is sufficient for an AI agent to select and invoke this tool 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?
Although schema coverage is 100%, the description adds significant meaning: amountUsd is explained as testing withdrawal feasibility and market share, and asset differences between USDC and WETH are clarified beyond the enum 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's function: measuring exit capacity (utilization and withdrawable liquidity) for a Base lending market. It distinguishes itself from yield-focused sibling tools by focusing on exit capacity and separating it from APY.
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 implies usage context: it helps when high APY at high utilization needs to be separated from actual exit capacity. It also notes that unmeasured protocols are never recommended, providing guidance on when not to rely on this tool. However, it doesn't explicitly name alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_leadership_persistenceAInspectHow long this service's own leadership calls actually hold, measured from its hourly on-chain attestations (EAS on Base). Returns the median duration a protocol stayed the best pick, survival rates at 6/24/72h, how much of the rotation is the same two protocols trading places, and what chasing the leader is worth per $10k before gas. Measured over 24 days: the WETH leader never changed once, the ETH staking leader changed every ~26h, the USDC leader every ~2h with half the switches being a round trip between the same pair — three assets sold at one price with wildly different reliability. Also answers, empirically, whether a wider lead lasts longer: it does not (Spearman -0.04 over 177 completed spells), so gap size is not a usable proxy for confidence. Every input is a public attestation UID: recompute it yourself from base.easscan.org and get the same number. Observed history with sample sizes attached, never a forecast — assets whose lead has not changed in the window are reported as a floor with a censoring flag, never as a median.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Which market's leadership durability to measure: USDC/WETH lending on Base, or ETH_STAKING liquid staking. Defaults to USDC. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to rely on, the description carries the full burden and excels: it discloses the data source (hourly EAS attestations on Base), the measurement window (24 days), statistical details (Spearman -0.04 over 177 spells), the censoring flag for unobserved lead changes, and that results are observed history, never forecasts. It also notes the outputs are recomputable from public attestation UIDs.
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 long but structured and information-dense; every sentence contributes meaningful context about methodology or return values. It is front-loaded with the core output, followed by empirical examples and caveats. Slightly verbose, but justified by the tool's analytical 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?
Even without an output schema, the description fully explains what results are returned (median duration, survival rates, rotation stats, chasing value), how they are computed, and important limitations (censoring, floor values, no forecasting). It also mentions sample sizes and verifiability, making it exceptionally complete for a complex analytical tool.
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% with the single enum parameter already described in the schema. The description adds illustrative examples of the three assets (WETH, ETH_STAKING, USDC) but does not provide additional parameter-level detail or syntax, so the baseline of 3 is appropriate.
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 states a specific verb+resource: it measures how long the service's own leadership calls actually hold, listing concrete outputs like median duration, survival rates at 6/24/72h, rotation stats, and value per $10k. It clearly distinguishes this persistence analysis from sibling tools that focus on exit capacity, rate sensitivity, shared exposure, etc.
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 context for when to use the tool, such as answering empirically whether a wider lead lasts longer and giving examples of asset-specific behavior. However, it does not explicitly name alternative tools or state when not to use it, stopping short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_rate_sensitivityAInspectHow close a Base lending market is to the kink where borrow rates explode. Returns, per protocol, the current utilization, the kink read from the protocol's own interest rate curve, the headroom in bps, and the borrow APY at points around the kink — plus how many times the borrow cost multiplies just past it. Measured on a live reading: Compound USDC sat 0.17 points below its kink, where borrow cost goes from ~4% to ~16%. Aave and Compound only: Morpho's adaptive IRM has no static curve to read and DefiLlama-sourced protocols expose none, so they are marked unmeasured and never assumed stable. Describes the current state of the curve, not a prediction that utilization will move.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Which Base lending market to stress-test: USDC or WETH. Defaults to USDC. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that this is a live reading, not a prediction, and clearly states that unmeasured protocols are 'marked unmeasured and never assumed stable.' It also details what metrics are returned and gives a concrete example (Compound USDC), adding transparency beyond the name and schema.
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 efficient: it opens with a purpose, explains the measured metrics, provides a concrete example, notes protocol limitations, and closes with a caveat. Each sentence earns its place, and the length matches the tool's complexity without unnecessary fluff.
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?
The description is remarkably complete given the tool's complexity. It defines the concept, lists all output metrics (utilization, kink, headroom, APY, multiplier), explains what is measured and what is not, gives a live example, and clarifies the non-predictive nature. Without an output schema, this description effectively conveys what the tool returns and its limitations.
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?
The schema covers the single parameter fully (enum USDC/WETH, default USDC). The description adds context about how asset maps to lending markets and gives a Compound USDC example, but it doesn't substantially extend beyond the schema's documentation. Baseline 3 is appropriate given 100% schema coverage.
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 uses a specific verb-resource pairing: it explains how close a Base lending market is to the 'kink' where borrow rates explode. It distinguishes itself from sibling tools focused on exit capacity, yield decisions, durability, and signal by centering on rate sensitivity and kink proximity, with clear metrics (utilization, kink, headroom, borrow APY).
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 context on when to use the tool: it applies to Aave and Compound only, explicitly excluding Morpho (adaptive IRM) and DefiLlama-sourced protocols. It also warns that it measures current state, not predictions. While it doesn't name sibling alternatives, the scope and limitations effectively guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_yield_decisionAInspectBuyer-side MOVE/HOLD decision (Layer 1 premium — sells the decision, not the raw datapoint). Given your current position, size, move cost and horizon, returns whether moving your capital to the best risk-adjusted protocol pays for itself now — with expected net gain, break-even days and a confidence tier. Deterministic from the underlying signal, which is EIP-712 signed and returned in a sibling content block (re-run the decision locally to reproduce it). Priced above the plain signal tool.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Which market the decision is for: USDC/WETH lending on Base, or ETH_STAKING liquid staking on Ethereum mainnet. Defaults to USDC. | |
| position | No | Protocol where your capital sits now (aave/morpho/compound/moonwell/euler/fluid/lido/rocket-pool/coinbase-wrapped-staked-eth/frax-ether/binance-staked-eth). Omit or use 'idle' if uninvested. | |
| amountUsd | No | Position size in USD. Scales the absolute gain and break-even. Defaults to 1000. | |
| horizonDays | No | How many days you expect to hold before re-evaluating. Gain only counts up to here. Defaults to 30. | |
| moveCostUsd | No | Your estimated cost to move (gas + slippage) in USD. Defaults to 0.5. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool is deterministic from an underlying signal, that the signal is EIP-712 signed and returned in a sibling content block, and that the decision can be reproduced locally. It also hints at pricing without specifying costs, which is acceptable 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 slightly long but well-structured with a clear lead sentence. Each sentence adds unique value, including contrast with sibling, explanation of return values, and verification info. No redundancy, but could be tightened slightly.
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?
No output schema exists, so the description must explain return values. It mentions 'expected net gain, break-even days and a confidence tier', which is adequate. It also covers deterministic behavior and verification. For a tool with 5 parameters, the description is complete enough.
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%, baseline is 3. The description adds context beyond schema: e.g., 'amountUsd scales the absolute gain and break-even', 'horizonDays limits gain counting', 'moveCostUsd estimated cost'. This clarifies how parameters affect outputs, justifying a score above baseline.
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 provides a 'MOVE/HOLD decision' for the buyer side, specifies it is a 'Layer 1 premium' that sells the decision rather than raw data, and contrasts with the sibling tool 'get_yield_signal' by noting it is 'priced above the plain signal tool'. The verb 'returns' and resource 'whether moving capital pays for itself' are specific.
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 explains when to use the tool: given current position, size, move cost, and horizon. It implies the alternative is 'get_yield_signal' for raw data by stating it is 'priced above the plain signal tool', but does not explicitly state when not to use this tool. The context is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_yield_durabilityAInspectHow much of the current APY survives if incentives stop. Splits each protocol's yield into base interest vs reward/incentive, reports the post-incentive floor, and says whether the leader changes without incentives. Only protocols whose source itemizes the reward component are decomposed — the rest are listed as undecomposable and NEVER assumed incentive-free, and no ranking claim is made when the current leader is one of them. Also returns bestVerifiableFloor: the highest yield provably independent of incentives. A stress test of readings taken now, not a forecast of when a campaign ends.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Which Base lending market to stress-test: USDC or WETH. Defaults to USDC. |
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 thoroughly explains limitations (undecomposable protocols never assumed incentive-free, no ranking claim if leader is undecomposable), outputs (bestVerifiableFloor), and clarifies the temporal scope (not a forecast). This is exemplary 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 several sentences long but each sentence adds unique value: purpose, decomposition mechanism, limitations, output, and temporal scope. It is dense with information and not unnecessarily wordy, though it could be slightly tighter.
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 has one parameter and no output schema, the description does a good job of explaining primary outputs and caveats. It lacks exact return formatting (e.g., units, data types), but the overall behavior is sufficiently clear for an agent to understand and invoke the tool.
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?
The input schema already provides a description for the only parameter (asset) with 100% coverage, including valid enums and default. The tool description adds no additional parameter-specific semantics, so the baseline of 3 applies.
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 what the tool does: it calculates how much current APY survives if incentives stop, splits yields into base vs reward, and reports a post-incentive floor. This specific verb+resource purpose distinguishes it from siblings like get_yield_decision or get_exit_capacity, which focus on other aspects of yield.
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 gives clear context that this is a stress test of current readings, not a forecast, which implies when to use it and what it is not for. However, it does not explicitly name alternative tools or exclusions beyond that, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_yield_signalAInspectReal-time risk-weighted yield signal. USDC/WETH: lending APY on Base (Aave/Compound/Morpho read onchain, Moonwell/Euler/Fluid via DefiLlama). ETH_STAKING: liquid staking APY on Ethereum mainnet (Lido/Rocket Pool/Coinbase Wrapped Staked ETH/Frax Ether/Binance Staked ETH, all via DefiLlama) — a different chain and category from the lending signals, not a Base lending market. Source tagged per reading (never estimated). Result is signed (EIP-712 typed data) by the payment-receiving address, returned as a sibling content block for offline verification. That same address is registered on-chain as an ERC-8004 agent identity (agent-card.json) and periodically publishes EAS attestations of past readings (Base mainnet) — a public track record independent of this server's uptime.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Which yield signal to fetch: USDC/WETH lending APY on Base, or ETH_STAKING liquid staking APY on Ethereum mainnet. Defaults to USDC. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It thoroughly discloses real-time and risk-weighted nature, specific sources (onchain vs DefiLlama), different chain/category distinction, signed result (EIP-712), public track record via EAS attestations, and offline verification capabilities. No contradictions or omissions.
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 appropriately sized, front-loaded with the core purpose, and every sentence provides unique value. It avoids redundancy and wasted words. The structure flows logically: purpose, asset breakdown, source transparency, output format, and verification details.
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 no output schema, the description covers all necessary aspects: what the tool does, which assets and chains, how data is sourced (with source tagging), expected output format (signed data), and offline verification mechanism. It provides a complete picture for an agent to understand and invoke the tool 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 has one optional parameter with enum and description (100% coverage). The description adds significant meaning by explaining what each enum value corresponds to (USDC/WETH lending on Base, ETH_STAKING liquid staking on Ethereum), which goes beyond the schema's brief description. It effectively enriches understanding of the parameter's role.
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 provides a 'Real-time risk-weighted yield signal' for specific assets (USDC/WETH lending APY on Base, ETH_STAKING liquid staking APY on Ethereum mainnet). It distinguishes itself from the sibling tool 'get_yield_decision' by focusing on fetching the raw signal. The verb+resource combination is precise and unambiguous.
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 does not explicitly guide when to use this tool versus the sibling 'get_yield_decision'. It implicitly suggests it is for fetching raw yield data, but lacks explicit 'when to use' or 'when not to use' guidance. The agent can infer usage from context but no direct alternatives are stated.
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!
