Skip to main content
Glama
Abstract36

stakechain-mcp

by Abstract36
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

List Base yield opportunities

list_base_yields
Read-only

Survey Base staking and lending opportunities with APY, TVL, project and asset per pool. Filter by asset, minimum TVL, or stablecoins to compare available yields.

Instructions

Survey staking and lending opportunities on Base: APY, TVL, project and asset for each. Use this to see the landscape or to answer 'what is available', and use best_yield instead when one asset's single best option is wanted. Results already exclude obvious traps (minimum TVL, APY ceiling). Returns market data, not a recommendation; the pool id of any row can be passed to yield_history.

Input Schema

NameRequiredDescriptionDefault
assetNoFilter by asset symbol, e.g. 'USDC', 'ETH', 'cbBTC'
minTvlNoMinimum total deposits in USD, e.g. 10000000 for $10M
stableNoTrue returns stablecoin pools only
sortByApyNoTrue sorts by APY descending; default order is by TVL, largest first

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.1
    • changedInput schema / properties / asset / description
      Previous value: -"Filter by asset symbol, e.g. ETH, USDC"New value: +"Filter by asset symbol, e.g. 'USDC', 'ETH', 'cbBTC'"
    • changedInput schema / properties / minTvl / description
      Previous value: -"Minimum TVL in USD"New value: +"Minimum total deposits in USD, e.g. 10000000 for $10M"
    • changedInput schema / properties / sortByApy / description
      Previous value: -"Sort by APY descending"New value: +"True sorts by APY descending; default order is by TVL, largest first"
    • changedInput schema / properties / stable / description
      Previous value: -"Only stablecoin pools"New value: +"True returns stablecoin pools only"
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld/non-destructive, so the bar is lower. The description adds meaningful behavior beyond that: results are pre-filtered to exclude 'obvious traps' (minimum TVL, APY ceiling) and explicitly framed as market data rather than a recommendation, which sets agent expectations about result trustworthiness.

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?

Three tightly packed sentences, front-loaded with the core purpose, then routing, then the filtering caveat. Nothing is redundant and every clause carries information.

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?

No output schema exists, but the description compensates by naming the returned fields (APY, TVL, project, asset) and the `pool` id usable with `yield_history`. Combined with the pre-filtering note, an agent has everything needed to call and interpret 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%, so the schema already documents all four parameters fully. The description adds no additional parameter information (no filter interaction or default behavior detail), so baseline 3 applies.

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?

States a specific verb and resource ('Survey staking and lending opportunities on Base') and enumerates the returned fields (APY, TVL, project, asset). It clearly distinguishes itself from best_yield by scope: broad landscape vs. single-asset best option.

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

Usage Guidelines5/5

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

Explicitly names the alternative `best_yield` with the condition that selects it ('when one asset's single best option is wanted'), and also points to `yield_history` for drill-down via the pool id. When-to-use and cross-tool routing are both covered.

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