DeFi Intelligence Engine

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct category or action (e.g., best yield, gas price, contract scoring, alerts). The get_best_* series clearly differentiate by asset/protocol type, and comparison tools are separated by domain. Descriptions include usage notes to avoid confusion.
Naming Consistency5/5
All tool names follow snake_case with a consistent verb_noun pattern (compare_, explain_, get_, score_, yield_alert_). The get_best_ prefix is used uniformly for recommendations, and alert tools share a yield_alert_ prefix, creating a clear and predictable naming scheme.
Tool Count5/5
With 17 tools covering yield, staking, restaking, RWA, perps, gas, allocation, alerts, and security, the count is well-scoped for a DeFi intelligence server. Each tool serves a distinct purpose without redundancy, and the count is neither too few nor too many for the domain.
Completeness4/5
The tool surface covers core DeFi intelligence needs: best picks, comparisons, risk analysis, gas optimization, allocation, and alerts. Minor gaps include lack of comparison tools for liquid staking and restaking, and no direct endpoint for detailed single-protocol data beyond recommendations. Overall, it's comprehensive but not exhaustive.
Average 4.1/5 across 17 of 17 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
Add a glama.json file to provide metadata about your server.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'detailed analysis of risk' without disclosing what that entails (e.g., read-only, data sources, permissions, or side effects). The agent is left guessing about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, which is concise but lacks detail. It is appropriately front-loaded but under-specified, earning a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to explain what the analysis returns or how to interpret results. With zero parameter descriptions and no annotations, the tool is insufficiently documented for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain parameter values, formats, or defaults (e.g., chain defaults to 'all'). The description 'for a specific protocol for an asset' adds minimal meaning beyond the parameter names.
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 it performs a detailed risk analysis for a specific protocol and asset. This distinguishes it from sibling tools like compare_perps, get_best_yield, etc., which focus on different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, scenarios, or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral traits are disclosed beyond the basic comparison. Since annotations are absent, the description should detail data freshness, scope, or limitations. It only states the comparison dimensions without any side effects or constraints.
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?
The description is a single concise sentence with no fluff. It is front-loaded and efficient, though it could include slightly more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is sparse for a comparison tool. It does not explain what 'volume and activity' encompass or what the output format is. Given no annotations, more context is needed for adequate completeness.
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 baseline is 3. The description adds modest value by mentioning volume and activity as comparison criteria, but the parameter description in the schema already provides examples. No further semantic enrichment.
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 compares perpetuals protocols side-by-side by volume and activity. It specifies the resource (perpetuals protocols) and the comparison dimensions (volume and activity), distinguishing it from siblings like compare_yields or get_perps_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_perps_overview or compare_yields. The description does not mention prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It fails to disclose behavioral traits such as side effects, rate limits, authentication needs, or return characteristics beyond the basic comparison. The term 'risk-adjusted' is vague.
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?
The description is a single sentence that is front-loaded with key action. However, it is in French, potentially confusing for English-speaking agents, slightly reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high schema coverage and an output schema, the description lacks context on what the comparison entails (e.g., APY, risk score, TVL). It does not mention the allowed protocol count (2-6) or default chain behavior, leaving gaps for an agent.
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% with clear parameter descriptions. The description adds no additional meaning beyond the schema. 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 performs a side-by-side risk-adjusted comparison of protocols. This specific verb+resource combination distinguishes it from siblings like compare_perps (perpetuals comparison) and get_best_yield (single best yield).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description does not mention exclusions, prerequisites, or links to sibling tools. An agent lacks context to decide between compare_yields and similar tools like explain_risk.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only says 'Delete' and 'FREE', which is ambiguous. It does not disclose that deletion is destructive, irreversible, or requires permissions. With no annotations, the description should carry this burden but fails.
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?
One concise sentence with no filler. However, 'FREE' is slightly redundant and could be integrated or omitted. Efficient but could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete with one param and output schema present, the description is adequate but lacks details about return values or side effects. It meets minimum viability.
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% with parameter description for alert_id. The tool description adds no additional semantics beyond the schema (e.g., format constraints). Baseline score of 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?
Description clearly states verb (delete), resource (yield alert), and method (by ID). It distinguishes from sibling tools like yield_alert_set (create) and yield_alerts_list (list) and includes 'FREE' as extra clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like yield_alert_set or yield_alerts_list. The description does not specify prerequisites or context for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the tool returns JSON with alerts, status, and age, which implies read-only behavior, but does not explicitly declare side-effect-free or mention authentication, rate limits, or other behavioral traits.
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 concise sentences. First sentence states purpose, second provides usage context, third outlines return format. 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?
The tool has an output schema, so description does not need full return details. It succinctly describes that it returns JSON with alerts, status, and age. No missing information given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema fully covers the interface. The description does not need to add parameter details. Baseline for 0 params is 4.
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?
Clearly states 'List all active yield alerts' with a specific verb and resource. Differentiates from sibling tools like yield_alert_check and yield_alert_set by focusing on listing all active alerts. Provides additional context for agents managing multiple positions.
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?
Mentions it is 'useful for agents managing multiple positions,' which gives some context, but lacks explicit guidance on when to use vs. alternatives like yield_alert_check. Does not specify when not to use or provide 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?
No annotations provided, so description carries full burden. It explains output (safe/standard/fast prices in Gwei with USD estimate) and notes it's free, but does not disclose if it's read-only, rate limits, or potential errors.
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 sentences, no wasted words. Front-loaded with purpose, then output details, then usage guidance. Perfectly structured for an agent to quickly grasp.
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 tool with one parameter and existing output schema, the description covers essential usage, output, and follow-up. Could mention return structure, but output schema handles that.
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 baseline 3. The description adds value by stating the chain parameter and default, but the schema already describes it well with example options.
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 'Get current gas prices across urgency levels for a given chain' with a specific verb and resource, and distinguishes from sibling tool 'get_optimal_gas_window' by noting it as a follow-up.
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 states 'Use this when: an agent needs current gas cost before executing a transaction' and suggests a subsequent tool, providing clear context and alternatives.
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 provided, so description carries full burden. States it uses cached data, is non-destructive, and returns specific fields. Does not mention error handling or authentication, but for a simple read-only tool, it's fairly transparent.
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?
Very concise at 4 sentences; front-loaded with the core action. Every sentence adds value: polling action, freeness, caching, return fields. No redundant information.
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 simplicity of the tool (1 param, no nested objects) and presence of output schema, the description covers the essential: what it returns and that it's safe. Minor missing details on error states, but not critical for a poll 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%, and the input schema already provides clear meaning for 'alert_id' with context ('Alert ID from yield_alert_set' and example). The description adds no additional parameter semantics beyond what is in the schema.
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?
Description clearly states it polls yield alert status, using specific verb 'poll' and resource 'yield alert'. Distinguishes from siblings like yield_alert_set (create) and yield_alert_delete (delete) by focusing on status checking.
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?
Explicitly says 'FREE' and 'Safe to call frequently', guiding the agent on when to use (frequent polling). Does not explicitly state when not to use, but context from sibling tools implies it's for status checks only.
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 discloses key behaviors: alert fires when get_best_yield finds an opportunity exceeding threshold_apy, returns alert_id, persists in server memory, and is free. It lacks details on persistence duration or rate limits, but covers the essential traits.
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 with the core action. It uses short sentences to convey key points without redundancy, making it easy to parse quickly.
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 simple nature of the tool and the presence of an output schema, the description covers the trigger condition, return value, lifecycle, and usage context. It does not discuss error handling, but that is acceptable for this 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%, so the schema already documents parameters. The description adds minimal extra meaning beyond stating that threshold_apy triggers the alert and risk_profile affects yield calculations, which is consistent with the schema.
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 registers an APY threshold alert, returns an alert_id, and explicitly distinguishes it from sibling tools like yield_alert_check, yield_alert_delete, and yield_alerts_list.
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 explicit use cases: 'Use this when: an agent wants to be notified... without continuously calling get_best_yield.' It also mentions related tools for checking and deleting alerts, but does not explicitly state when not to use it.
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 provided, so the description carries the full burden. It discloses scoring criteria and output format (one recommendation with reasoning and alternatives). However, it lacks details on data freshness, failure modes, or response time. For a recommendation tool, this is good but not exhaustive.
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?
Description is efficiently structured: main action in first sentence, scoring details, then usage guidance. No superfluous words, all information is relevant and front-loaded.
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 3 optional parameters, an output schema, and no annotations, the description covers core purpose, usage context, alternatives, and scoring criteria. It does not detail the return structure, but the output schema compensates. Slight gap in explaining potential limitations or data sources.
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% with clear descriptions for all three parameters. The description adds overall context but does not enhance parameter semantics beyond what the schema already provides. 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 selects the best liquid staking protocol for a given asset and risk profile, lists scoring criteria (TVL, audit count, age, momentum), and enumerates covered protocols. This specificity and verb+resource structure distinguish it from siblings.
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 states 'Use this when: an agent needs to stake an asset while keeping it liquid.' and 'Do NOT use for: yield farming (use get_best_yield), restaking (use get_best_restaking).' This provides clear context and alternative tools.
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 that it uses GoPlus Security API, checks multiple risks, and returns a score 0-100. However, it lacks details on error handling (e.g., invalid address, unsupported chain) and potential side effects like API rate limits, which would improve transparency.
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 five sentences with clear sections: main action, detailed checks in bullet-like format, and usage guidelines. It is front-loaded with the core purpose and uses no unnecessary words, making it efficient and easy to scan.
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?
With output schema present (return values not needed) and full schema coverage, the description covers the tool's functionality, usage when/not, and specific checks. It lacks mention of error conditions or edge cases like unsupported chains, but overall it is sufficiently complete for a scoring 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 both parameters well-described in the schema (example address, chain list). The description adds minor context (e.g., 'tokens and general contracts') but does not significantly enhance meaning beyond the schema. 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 scores a smart contract for security risks using GoPlus Security API, listing specific checks and a risk score range 0-100. It explicitly distinguishes from sibling tool 'explain_risk' by stating when not to use it and what alternative to use, making the purpose unambiguous.
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?
The description provides explicit guidance: 'Use this when: an agent is about to interact with an unknown contract or token. Do NOT use for: known safe protocols (use explain_risk for Aave/Morpho/etc.)'. This clearly indicates when to use the tool and when not, along with a specific alternative.
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 exist, so description covers key behaviors: returns volume, open interest, market share, and covers 50+ protocols. Lacks mention of data freshness or limits, but sufficient for a read-only overview.
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?
Description is concise at 4 sentences with clear structure: action, examples, use-case guidance. No redundant 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?
With output schema present, description adequately covers purpose, usage, and return fields. Complete enough for an agent to correctly invoke 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 coverage is 100% with clear descriptions for chain and top_n. The tool description does not add additional parameter semantics beyond what the schema already provides, meeting the baseline.
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 identifies top perpetuals/derivatives protocols ranked by 24h volume, specifies examples like Hyperliquid, dYdX, etc., and distinguishes it from sibling tools such as compare_perps and get_defi_overview.
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 provides when to use ('derivatives market intelligence') and when not to use ('spot DEX', 'yield') with alternative tool names (DeFiLlama DEX endpoints, get_best_yield).
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 provided, so description carries full burden. It discloses it returns JSON with market leaders, TVL, and quick stats, and notes it is free. Lacks details on data freshness or rate limits, but sufficient for a no-parameter read-only tool.
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?
Description is reasonably concise with 4-5 sentences, covering purpose, usage, and output. Could be slightly more structured (e.g., bullet points for return fields) but is efficient overall.
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 zero parameters and no output schema (though context indicates output schema exists), the description sufficiently explains the output format and content. It fully covers what an agent needs to decide whether to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description adds no parameter info. Baseline 4 is appropriate since schema coverage is 100% and the description correctly implies no inputs needed.
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 it returns a 'Complete DeFi market snapshot across all categories' and lists specific categories (Yield, Liquid Staking, etc.). It distinguishes itself from sibling category-specific tools by positioning itself as the first call.
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 says 'Use this as a starting point before calling category-specific tools' and mentions it is FREE, guiding the agent to use it to decide which paid tool to call next. This provides clear when-to-use and alternative context.
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 bears full burden. It discloses that the tool 'returns a weighted multi-protocol allocation' that 'maximizes APY while respecting TVL constraints and risk limits.' It does not explicitly state read-only nature, but the description implies a computational/planning role. Missing explicit read/write disclosure but still informative.
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 succinct (two short paragraphs plus a guidance line). It is front-loaded with the core purpose, then differentiates, then provides usage rules. Every sentence adds value without 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?
Given the tool's complexity (5 parameters, output schema, sibling tools), the description covers purpose, differentiation, usage guidelines, and behavioral constraints. It does not explain the output format, but the output schema exists to handle that. It could mention what happens if risk_profile is out of bounds, but overall it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context beyond parameter descriptions: 'respecting TVL constraints and risk limits' relates to risk_profile and max_protocols; 'diversification' connects to max_protocols; 'amounts >$10,000' adds practical use guidance for total_amount_usd.
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's purpose: 'Split capital optimally across multiple DeFi protocols for maximum risk-adjusted yield.' It uses a specific verb and resource, and explicitly differentiates from the sibling tool 'get_best_yield' by noting it handles multi-protocol allocations.
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?
The description provides explicit when-to-use ('an agent needs to deploy capital across multiple protocols') and when-not-to-use ('single-protocol analysis') with alternative tool names ('get_best_yield or explain_risk'). It also adds a threshold recommendation ('amounts >$10,000').
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 reveals it uses historical gas patterns (hourly + day-of-week multipliers), typical savings (25-45%), and best windows (3-7 AM UTC, weekends). It doesn't mention data freshness or limitations, but adequately describes behavior for a prediction 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?
Five efficient sentences: purpose, method + savings, best windows, usage guidance, and combination tip. Every sentence provides unique value, with no redundant or missing information.
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 output schema exists (covers return values), the description adequately explains when to use (deferral), how it works (historical patterns), and context (savings, windows). It could mention other supported chains from schema, but overall sufficient for a prediction tool with optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds value by explaining typical savings and best windows, which helps users interpret parameters like urgency and horizon_hours. However, it doesn't elaborate on the 'chain' parameter beyond mentioning Ethereum in examples.
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 predicts the best time window for minimum gas cost, with specific verb+resource. It implicitly distinguishes from sibling get_gas_price by saying 'Combine with get_gas_price for current baseline', making differentiation clear.
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?
Provides explicit 'Use this when:' usage guidance: deferring a non-urgent transaction to save gas. Also suggests combining with get_gas_price for baseline, indicating alternative when immediate execution is needed.
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?
Describes scoring dimensions (TVL, audits, age) and coverage, but could elaborate on what 'best' means or if it's read-only. No annotations to verify idempotency.
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 clear paragraphs: first states purpose and scope, second provides usage guidelines. No superfluous 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?
Covers purpose, scope, criteria, and usage boundaries. Output schema likely details return format, so no additional info needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters; description adds threshold values for risk_profile and enum details for restaking_type, enhancing schema descriptions.
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 specific verb 'Select' and resource 'best restaking protocol', lists covered protocols (EigenLayer, Symbiotic, etc.), and explicitly distinguishes from sibling 'get_best_liquid_staking'.
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?
Provides explicit when to use ('agent wants to restake ETH or LSTs') and when not to use ('simple staking' with alternative tool named). Also outlines scoring criteria (TVL, audits, age).
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?
Despite no annotations, the description explains the scoring criteria (TVL, audits, age) and covers the selection behavior. It could be more explicit about the output format, but the existence of an output schema likely covers that.
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 front-loaded sentences plus a clear usage guideline paragraph. No unnecessary words, every sentence adds value.
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 only 2 optional parameters and an output schema, the description fully covers the tool's purpose, selection criteria, types, and usage boundaries. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions. The description adds value by listing example protocols (Ondo USDY, BlackRock BUIDL) and explaining the scoring, which helps the agent understand parameter effects.
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 selects the best RWA protocol by TVL and risk profile, listing specific protocols and types (t-bills, private credit, real estate). It distinguishes from sibling tools like get_best_yield by specifying off-chain vs on-chain yields.
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 states when to use ('stable off-chain backed yield') and when not to use ('on-chain DeFi yields'), with a direct reference to the alternative tool (get_best_yield).
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 provided, but description discloses scoring mechanism (9-signal algorithm, 13,800+ pools), output format (reasoning + 2 alternatives, ~60 tokens), and what the tool does not do (list all). Slight gap on side effects, but it's a read-only analysis 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?
Well-structured with clear sections; every sentence is informative and necessary. Front-loaded with main purpose, then details, guidelines, and output size.
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?
Comprehensive for a DeFi yield selection tool: covers scope, algorithm, output, when/not to use, and parameter details. Output schema exists but not shown; description still feels complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions. Description adds context like risk_profile thresholds, amount_usd minimum TVL filter (10x), and chain examples, exceeding what schema 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?
Description clearly states it selects the single best DeFi yield opportunity for an asset and risk profile, distinguishing it from sibling tools like compare_yields and explain_risk.
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 provides 'Use this when' and 'Do NOT use for' sections, directing to alternatives (compare_yields, explain_risk) for other tasks.
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:

[![defi-yield-engine MCP server](https://glama.ai/mcp/servers/danteriva45-hub/defi-yield-engine/badges/card.svg)](https://glama.ai/mcp/servers/danteriva45-hub/defi-yield-engine)

Score Badge

Copy to your README.md:

[![defi-yield-engine MCP server](https://glama.ai/mcp/servers/danteriva45-hub/defi-yield-engine/badges/score.svg)](https://glama.ai/mcp/servers/danteriva45-hub/defi-yield-engine)

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/danteriva45-hub/defi-yield-engine'

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