Loading ToolBench
MCP server + CLI that reads live Aerodrome (Base) on-chain data to rank pools by veAERO vote efficiency and recommend a self-dilution-aware vote allocation.
Two tools with strong, detailed descriptions (194 - 250 chars each) and comprehensive input schemas using Zod validation. Tool names follow verb_noun pattern (list_, recommend_). Parameters are well-typed with enums, ranges, and clear descriptions. Error handling wraps exceptions into user-friendly messages via formatError(). Output is structured JSON. Main gaps: no output schema documentation in code, no tool annotations (readOnlyHint), and parameter descriptions could be more concise for LLM parsing. Both tools are READ_ONLY and safe, but this is not declared via annotations.
Ranks all live-gauge Aerodrome (Base) pools by current and trend-predicted USD value per veAERO vote, using live on-chain data from Aerodrome's Sugar contracts plus DefiLlama USD pricing. 'Predicted' is a simple trailing average of recent epochs, not a machine-learning forecast. Each pool also reports `momentum`: the recent completed epochs' average over the older ones', minus 1 (null without enough history) — direction that the trailing average and consistency alone can't show.
Given a veAERO amount, recommends how to split votes across the current highest-efficiency Aerodrome pools using a greedy marginal-value ('water-filling') algorithm that accounts for self-dilution — voting more of your own veAERO into a pool measurably lowers your own $-per-vote there. Output is weights and expected USD only; this tool never touches a wallet, private key, or sends any transaction. The user reviews the recommendation and votes themselves on aerodrome.finance.
No tool annotations (readOnlyHint, idempotentHint) declared. Both tools are READ_ONLY and idempotent, but this is not signaled to the MCP client or agent.
Output schema not documented in code. Tools return structured JSON (poolsConsidered, poolsPassingConsistency, top array; weights, expectedUsd, etc.), but the schema is not declared in tool registration or comments for LLM consumption.
Parameter descriptions are verbose (100+ chars) and include implementation details ('trailing average', 'water-filling algorithm'). LLMs parse shorter, action-focused descriptions better. Recommend 50 - 100 chars per param.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
No pagination or result limits documented for list_pool_efficiency. Tool returns top N pools (default 20, max 100), but no total count or next_cursor. If Aerodrome has >100 pools, agent cannot discover all.
recommend_allocation accepts mutually exclusive params (veAero vs address) but does not validate at schema level. Error is thrown at runtime. Zod could use .refine() to enforce mutual exclusivity at parse time.