DefiLlama MCP Server
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@DefiLlama MCP ServerShow me the top 10 protocols by TVL"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
DefiLlama MCP Server
Overview
The DefiLlama MCP Server enables AI agents to interact with DefiLlama, a comprehensive DeFi data aggregator. This server provides access to TVL metrics, DEX volumes, protocol statistics, stablecoin data, token prices, yield farming pools, options data, and more — across 8 service groups and 4 upstream hosts.
By implementing the Model Context Protocol (MCP), this server allows Large Language Models (LLMs) to query DeFi data through a Code Mode surface: instead of one tool per endpoint, agents write small JavaScript programs that run in a sandboxed isolated-vm environment against a pre-wired defillama.* client. Four opt-in dynamic tools are available for structured endpoint discovery and dispatch.
Related MCP server: Birdeye MCP Server
Demo
The server in use from Claude. The agent uses search_docs to find the right method, writes a small program for the execute sandbox, and projects only the answer back across the boundary.
"Which protocol has the highest TVL 7-day change?" — the agent loads the tools, calls search_docs to find how to read the change metric, then writes an execute program. It notices the raw leader is a data artifact (a protocol whose TVL jumped from near-zero, reading as a trillion-percent gain) and reasons toward the meaningful answer:

It then distinguishes the literal answer (3Jane Lending) from the meaningful one (STRATO, the top gainer among protocols with enough TVL for the percentage to be credible):

"Pools with high TVL and their 30-day APY" — one execute call fetches the yield pools, ranks them by TVL, and formats apyMean30d into a table:

Requirements
Node.js >= 22 (required by
isolated-vm6.x for theexecutesandbox).The published binary's shebang already passes
--no-node-snapshotto node. If you invokenode dist/index.jsdirectly, pass--no-node-snapshotyourself:node --no-node-snapshot dist/index.js.isolated-vmis declared inoptionalDependencies, sopnpm installwill succeed on platforms without a prebuilt addon or a compiler toolchain. The server still starts andsearch_docsstill works; onlyexecutewill report a load-failure error until you runpnpm rebuild isolated-vm.pnpm(for package management andpnpm dlxinvocations).
Installation
Using pnpm dlx (Recommended)
To use this server without installing it globally:
pnpm dlx @iqai/defillama-mcpBuild from Source
git clone https://github.com/IQAIcom/mcp-defillama.git
cd mcp-defillama
pnpm install
pnpm run buildRunning with an MCP Client
Add the following configuration to your MCP client settings (e.g., claude_desktop_config.json).
Minimal Configuration
{
"mcpServers": {
"defillama": {
"command": "pnpm",
"args": ["dlx", "@iqai/defillama-mcp"],
"env": {}
}
}
}Advanced Configuration (With IQ Gateway)
{
"mcpServers": {
"defillama": {
"command": "pnpm",
"args": ["dlx", "@iqai/defillama-mcp"],
"env": {
"IQ_GATEWAY_URL": "your_iq_gateway_url",
"IQ_GATEWAY_KEY": "your_iq_gateway_key"
}
}
}
}Enabling Dynamic Tools
Start with --tools=dynamic (or set DEFILLAMA_MCP_TOOLS=dynamic) to also register the four endpoint-dispatch tools:
{
"mcpServers": {
"defillama": {
"command": "pnpm",
"args": ["dlx", "@iqai/defillama-mcp", "--tools=dynamic"],
"env": {}
}
}
}Note (Claude Desktop / older MCP clients): Claude Desktop may resolve
pnpm/nodefrom an older Node in yourPATH, which the server rejects (Node >= 22 is required). If startup fails with a Node version error, see Troubleshooting below.
Configuration (Environment Variables)
All environment variables are optional. DefiLlama's public API works unauthenticated; the API key and gateway settings are for users who have paid access or want caching.
Variable | Required | Description | Default |
| No | DefiLlama API key; sent as | — |
| No | IQ Gateway base URL. When set together with | — |
| No | IQ Gateway API key; sent as | — |
| No | Set to | — |
Troubleshooting
requires Node >= 22 / ReferenceError: File is not defined
The server requires Node >= 22 (the execute sandbox uses isolated-vm 6.x). When launched via pnpm dlx/npx, the package's shebang resolves whatever node comes first in the MCP client's PATH — and clients like Claude Desktop often inherit a PATH where an older Node (e.g. from nvm) is first. Under that older Node the server now exits immediately with:
[defillama-mcp] @iqai/defillama-mcp requires Node >= 22 (running v18.17.1).(Older releases instead crashed with a cryptic ReferenceError: File is not defined from a transitive dependency.)
Fix — pin an absolute Node >= 22. Install the package with a Node 22 toolchain and point the client directly at that Node binary and the installed entry, bypassing PATH entirely:
# with the Node >= 22 you want to run under:
npm install -g @iqai/defillama-mcp@latest
npm root -g # prints <global>; entry is <global>/@iqai/defillama-mcp/dist/index.js
which node # absolute path to your Node >= 22 binary{
"mcpServers": {
"defillama": {
"command": "/absolute/path/to/node22/bin/node",
"args": [
"--no-node-snapshot",
"/absolute/path/to/global/node_modules/@iqai/defillama-mcp/dist/index.js"
],
"env": {}
}
}
}Add "--tools=dynamic" as a third entry in args to enable the dynamic tools.
Alternatively, keep pnpm dlx but force a Node >= 22 onto the front of PATH via the server's env:
{
"mcpServers": {
"defillama": {
"command": "/absolute/path/to/node22/bin/pnpm",
"args": ["dlx", "@iqai/defillama-mcp@latest"],
"env": { "PATH": "/absolute/path/to/node22/bin:/usr/local/bin:/usr/bin:/bin" }
}
}
}On Windows, use the ; path separator and Windows-style paths in the PATH override (e.g. "PATH": "C:\\Program Files\\nodejs;C:\\Windows\\System32"), and point command at node.exe / pnpm.cmd.
The absolute-path approach is recommended — it also avoids a per-launch dlx fetch.
Architecture
┌────────────────────────────────────────────────────────────────────────────┐
│ Claude Desktop / Cursor / any MCP client │
└─────────────────────────────────┬──────────────────────────────────────────┘
│ stdio (JSON-RPC)
▼
┌────────────────────────────────────────────────────────────────────────────┐
│ defillama-mcp server │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ Default tools │ Dynamic tools (opt-in via --tools=…) │ │
│ │ ────────────────────── │ ────────────────────────────────── │ │
│ │ execute │ defillama_resolve │ │
│ │ search_docs │ list_endpoints │ │
│ │ │ get_endpoint_schema │ │
│ │ │ invoke_endpoint (with jq_filter) │ │
│ └──────────────────────────────────────────────────────────────────────┘ │
│ │ │ │
│ ┌─────────▼──────────────┐ ┌──────────▼──────────────┐ │
│ │ isolated-vm sandbox │ │ direct dispatch │ │
│ │ • 128 MiB cap │ │ • zod schema validate │ │
│ │ • 30 s wall clock │ │ • 5 s / 6 s timeouts │ │
│ │ • scope budget+slots │ │ • jq projection │ │
│ └────────────────────────┘ └─────────────────────────┘ │
│ └──────────────┬──────────────────┘ │
└───────────────────────────┼────────────────────────────────────────────────┘
│ HTTPS (optional API key or IQ Gateway)
▼
┌──────────────────────────────────────────────┐
│ DefiLlama upstream (4 hosts) │
│ api.llama.fi coins.llama.fi │
│ stablecoins.llama.fi yields.llama.fi │
└──────────────────────────────────────────────┘How execute works (one call's lifetime)
sequenceDiagram
participant Agent
participant Tool as execute (tool.ts)
participant Sandbox as runInSandbox (sandbox.ts)
participant Guest as Guest JS<br/>(V8 isolate)
participant Bridge as installServiceCall<br/>(client.ts)
participant DefiLlama as DefiLlama API
Agent->>Tool: tools/call execute {code}
Tool->>Tool: createExecutionScope()<br/>(budget=100, concurrency=10)
Tool->>Sandbox: runInSandbox(code, installClient)
Sandbox->>Sandbox: new Isolate({memoryLimit:128MB})
Sandbox->>Bridge: installDefillamaClient(ctx, scope)
Bridge-->>Guest: install defillama.protocol.*, defillama.price.*, resolveChain, ...
Sandbox->>Guest: script.run({timeout:30s})
Guest->>Bridge: await defillama.protocol.getChains({})
Bridge->>Bridge: tryReserveBudget<br/>acquireSlot<br/>safeParse(args)
Bridge->>DefiLlama: HTTPS (5s abort + 6s axios timeout)
DefiLlama-->>Bridge: JSON
Bridge-->>Guest: envelope {ok:true, data}
Guest-->>Sandbox: return projected result
Sandbox-->>Tool: {ok, result, log_lines, err_lines}
Tool->>Tool: cancelScope() in finally
Tool-->>Agent: MCP envelopeThe key insight: only the projected return value crosses the V8 boundary. The agent writes JS that loops, joins, and filters; the host sees one returned value, not N intermediate responses.
Code Mode
The preferred way to query DefiLlama from an AI agent is the execute + search_docs pair. These two tools handle the full workflow — discovery, projection, multi-step composition — through agent-authored JavaScript.
Default tool surface
By default the server registers exactly two tools:
Tool | Purpose |
| Run agent-authored JavaScript in a secure |
| Search the embedded MiniSearch index over all DefiLlama API methods and cookbook entries. |
--tools=dynamic mode
Start the server with --tools=dynamic (or set DEFILLAMA_MCP_TOOLS=dynamic) to register four additional tools:
Tool | Purpose |
| Resolve a human-readable name ("BSC", "Lido", "USDC") to its DefiLlama identifier. |
| List all available endpoint qualified names with descriptions. |
| Inspect parameters and response shape for a specific endpoint. |
| Call a single endpoint by qualified name with an optional |
MCP client configuration with dynamic tools:
{
"mcpServers": {
"defillama": {
"command": "pnpm",
"args": ["dlx", "@iqai/defillama-mcp", "--tools=dynamic"],
"env": {}
}
}
}Or via environment variable:
{
"mcpServers": {
"defillama": {
"command": "pnpm",
"args": ["dlx", "@iqai/defillama-mcp"],
"env": {
"DEFILLAMA_MCP_TOOLS": "dynamic"
}
}
}
}execute — Sandboxed JavaScript
Run arbitrary JavaScript inside a secure isolated-vm sandbox. The sandbox receives a fully-configured DefiLlama client as defillama. All eight service groups are available.
Define async function run(defillama) { ... }; the JSON-serializable return value (plus console.log output) is sent back.
Example — top 5 protocols by TVL:
async function run(defillama) {
const protocols = await defillama.protocol.getProtocols();
return protocols
.sort((a, b) => (b.tvl ?? 0) - (a.tvl ?? 0))
.slice(0, 5)
.map(p => ({ name: p.name, tvl: p.tvl, chain: p.chain }));
}Example — current price of ETH and USDT:
async function run(defillama) {
return await defillama.price.getCurrentPrices({
coins: 'coingecko:ethereum,ethereum:0xdac17f958d2ee523a2206206994597c13d831ec7'
});
}defillama.* client groups
The defillama client inside execute is split into eight groups that mirror the upstream service architecture:
Group | Methods | Upstream host |
|
| api.llama.fi |
|
| api.llama.fi |
|
| api.llama.fi |
|
| api.llama.fi |
|
| stablecoins.llama.fi |
|
| coins.llama.fi |
|
| yields.llama.fi |
|
| coins.llama.fi |
Resolvers
Three resolver helpers are available inside execute:
resolveChain(input)— resolves a human name to{ name, slug }. Use.nameforapi.llama.figroups (protocol, dex, fees, options) and.slugforcoins.llama.ficalls (price, blockchain).resolveProtocol(input)— resolves a protocol name to its DefiLlama slug string (e.g."lido").resolveStablecoin(input)— resolves a stablecoin name or symbol to its numeric DefiLlama ID string (e.g."1"for USDT).
Example:
async function run(defillama) {
const chain = await defillama.resolveChain('BSC');
// chain = { name: 'BSC', slug: 'bsc' }
const overview = await defillama.dex.getDexsOverview({ chain: chain.name });
return overview.protocols?.slice(0, 5).map(p => ({ name: p.name, volume: p.total24h }));
}Chain name vs. slug convention
DefiLlama uses two chain spellings depending on the host:
api.llama.fi groups (
protocol,dex,fees,options) use the chain display name — e.g."Ethereum","BSC".coins.llama.fi calls (
price,blockchain) use the lowercase slug — e.g."ethereum","bsc".
resolveChain(x) returns { name, slug }. Always use .name for api-group parameters and .slug for coins-group parameters.
Price coin format — chain:address
The price group identifies tokens as chain:address, using the lowercase chain slug:
ethereum:0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2— WETH on Ethereumcoingecko:ethereum— native ETH via CoinGecko ID (no contract address needed)bsc:0x55d398326f99059ff775485246999027b3197955— USDT on BSC
Multiple tokens are comma-separated:
await defillama.price.getCurrentPrices({
coins: 'coingecko:ethereum,ethereum:0xdac17f958d2ee523a2206206994597c13d831ec7'
})search_docs — Local Documentation Search
Search the embedded MiniSearch index over all DefiLlama API methods and cookbook entries. Use it first when you're unsure which method or parameters you need, or to find a worked recipe.
Example query: top protocols tvl
Safety limits
The execute sandbox enforces five bounds. Defaults are tuned for legitimate Promise.all-style work.
Limit | Default | Override | Behaviour on hit |
Isolate memory | 128 MiB | hard-coded | Isolate is terminated; error surfaces as script timeout (V8 conflates OOM with timeout in some paths) |
Script wall clock | 30 s | internal (test only) | Returns |
Calls per | 100 | internal (test only) | Subsequent guest calls return budget-exceeded error |
Concurrent calls | 10 | internal (test only) | Calls queue on a semaphore; no error, just back-pressure |
Per-call upstream | 5 s abort + 6 s axios | hard-coded | Returns |
These limits protect DefiLlama's public rate limits, which are not tied to any user credential.
The sandbox also blocks the source-level identifiers process., require(, import(, and eval( at submission time as a defense-in-depth check.
Schema validation is enforced on every guest call: arguments are zod-parsed against the method's published schema before reaching the upstream service. Invalid arguments return a clear error message rather than propagating to the API.
invoke_endpoint with jq_filter
invoke_endpoint (in --tools=dynamic mode) accepts an optional jq_filter that projects the response before it crosses back to the agent — reduces response size and skips client-side parsing.
{
"name": "defillama.protocol.getChains",
"params": {},
"jq_filter": "[.[] | {name, tvl}] | sort_by(-.tvl) | .[0:5]"
}Common patterns:
Goal | jq filter |
Project one field |
|
Pick from each item |
|
Filter then project |
|
Aggregate |
|
The filter runs through jqts (pure-JS, no native jq binary) so it works on every platform.
Error envelopes
Every tool returns the MCP standard { content: [{ type, text }], isError } envelope. The text is JSON containing one of:
Shape | When you'll see it |
|
|
|
|
|
|
|
|
|
|
|
|
Raw method JSON (or jq projection) |
|
|
|
Errors never throw across the VM boundary — every guest-side failure surfaces as an { ok: false, error } envelope.
Migrating from earlier versions
The ~19 endpoint-specific defillama_* tools are removed. Use execute for multi-step workflows, or start with --tools=dynamic for the per-endpoint dispatch triad:
list_endpoints— discover available endpoints and their qualified names.get_endpoint_schema— inspect parameters and response shape for a specific endpoint.invoke_endpoint— call a single endpoint with optionaljq_filterfor host-side projection.
The OPENROUTER_API_KEY, LLM_MODEL, and GOOGLE_GENERATIVE_AI_API_KEY env vars are no longer recognized.
ADK Usage
@iqai/defillama-mcp exports an ADK-compatible helper:
import { getDefillamaTools } from "@iqai/defillama-mcp/dist/adk/index.js";
// Default surface (execute + search_docs) — 2 tools
const tools = getDefillamaTools();
// With dynamic tools enabled — 6 tools
const allTools = getDefillamaTools({ dynamic: true });getDefillamaTools() returns BaseTool[] from @iqai/adk. These wrap the same MCP tool implementations and can be dropped into any ADK agent.
Development
Build Project
pnpm run buildDevelopment Mode (Watch)
pnpm run watchLinting & Formatting
pnpm run lint
pnpm run formatTests
pnpm testRelease Management
pnpm changeset # Create a release note
pnpm version-packages # Apply pending changesets
pnpm publish-packages # Build and publishProject Structure
src/
├── index.ts # Server entry point (FastMCP registration)
├── env.ts # Env validation (dotenv + zod)
├── config.ts # Per-group cache TTLs
├── types.ts # Shared TypeScript types
├── adk/index.ts # getDefillamaTools() ADK adapter
├── services/ # DefiLlama API client (one *.service.ts per domain)
│ └── base.service.ts # RequestOptions, IQ-Gateway + direct fetch
├── lib/
│ ├── entity-resolver.ts # resolveChain / resolveProtocol / resolveStablecoin
│ └── utils/ # logger, error-handler
├── mcp/
│ ├── tools.ts # defillama_resolve (dynamic mode)
│ ├── execute/ # Code Mode: sandbox + client + scope + tool
│ ├── search-docs/ # MiniSearch index + tool + cookbook recipes
│ ├── endpoints/ # list_endpoints / get_endpoint_schema / invoke_endpoint
│ ├── instructions/ # instructions.md → instructions.generated.ts
│ └── catalog/ # tool-metadata + response-schemas (shared)
└── enums/chains.ts # Bundled chain catalog (fallback when live fetch fails)
scripts/
├── build-docs-index.ts # Pre-build: tool-metadata + cookbook → embedded-index.ts
└── build-instructions.ts # Pre-build: instructions.md → instructions.generated.ts
tests/integration/ # End-to-end tests (spawn the built server)Resources
Disclaimer
This project is an unofficial tool and is not directly affiliated with DefiLlama. It interacts with DeFi protocol data via DefiLlama's public API. Users should exercise caution and verify all data independently. DeFi involves risk.
License
Available Tools
2 toolsexecuteA
Run async JavaScript against a pre-wired DefiLlama client. Define async function run(defillama) { ... }; the JSON-serializable return value is sent back plus console.log output. The defillama client mirrors the services: defillama.protocol, defillama.dex, defillama.fees, defillama.options, defillama.stablecoin, defillama.price, defillama.yield, defillama.blockchain, plus defillama.resolveChain / defillama.resolveProtocol / defillama.resolveStablecoin helpers. JavaScript only (no type annotations); variables don't persist between calls; no fs, no network outside the client.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| intent | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the minimal readOnlyHint=false annotation, the description thoroughly discloses behavioral traits: the execution model (async function, JSON-serializable return), console.log output capture, the full client service surface, and sandbox constraints. This provides rich context for predicting tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a front-loaded purpose, a usage template, a compact list of client services, and a set of constraints. Each sentence adds value, and the length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core functionality, client capabilities, return format, and limitations, but it omits behavior on errors/timeouts and does not explain the 'intent' parameter. Given the tool's complexity and lack of output schema, these gaps make it not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for 'code' or 'intent' (0% coverage). The description explains the expected content of 'code' via the `async function run(defillama)` template, but it never clarifies the optional 'intent' parameter. This partial compensation for the schema gap earns a mid score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Run async JavaScript against a pre-wired DefiLlama client.' It provides a concrete usage template and lists the client's services, making it easy to distinguish from the sibling search_docs tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on how to use the tool, including the required async function signature and constraints like 'no fs, no network outside the client' and 'variables don't persist between calls.' However, it does not explicitly mention when to use this tool over search_docs or any exclusions, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_docsARead-only
Search DefiLlama SDK docs to find the right methods, parameters, and example code. Use before writing execute() code when you're unsure of the API.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| detail | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's mention of 'search' aligns. It adds value by specifying the kind of results (methods, parameters, example code) and the intended usage context, though it doesn't go into deeper behaviors like rate limits or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. The first states the action, the second provides usage guidance, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 2 parameters and no output schema, the description adequately covers purpose, usage, and output hint. The 'detail' parameter is not explained, which is a minor gap given its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives meaning to the 'query' parameter as the search term but entirely omits the 'detail' parameter. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches DefiLlama SDK docs for methods, parameters, and example code, using the specific verb 'search' and resource 'docs.' It distinguishes from the sibling 'execute' tool by framing this as a pre-execution lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use before writing execute() code when unsure of the API, providing both a clear context and an implicit alternative (execute). This is strong when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v1.0.8- First observed
execute - First observed
search_docs
TDQS
Scored across 2 tools
The two tools serve clearly distinct purposes: `execute` runs JavaScript against the DefiLlama client, while `search_docs` provides documentation lookup. There is no overlap or confusion between them.
Both tool names are lowercase and follow an imperative style: a single verb (`execute`) and a verb_noun compound (`search_docs`). The naming pattern is simple and consistent across the set.
With only two tools, the count is on the low end. However, the pair of research (search_docs) and action (execute) is a coherent minimal design, though it may feel thin compared to more direct data-access tool sets.
The `execute` tool provides full programmatic access to all DefiLlama services via JavaScript, making the surface functionally complete. The addition of `search_docs` fills the knowledge gap, covering the entire workflow without dead ends.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
DefiLlama MCP — DeFi analytics from DefiLlama (free, no auth)
Enable AI assistants to interact seamlessly with the DefiLlama API by translating MCP tool calls i…
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
Provide AI agents and automation tools with contextual access to blockchain data including balance…
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceReal-time DeFi data for AI agents. Provides yields, TVL, prices, DEX volumes, fees, and contract data via 8 MCP endpoints, powered by DeFiLlama.-
- FlicenseNot gradedqualityDmaintenanceProvides blockchain data context from Birdeye APIs for AI models via Model Context Protocol, enabling token, market, wallet, NFT, and DEX pool queries on Solana.-
- AlicenseBqualityDmaintenanceEnables Claude to access DeFi data via DefiLlama API, including protocol TVL, chain TVL, token prices, and stablecoin information.79MIT
- AlicenseAqualityFmaintenanceProvides access to DeFi Llama's free API for querying protocol TVL, chain TVL, yields, stablecoins, bridges, DEX volumes, and fees through natural language.87MIT