🔒 PREMIUM (requires x402 payment, $0.03): Deep scan a specific pool or token — APY breakdown (base + reward), TVL, risk score, IL exposure, 30d average. Search by name, symbol, or pool ID. → Call via https://tooloracle.io/x402/yield/mcp/ with X-PAYMENT header. New wallets get 5 free units auto-applied.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Token or protocol name (e.g. 'USDC', 'aave') | |
| pool_id | No | DeFiLlama pool ID for exact match |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / additionalPropertiesAdded value: +falseDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses key behaviors: it is a premium tool requiring x402 payment ($0.03), the HTTP call endpoint, the required X-PAYMENT header, and the free 5-unit allocation for new wallets. It also specifies the returned data fields. It does not mention rate limits or failure modes, but the core behavioral traits are covered.
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 a single dense sentence that front-loads the premium nature and payment requirement. It is efficient with no redundant filler, though the emojis and capitalization add visual noise. All content contributes to understanding the tool.
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 tool returns APY, TVL, risk, IL, and 30d average; the description lists these without an output schema. It covers the access mechanism (payment, endpoint, header), search capabilities, and free trial. Missing: error behavior or edge cases, but the essential operational context is present.
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 coverage is 100%, so baseline is 3. The description adds meaning beyond schema by clarifying that 'query' accepts token or protocol name (also symbol) and pool_id is an exact match via DeFiLlama ID. It also indicates that searches work by name, symbol, or pool ID, which enriches the schema's sparse descriptions.
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 uses a specific verb 'Deep scan' and clearly identifies the resource: 'a specific pool or token'. It enumerates the output metrics (APY breakdown, TVL, risk score, IL exposure, 30d average) and search methods (name, symbol, pool ID), making it distinct from sibling tools like top_yields or chain_yields.
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 implies use when in-depth details on a specific pool/token are needed, contrasting with higher-level yield lists. It does not explicitly name alternatives or exclusions, but the context is clear enough to guide selection. Payment requirement is stated upfront, which is important use-case context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have distinct purposes: health_check is unique, while yield_compare, yield_scan, and rwa_yield are clearly specialized. However, chain_yields, stablecoin_yield, and top_yields all provide yield rankings, differing only by filter (chain, stablecoin, global), which could cause some confusion despite clear descriptions.
All tool names use lowercase_with_underscores and mostly follow a noun/noun or noun/verb pattern (e.g., chain_yields, stablecoin_yield, yield_compare, yield_scan). The pattern is consistent in style, though not strictly verb_noun for all (e.g., rwa_yield, health_check are exceptions).
With 8 tools, the set is well-scoped for a DeFi yield aggregator. Each tool covers a distinct niche (global, chain, stablecoin, RWA, risk-adjusted, comparison, deep scan, health), and there is no redundancy that would benefit from removal.
The tool surface covers the main yield discovery needs: top yields, chain-specific, asset-class filters, risk adjustment, comparison, and deep pool analysis. Missing features like historical yield trends or protocol-specific filtering are minor gaps that agents can work around with existing tools.