Skip to main content
Glama

buy_yields_protocol_re

Paid. Live DeFi yields for re: its pools across chains with APY, TVL, 7d APY change (DefiLlama data). $0.005 USDC on Base or Solana. No account, no API key. Failed calls not charged. URL https://southpow.media/v1/yields/protocol/re.

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": "buy_yields_protocol_re"
  }
}

Input Schema

NameRequiredDescriptionDefault
sortNotvl (default) or apy
limitNoRows, 1-100 (default 20)
min_tvl_usdNoMinimum pool TVL in USD (default 100000)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden and does a decent job: it discloses the cost ($0.005 USDC), payment chains (Base or Solana), that no account or API key is needed, that failed calls are not charged, and the backing data source. It omits rate limits and the response/pagination shape.

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?

Front-loads the critical 'Paid' flag, then scope, then cost and mechanics in a few tight sentences with zero filler. The fragment 'for re:' is slightly cryptic but still efficient.

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?

For a paid, no-auth, no-output-schema data endpoint, the description covers what an agent needs to decide and pay: scope, data fields, price, accepted chains, failure billing policy, and the endpoint URL. Nothing essential to invoking it correctly is missing.

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 coverage is 100%, so sort, limit and min_tvl_usd are already fully documented in the schema. The description adds no syntax or default detail beyond noting the returned fields, so the baseline 3 applies.

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?

States a specific resource and scope: live DeFi yields for the 're' protocol only, with the exact fields returned (APY, TVL, 7d APY change) and the data source (DefiLlama). Among the many buy_yields_protocol_* siblings the protocol scoping is implicit in the name, but the description makes clear this is not a chain-, token- or top-level yields tool.

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?

Usage is only implied — 'Paid' plus the price signal that this is a metered call, and the protocol name signals when it applies. It never states when to prefer buy_yields_chain_* or buy_yields_top instead, nor any prerequisite for paying.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources