Defillama

Defi Yields

defi_yields

Read-onlyIdempotent

Find yield opportunities across DeFi pools filtered by project name, minimum TVL, or minimum APY. Returns APY, TVL, and project details.

Input Schema

TableJSON Schema

Name	Required	Description
`search`	No	Filter by project name (case-insensitive substring match)
`min_apy`	No	Minimum APY percentage (e.g., 5 for 5%)
`min_tvl`	No	Minimum TVL in USD (e.g., 1000000 for $1M)

Output Schema

TableJSON Schema

Name	Required	Description
`pools`	Yes
`showing`	Yes	Number of pools returned (max 50)
`total_matched`	Yes	Total pools matching filters

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedMay 8, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "pools": {
+      "items": {
+        "properties": {
+          "apy": {
+            "description": "Annual percentage yield",
+            "type": "number"
+          },
+          "apy_base": {
+            "description": "Base APY from swap fees",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "apy_reward": {
+            "description": "Additional reward APY",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "chain": {
+            "description": "Blockchain where pool is deployed",
+            "type": "string"
+          },
+          "exposure": {
+            "description": "Pool exposure type",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "il_risk": {
+            "description": "Impermanent loss risk level",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "pool_id": {
+            "description": "Unique pool identifier",
+            "type": "string"
+          },
+          "project": {
+            "description": "Project/protocol name",
+            "type": "string"
+          },
+          "stablecoin": {
+            "description": "Whether pool is stablecoin pair",
+            "type": "boolean"
+          },
+          "symbol": {
+            "description": "Pool token symbol",
+            "type": "string"
+          },
+          "tvl_usd": {
+            "description": "Total value locked in USD",
+            "type": "number"
+          }
+        },
+        "required": [
+          "pool_id",
+          "project",
+          "chain",
+          "symbol",
+          "tvl_usd",
+          "apy"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "showing": {
+      "description": "Number of pools returned (max 50)",
+      "type": "integer"
+    },
+    "total_matched": {
+      "description": "Total pools matching filters",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "total_matched",
+    "showing",
+    "pools"
+  ],
+  "type": "object"
+}

Changed1 schema field changedMay 6, 2026

addedInput schema / examples

Added value: +[
+  {
+    "search": "curve"
+  },
+  {
+    "min_apy": 5,
+    "min_tvl": 1000000
+  }
+]

First observedApr 22, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows the tool is safe and non-destructive. The description adds that it returns APY, TVL, and project details, but does not disclose additional behavior like data freshness or pagination. With annotations covering the core traits, the description adds minimal extra value.

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 two sentences, front-loaded with the action, and contains no extraneous words. Every sentence serves a clear purpose.

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 tool's simplicity (3 optional parameters, output schema present), the description covers the essentials. It could mention that all parameters are optional, but that is inferable from schema. The description is complete enough for a look-up tool.

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% with each parameter having a clear description. The tool description rephrases the filtering concepts but adds no new semantic information beyond the schema. Baseline score of 3 is appropriate.

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 verb 'find' and the resource 'yield opportunities across DeFi pools'. It specifies filter criteria (project name, minimum TVL, minimum APY) and what is returned (APY, TVL, project details). This distinguishes it from sibling tools like defi_chain_tvl or defi_protocol_fees.

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 implies usage for finding yields with filters, but does not explicitly state when to use this tool vs alternatives. Among siblings, there are other DeFi tools, but no guidance is provided. The context is implied but not explicit.

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

All Defillama tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.