Skip to main content
Glama

YieldSignal

by io.github.Stakemate369

get_yield_durability

How 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
assetNoWhich Base lending market to stress-test: USDC or WETH. Defaults to USDC.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries full disclosure burden. It explicitly states the decomposition limitation, that undecomposable protocols are never assumed incentive-free, that no ranking claim is made in such cases, and describes the bestVerifiableFloor return field. 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.

Conciseness5/5

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

The description is dense but well-organized: a leading question, a breakdown of outputs, a key limitation, and a clarifying note about stress testing vs forecasting. Every sentence adds unique value with no fluff.

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

Completeness5/5

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

Given the tool's moderate complexity (one optional param, no output schema), the description covers behavior, edge cases, limitations, and key return values comprehensively. It is self-contained enough for an agent to select and invoke the tool correctly.

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?

The schema already fully documents the single optional asset parameter with its enum and default. The description does not add new parameter details beyond what the schema provides, but it does add context about the tool operating on 'each protocol's yield' within the chosen market. 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.

Purpose5/5

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

The description opens with a clear, specific question ('How much of the current APY survives if incentives stop?') and then details exactly what the tool computes: base vs reward yield, post-incentive floor, and leader changes. This differentiates it from sibling tools about exit capacity, decisions, or signals.

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 description makes the tool's purpose very clear and adds a crucial usage caveat: it's a stress test of current readings, not a forecast. It does not explicitly name alternative tools or state when not to use it, but the behavioral scope is well-defined.

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

All YieldSignal toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool addresses a distinct aspect of yield analysis: signal provides raw data, durability stress-tests incentive dependence, decision recommends an action, and exit capacity evaluates liquidity. There is no overlap; an agent can clearly select the right tool for the task.

Naming Consistency5/5

All tools follow a consistent get_<yield_>?<specific> pattern, using snake_case and a uniform verb. get_exit_capacity fits the pattern with 'get_' and a clear noun even without 'yield' in the name, maintaining predictability.

Tool Count5/5

Four tools is a well-scoped set for a focused yield analytics server. Each tool earns its place by covering a distinct part of the decision workflow without redundancy or unnecessary bloat.

Completeness5/5

The tool set covers the full yield analysis lifecycle: raw signal, durability under incentive changes, decision recommendation, and exit liquidity. There are no obvious dead ends; an agent can go from data to action to exit assessment without missing critical operations.

Resources