Skip to main content
Glama

YieldSignal

by io.github.Stakemate369

get_yield_signal

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
assetNoWhich yield signal to fetch: USDC/WETH lending APY on Base, or ETH_STAKING liquid staking APY on Ethereum mainnet. Defaults to USDC.

Schema Changelog

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

  1. Changed1 schema field changed
    • changedInput schema / properties / asset / enum
      Previous value: -[
-  "USDC",
-  "WETH",
-  "ETH_STAKING"
-]New value: +[
+  "ETH_STAKING",
+  "USDC",
+  "WETH"
+]
  2. Changed2 schema fields changed
    • changedInput schema / properties / asset / description
      Previous value: -"Which asset's lending yield to compare. Defaults to USDC."New value: +"Which yield signal to fetch: USDC/WETH lending APY on Base, or ETH_STAKING liquid staking APY on Ethereum mainnet. Defaults to USDC."
    • changedInput schema / properties / asset / enum
      Previous value: -[
-  "USDC",
-  "WETH"
-]New value: +[
+  "USDC",
+  "WETH",
+  "ETH_STAKING"
+]
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses key behavioral traits: signed output (EIP-712), source tagging (never estimated), different chains/categories, and verification mechanisms (on-chain registration, EAS attestations). This is highly transparent.

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?

The description is fairly long but each sentence adds value. It is well-structured, front-loading the core functionality before detailing verification aspects. Minor redundancy could be trimmed, but overall concise for the complexity.

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

Completeness4/5

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

Given the complexity (multiple sources, chains, signed data), the description covers key aspects: asset categories, sources, verification, and offline use. It lacks explicit return format details, but the context of 'yield signal' and 'signed data' suffices for an agent.

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

Parameters4/5

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

The input schema has one parameter with enum and 100% description coverage. The description adds meaningful context by explaining what each enum value represents (e.g., ETH_STAKING = liquid staking APY on Ethereum mainnet) and notes the default (USDC), enhancing understanding beyond schema.

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 clearly states the tool fetches a real-time risk-weighted yield signal for specific assets (USDC, WETH lending on Base; ETH_STAKING on Ethereum mainnet). It distinguishes between lending and staking categories with explicit chains and sources, making the purpose unambiguous.

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

Usage Guidelines3/5

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

The description explains when to use each asset type but does not provide guidance on when to use this tool versus its sibling get_yield_decision. It implies this tool retrieves raw signals while the sibling may handle decisions, but this is not explicit.

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