Loading ToolBench
Aerodrome Predictive Allocation optimizer — MCP server that forecasts next-epoch pool demand on Base and recommends incentive allocations
Strong domain-specific tool set with clear, detailed descriptions (avg 180+ chars) and well-structured schemas. All 10 tools have explicit registrations with input schemas and descriptions. Parameters are typed and constrained (enums, ranges, patterns). However, output schemas are not formally documented in the code, responses are shaped ad-hoc via json() helper. Tool names are action-oriented (scan_, predict_, recommend_, detect_, backtest_, prepare_) and unambiguous. Error handling is present but minimal (basic err() helper). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Composition is excellent, tools chain naturally (scan_pools → pool_history → predict_demand → recommend_allocation → prepare_vote_calldata). Parameter naming is consistent and domain-appropriate (pool, votingPowerVe, bribeBudgetUsd). Defaults are sensible and non-destructive.
Walk-forward backtest against live Base data: replay completed epochs, forecast each with only the history available at the time, and score against realized fees and a naive 'predict = last epoch' baseline. Returns overall accuracy metrics (MAE, RMSE, WAPE, directional accuracy), confidence calibration buckets, and worst misses.
Detect pools where bribes or votes are running well off their normal pace — the 'incentivized pool draining regular pools right before lock' pattern. Returns risers (pools with unusually high bribes relative to their history, often pulling votes) and fallers (pools losing votes to the risers).
Per-epoch history for one Aerodrome pool: votes, AERO emissions, trading fees (USD) and bribes/incentives (USD) per weekly epoch, newest first (first row is the in-progress epoch).
Forecast next-epoch trading-fee demand for top Aerodrome pools and compare it with current vote allocation. Key output: predictiveEdgePct — pools with positive edge are under-incentivized relative to predicted demand (the signal a Predictive-Allocation-style mechanism would reward). Data is cached ~5 min.
Encode a vote allocation into unsigned Voter.vote() call data for submission to the Aerodrome Voter contract. Takes an allocation recommendation and returns the raw transaction calldata (not signed — signing and submission belong to the host agent's wallet layer).
Output schemas not formally documented. Responses are shaped via json() helper with ad-hoc field selection. LLMs cannot predict response structure without calling the tool.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Clients cannot infer safety properties without explicit hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Compares logged voter_roi recommendations (written by epoch-reminder, when AERO_VOTING_POWER is set) against what actually happened, for every logged epoch that has since completed. Returns skill metrics showing how well predictions matched realized rewards.
Produce a concrete incentive-allocation recommendation across Aerodrome pools. Three objectives, three different questions: protocol_efficiency = the market-wide ideal (weights ∝ predicted next-epoch fee demand) — a benchmark, not personalized. voter_roi = maximizes YOUR expected reward for votingPowerVe AERO, accounting for self-dilution (your votes shrink the per-vote payout) — pass your real AERO amount for sized weights; this is the one to use for 'where should I actually vote'. edge_hunter = chases the biggest, most-trustworthy mispricings (predictiveEdge × confidence) rather than raw demand or dilution-optimal ROI — not dilution-aware, pairs well with voter_roi to size the result. Returns weights that sum to 100%.
For a team/protocol deciding where to spend a bribe budget (not a voter deciding how to vote): estimate how much AERO vote share a bribe would pull toward one pool. Models a full re-optimization of the market's active voting power by payout (votes scale with the square root of pool payout), so a bribe dollar pulls disproportionately more on cheap/low-payout pools than on already-large ones — an optimistic upper bound, since real voters re-vote slowly. Also reports which other pools lose the most votes as the market rebalances.
Forward-looking staking-yield ranking for LPs deciding where to deposit and stake liquidity — deliberately NOT trading-fee revenue: on Aerodrome, fees and bribes accrue to AERO voters, not to liquidity stakers (see recommend_allocation), so this ranks by predicted AERO emissions instead, the actual staker reward. predictedNextEpochAprPct forecasts next-epoch emissions from each pool's emissions history the same way predict_demand forecasts fees; currentEpochAprPct uses this epoch's already-fixed live emission rate (no forecast error).
Scan Aerodrome (Base) gauge-enabled pools with live TVL, staked TVL, fee tier and emissions. Sorted by staked TVL. Use this for a market overview before predicting demand.
Error handling is minimal. err() helper returns isError=true but no recovery guidance. Tools should return actionable error messages (e.g., 'Pool not found. Try scan_pools() to discover valid pools.').
realized_performance tool has empty input schema (no parameters). Description is brief (80 chars). Unclear what triggers the computation or how to filter results.
Parameter descriptions lack format/constraint hints. E.g., 'votingPowerVe' description does not explain units (AERO tokens? wei?). 'pool' pattern is documented but not explained in description text.