DeFi Llama MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.4
Disambiguation5/5
Each tool targets a distinct data category (bridges, stablecoins, protocols, chains, yields, DEX volumes, fees). Even the two TVL-related tools are clearly separated between protocol-level and chain-level, making misselection unlikely.
Naming Consistency4/5
All tools follow a verb_noun pattern with 'get_' except for 'search_protocols', which uses 'search_' instead. This minor inconsistency is offset by the otherwise uniform naming style, so no real confusion arises.
Tool Count5/5
With 8 tools, the server is well-scoped for a data aggregation service like DeFi Llama. Each tool represents a major data section without redundancy, fitting comfortably within the ideal 3-15 range.
Completeness4/5
The tool set covers the core DeFi metrics: TVL (protocol and chain), yields, stablecoins, DEX volumes, bridges, and fees. Some granular data (e.g., token-specific details or historical charts) is missing, but the available surface supports most common research workflows.
Average 4.2/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses ranking and return fields but does not mention data source, pagination, or ordering details beyond the ranking criterion.
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 three concise sentences, each providing distinct value: action, returned data, and usage context. No wasted words.
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?
The tool is simple with one optional parameter and no output schema. The description covers the essential action, fields, and usage, but could be more explicit about the output being a list and the currency of TVL.
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?
The input schema fully describes the sole parameter 'limit' with a clear description, yielding 100% schema coverage. The tool description adds no additional parameter semantics, so a 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 tool retrieves cross-chain bridge data ranked by TVL, with a specific verb and resource. It enumerates the returned fields, which distinguishes it from sibling tools focused on other asset types or metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use case context: comparing bridge liquidity and identifying dominant capital flows. However, it doesn't explicitly mention alternatives or when not to use this tool, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the return fields and ranking by TVL, but does not state whether the operation is read-only, whether there are rate limits, pagination, or what happens on no matches. It is not misleading but lacks depth for a completely transparent view.
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 verb 'Search', and every sentence provides value: the first explains the search and return structure, the second tells how to proceed using the slug. No fluff or redundancy.
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?
For a simple 2-parameter search tool with no output schema, the description is nearly complete: it states the search behavior, the result fields, ranking, and the next step with a sibling tool. Minor gaps like handling empty results or result ordering are not critical, and the schema covers 'limit'. Overall, it is enough for an agent to invoke correctly.
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?
The input schema already has 100% description coverage (query and limit both described), so the baseline is 3. The description does not add much beyond mapping 'name or symbol' to the query parameter, and the schema already covers examples. No additional parameter semantics are contributed.
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 searches DeFi protocols by name or symbol and returns a ranked list with specified fields (name, symbol, TVL, category, chains, slug). This specific verb+resource+fields structure distinguishes it from siblings, especially get_protocol_tvl which is explicitly referenced.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct usage guidance by telling the user to use the returned slug with get_protocol_tvl for detailed data. This implies the correct sequence of search-then-detail, and distinguishes when to use this tool. It does not explicitly mention when not to use other siblings, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It states what the tool returns (pool name, chain, project, APY breakdown, TVL, stablecoin indicator) and discloses a notable default exclusion (impermanent-loss pools). It does not mention auth requirements, rate limits, or side effects, but the read-only nature is implied by 'Search' and the absence of mutation verbs.
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 three concise sentences: purpose, return fields, and filters/exclusion. Each sentence adds distinct value with no redundancy. It front-loads the main operation and efficiently communicates key behaviors, making it quick to parse.
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 has 5 parameters and no output schema, the description covers the essential context: what it does, what it returns, and how to filter. It also provides a default behavior (exclusion of impermanent-loss pools). Minor gaps include lack of default sort order or exact matching semantics, but the description is complete enough for effective selection and invocation.
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 baseline is 3. The description's mention of filters ('chain, project, minimum TVL, or minimum APY') simply restates what the schema already documents. It adds no new syntactic or semantic details beyond the schema, such as value formats or matching behavior.
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 uses the specific verb 'Search' and clearly identifies the resource: 'yield/APY opportunities across DeFi lending pools and staking.' It enumerates return fields and filters, distinguishing it from sibling tools like get_bridges or get_dex_volumes, which address different DeFi data domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes a clear context: this is the tool to search for yield/APY opportunities. While it doesn't explicitly name alternative tools or state when not to use it, the context is unambiguous and sufficient for an agent to select it. It also notes a behavioral default ('Impermanent-loss pools excluded by default') which implies how results are pre-filtered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It clearly states the tool returns DEX name, 24h/7d/30d volume, and 24h change percentage, and notes the ranking by 24h volume. This gives the agent a solid understanding of the output without needing an output schema.
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 concise and front-loaded: the first sentence states exactly what the tool does, and the second sentence adds return details and use cases. There is no redundant or unnecessary text, making it highly efficient for an agent to parse.
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?
Given the tool's simplicity (one optional parameter, no nested objects, no output schema), the description is complete: it explains the output fields, the ranking logic, and the intended use cases. This is more than sufficient for an agent to invoke the tool correctly without additional context.
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?
The schema already documents the only parameter, 'limit', with 'Max results (default 25)'. The description does not add any additional meaning about the parameter beyond what the schema provides, so the 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 opens with a specific verb and resource: 'Get decentralized exchange trading volumes ranked by 24h volume.' This clearly distinguishes it from sibling tools that focus on bridges, stablecoins, yields, or TVL, so the agent can readily identify what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it is 'useful for comparing DEX activity, identifying volume trends, and finding which exchanges dominate on-chain trading.' While it doesn't explicitly name alternatives or state when not to use it, the context is sufficient for typical agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the ranking criterion, the fields returned, and that revenue is included 'where available,' which is important behavioral context. It lacks details on data freshness or units but is fairly transparent for a read-only data tool.
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 main purpose, and every sentence adds value. It is concise without unnecessary fluff.
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?
There is no output schema, so the description fully explains the return values: protocol name, 24h/7d/30d fees, and 24h revenue where available. This is sufficient for a simple tool with one optional parameter.
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?
The schema covers the only parameter (limit) with a description and default, so the baseline is 3. The description does not add extra meaning beyond what the schema already provides.
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 and resource: 'Get protocol fee and revenue data ranked by 24h fees.' It also lists the return fields, distinguishing it from sibling tools like get_protocol_tvl or get_yields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases: 'comparing protocol economics, identifying which DeFi protocols generate the most fees, and analyzing revenue trends.' This implies when to use it, though it does not explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the full set of return data (current TVL, chain distribution, change percentages, category, description, website, sampled history), which is significant behavioral detail. It does not mention error handling, rate limits, or pagination, but for a read-only get tool, the output specification is strong.
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?
Two well-structured sentences: the first states the purpose and return fields, the second provides a critical prerequisite. Every sentence earns its place; no redundant words.
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?
Given the tool's simplicity (one parameter, no output schema), the description is comprehensive: it explains the input requirement, the return payload, and the prerequisite to find the slug. The level of detail is sufficient for an agent to use the tool correctly without further context.
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?
The input schema already has 100% description coverage, including examples and the instruction to use search_protocols. The tool description repeats this guidance without adding new parameter semantics, so the baseline 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 'Get' and the resource 'detailed TVL breakdown for a specific DeFi protocol by slug,' listing the exact data returned. It distinguishes itself from siblings like get_tvl_by_chain (chain-level vs protocol-level) and search_protocols (search vs retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to 'Use search_protocols to find the slug first,' providing a clear prerequisite and directing to the correct tool for finding slugs. It does not explicitly mention when not to use it or contrast with get_tvl_by_chain, but the protocol-specific scope is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It transparently lists the output fields and the ranking order (by circulating supply), making clear this is a read-only data query. It does not mention caveats like rate limits or update frequency, but it is sufficiently transparent for a simple data retrieval tool.
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 concise sentences. The first sentence front-loads the core purpose and ranking, the second lists returned fields and use cases. Every word earns its place, with no redundant content.
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 tool with one optional parameter and no output schema, the description is complete: it states the data returned, the ordering, and practical use cases. The schema covers the limit param, and the sibling tools are distinct enough that context is clear.
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?
The single parameter 'limit' is fully documented in the schema (with default and description), so the description does not need to add param details. The description does not mention 'limit', but schema coverage is 100%, so baseline 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 tool gets stablecoin market data ranked by circulating supply, and lists specific returned fields (symbol, peg type, market cap, price, chain count). This differentiates it from sibling tools like get_bridges or get_yields, which focus on other DeFi metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides use cases ('comparing stablecoin adoption' and 'identifying multi-chain stablecoins'), giving context on when to use it. However, it does not explicitly state when not to use it or name alternatives, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It transparently describes what the tool returns (chain TVL, native token symbol, IDs, top 10 tokens), implying a read-only operation. It does not mention rate limits or edge cases, but for a simple read tool, this is adequate.
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 three sentences, each earning its place: purpose, return details, and use case. It is front-loaded with the action verb and resource, with no wasted words.
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?
This is a simple tool with one required parameter and no output schema. The description sufficiently explains what the tool does, what input is needed, and what output to expect, making it complete for an agent to select and invoke correctly.
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?
The schema provides 100% coverage for the single 'chain' parameter, including examples. The description repeats those examples but adds no new parameter-level information (e.g., format, constraints, default behavior) beyond what the schema already specifies. Baseline 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 tool gets total TVL for a specific blockchain, listing example chains. It is easily distinguished from siblings like get_protocol_tvl (protocol-level) and get_dex_volumes (DEX volumes), establishing a unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case ('comparing chain activity and identifying where capital is concentrated'), but it does not explicitly mention alternatives or when not to use the tool. Sibling names imply differentiation, but the description itself lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![defillama-mcp-server MCP server](https://glama.ai/mcp/servers/friendlygeorge/defillama-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/friendlygeorge/defillama-mcp-server)

Score Badge

Copy to your README.md:

[![defillama-mcp-server MCP server](https://glama.ai/mcp/servers/friendlygeorge/defillama-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/friendlygeorge/defillama-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/friendlygeorge/defillama-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server