aero-allocator
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BASE_RPC_URL | No | Base RPC URL | https://mainnet.base.org |
| AERO_MIN_TVL_USD | No | Minimum TVL in USD for pool candidates | 50000 |
| AERO_MAX_CANDIDATES | No | Maximum number of pools to analyze | 60 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_poolsA | 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. |
| pool_historyA | 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). |
| predict_demandA | 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 Predictive Allocation rewards). Data is cached ~5 min. |
| recommend_allocationA | Produce a concrete incentive-allocation recommendation across Aerodrome pools. objective=protocol_efficiency allocates proportional to predicted next-epoch fee demand (the Predictive Allocation ideal); objective=voter_roi maximizes expected reward per veAERO vote with a 25% per-pool concentration cap. Returns weights that sum to 100%. |
| prepare_vote_calldataA | Build unsigned transaction calldata for Aerodrome Voter.vote() from an allocation (veAERO NFT id + pool weights). Returns { to, data, value } for the host wallet (e.g. Base MCP send/send_calls) to review, sign and submit — this server never signs. Note: votes can only be cast once per epoch per veNFT, and not in the final hour before epoch flip. |
| predictive_allocation_statusA | Status of the direct Predictive Allocation submission path (Aerodrome's July 2026 mechanism replacing weekly gauge voting). Reports whether live contracts are wired into this server. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a distinct aspect of Aerodrome allocation: history, demand prediction, mechanism status, vote calldata preparation, allocation recommendation, and pool scanning. There is no overlap; descriptions clearly differentiate their purposes.
Most tool names follow a clear verb_noun pattern (predict_demand, scan_pools, prepare_vote_calldata, recommend_allocation), but two are noun phrases (pool_history, predictive_allocation_status). The naming style remains consistent with snake_case and descriptive terms.
With 6 tools, the server is well-scoped for its domain. Each tool serves a necessary function in the allocation workflow, neither too few to be incomplete nor too many to be unwieldy.
The tool set covers the full lifecycle: scanning for overview, historical data, demand prediction, allocation recommendation, and vote calldata construction. There are no obvious gaps for the intended purpose of optimizing Aero vote allocation.