A read-only Aerodrome (Base) veAERO gauge-voting toolkit: it scans pools, forecasts next-epoch fee demand, recommends vote weights, and builds unsigned Voter.vote() calldata — but it is built on the weekly-vote era that Aero has since replaced.
scan_pools — market overview: gauge-enabled Aerodrome pools sorted by staked TVL with TVL, staked TVL, fee tier and emissions; filter by limit (1–100) and minTvlUsd.
pool_history — per-epoch history for one pool (votes, AERO emissions, trading fees USD, bribes/incentives USD), newest first, 2–50 epochs.
predict_demand — forecasts next-epoch fee demand vs current vote allocation, with predictiveEdgePct flagging under-incentivized pools; sortable by predicted fees, edge or voter ROI; ~5 min cache or forced refresh.
recommend_allocation — weights summing to 100% across 2–20 pools, either proportional to predicted fee demand (protocol_efficiency) or reward-maximizing per veAERO (voter_roi, 25% per-pool cap).
prepare_vote_calldata — unsigned { to, data, value } for Voter.vote() from a veNFT id plus up to 30 pool weights; never signs, and notes the one-vote-per-epoch / no-vote-in-final-hour rules.
predictive_allocation_status — reports whether the July 2026 Predictive Allocation contracts are wired into this server.
Caveats: Aerodrome/Base only (no sAERO, no multi-chain), every tool has taskSupport: forbidden (nothing executes), and its weekly-vote premise is obsolete — the project removed its own weekly-vote engine after Aero replaced voting, so the vote calldata path is largely superseded.
Provides tools for forecasting next-epoch demand and allocating incentives across Velodrome (Optimism) liquidity pools, including vote recommendations, bribe placement, and calldata preparation for veVELO voters.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@aero-allocator predict demand for top 5 Aerodrome pools"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
https://aeroallocator.app is the sAERO allocator for Aero (the merged Aerodrome and Velodrome, live since 2026-10-22): which gauges pay the most per day for your amount of sAERO, what your positions earn, and an allocate / return-to-idle flow signed in your own wallet. It is free, has no accounts, and never holds keys. Figures are estimates from recent on-chain fee releases, not financial advice.
This repository holds:
web/: the Next.js site above, plus its free and paid (x402) APIs. This is the live product. Start with The site.
skills/: two agent skills (re-allocate a position only when it is worth it; check or prepare a veAERO to sAERO upgrade). See Agent skills.
scripts/: the CI audit gate. (The weekly-vote MCP engine that used to live in src/ was removed after Aero replaced weekly voting; it is in git history, last present in commit 1f94d77.)
What it does (all in web/, one page):
Gauges: every Aero gauge on Base (and the other Aero chains) ranked by what your amount earns per day after it dilutes the gauge, with an estimated APR, a "power flow" column (which gauges are gaining or losing share of the allocation weight), a Steady column (how evenly a gauge paid), flags for gauges whose incentives just appeared, and a per-gauge history chart (6-hour bars, plus a per-day chart from a 90-day record). The best split across up to six gauges is solved for you.
Your positions: paste an address or connect a wallet. Positions are read in the browser over public RPC, so the address never reaches our server. Each shows size, lock, how much is allocated, the 47-hour wait (with a "remind me" calendar file, built in the browser), what it earns now vs the best split and so what staying costs per day, and the trading fees it has earned and not claimed. Allocating simulates the transaction on-chain before your wallet is asked to sign.
Notes it keeps honest: the 47-hour wait belongs to each position, an existing position can't be split, a position with no AERO staked is usually an Aero Autopilot key, and fee figures are a recent pace, not a promise.
How the numbers are made: gauge weight is read from Aero's contracts; fees come from the fee releases (NotifyFeesAmount logs) over
the last 48 hours, with each gauge's first release left out; incentives are the streaming programs on each gauge. A yield per gauge is
(fees + incentives) × amount / (weight + amount). Against Aero's own pages, total allocation matched and APR was within about a point
or two on the pools compared.
Free, rate limited, no key. Described for agents at /llms.txt (plain text) and /openapi.json (OpenAPI 3.1, including the paid routes' 402 behaviour):
Endpoint | |
| Every gauge on a chain with weight, caps and incentives; the Base list also carries |
| Estimated fees per day per gauge, the hours of history behind each figure, a steadiness figure, and a |
| One gauge's fees per 6 hours, weight snapshots, steadiness, and per-day points from the 90-day record |
| How each gauge's share of the allocation weight moved over the last day, and gauges whose incentives just appeared |
| best split of an amount over every chain, after the ETH each extra chain costs (read-only) |
| ETH cost on Base of sending power to another chain |
| USD prices for up to 12 Base token addresses (lets the page value earned fees without sending a position anywhere) |
| The 1200×630 share card (also the link preview) |
Paid (x402), below: Paid API (x402).
cd web && npm install && npm run devOpen http://localhost:3000. Checks, in web/: npx tsc --noEmit, npm run lint, npm test, npm run build; in the root: npm install && npm run typecheck && npm test (the skills' and the audit gate's tests), and npx tsx scripts/audit-gate.ts . and ... web (CI runs all of them; the audit gate fails on any advisory except the one accepted advisory listed in scripts/audit-gate.ts).
History is kept by Vercel Cron: six crons (one per chain, web/vercel.json) call /api/gauge-fees/ingest every 30 minutes, which
extends the fee record (4 days), takes a weight snapshot (3 days) and, once a UTC day has finished, adds it to the daily record
(90 days). On Base the same cron also writes down, once a UTC day, the split the site would recommend for 10,000 sAERO (track-record-8453.json), so /api/track-record can show later how that advice compared with what the gauges paid. All of these live in private Vercel Blobs. The route requires CRON_SECRET as a bearer token (Vercel Cron sends
it by itself); a deployed site without it refuses every call, so history stays empty until it is set.
web/)Var | ||
| optional | A dedicated RPC, and a second one for failover. Without them public nodes are used, which works but is slower and rate limited |
| needed for history | Vercel Blob token for the fee, weight and daily records. Without it the site works but shows no history |
| needed for history | Locks |
|
| Public address, for the link-preview image |
| unset | Free Reown Cloud project id (the domain must be on its allowlist). Enables WalletConnect; without it that connector is left out because its relay socket would hang the tab |
| for the paid routes | See Paid API (x402) |
The site lives in web/, which Vercel's zero-config detection doesn't find at the repo root, so the project needs a couple of non-default settings:
Setting | Value | Why |
Root Directory |
| Vercel's Next.js detection checks this directory's |
Install Command |
| Must be a real install, not a no-op: Vercel checks the installed Next.js version immediately after this step, before running Build Command |
Build Command | default ( | The project may still carry the older |
Output Directory | default ( | Resolved relative to Root Directory: do not prefix with |
Root Directory isn't exposed as a vercel CLI flag; set it via the dashboard (Project Settings →
General) or the API (PATCH /v9/projects/{id} with {"rootDirectory": "web"}). Env vars (see the table above) go in Project
Settings → Environment Variables, per environment (Production/Preview), and take effect on the next deployment. A dedicated RPC (Alchemy,
Infura) is strongly recommended over the public default — it's the difference between a ~20s and a
~1min cold snapshot build, which matters against Vercel's function timeout (60s ceiling on Hobby).
Vercel's Deployment Protection (an SSO auth wall) is on by default for all deployments including
production. To make production public while keeping preview deployments protected, set
ssoProtection.deploymentType to "preview" via the API (also not a dashboard toggle at the time of
writing).
Rate limits: two Vercel Firewall rules (not stored in this repo; they live in the project's Vercel config) cap each IP at 300 requests a minute across /api, and at 30 a minute on the routes that read several chains or logs (all-chains-split, top-gauges, v1/cross-chain-plan, gauge-history, allocation-fee); beyond that Vercel answers 429 with an x-vercel-mitigated header, and the IP is let back in within about a minute. They add a limit shared across servers to the per-route, per-instance limiter in web/lib/rate-limit.ts. Set up 2026-10-31 with the CLI: vercel firewall rules list shows them, vercel firewall rules inspect "<name>" the details, vercel firewall rules disable|remove "<name>" then vercel firewall publish undoes one; to recreate them: vercel firewall rules add "Rate limit: whole API" --condition '{"type":"path","op":"pre","value":"/api"}' --action rate_limit --rate-limit-requests 300 --rate-limit-window 60 --rate-limit-keys ip --yes, the same with one --condition per route joined by --or and 30 requests for the second, then vercel firewall publish. A busy shared IP (an office, a mobile carrier) could hit the 300 limit; raise it then.
Preview builds are skipped: web/vercel.json has an ignoreCommand that exits 0 only when VERCEL_ENV is preview (anything else, or an unset variable, builds), because every pull request's preview and its merge build both cost build minutes and the October bill's biggest line was Build CPU. GitHub's CI still builds and tests each pull request. Delete the ignoreCommand line to get previews back.
Related MCP server: aero-vote-radar
Two skills in skills/, for agents that act on a sAERO position. Neither signs or sends anything; the owner's wallet layer does.
Skill | What it does |
Once the wait is over, checks a position and re-allocates it only for a real, steady gain (never a one-off fee burst), checks the unsigned | |
Checks a wallet's old veAERO locks against Aero's migration contract (what each becomes, what blocks it) and, only after the owner confirms each lock, prepares the unsigned |
The root SKILL.md is the overview of the APIs for agents. The skills are in this public repo, so no separate publishing is needed; install them with the skills CLI (the root skill hides the others unless you pass --full-depth):
npx skills add Hryhorii77/aero-allocator # the overview skill
npx skills add Hryhorii77/aero-allocator --full-depth --skill saero-allocator-automator # re-allocate when it is worth it
npx skills add Hryhorii77/aero-allocator --full-depth --skill veaero-to-saero-upgrade # check and prepare an upgradeReview a skill before you use it: it runs with your agent's permissions.
packages/mcp)aeroallocator-mcp is a dependency-free MCP server (stdio, Node 22+) over the site's free, read-only APIs: top_gauges, best_split_all_chains, power_flows, gauge_history, allocation_fee and track_record. It never signs or sends anything and needs no key. Once published: { "mcpServers": { "aeroallocator": { "command": "npx", "args": ["-y", "aeroallocator-mcp"] } } }. See packages/mcp/README.md.
Publishing is manual and needs an npm login: cd packages/mcp && npm publish (the name was free on 2026-10-30; tests run in the root npm test). Until then it can be run from a clone: node packages/mcp/bin/aeroallocator-mcp.mjs.
Two pay-per-call sAERO endpoints on the site's own deployment, in USDC on Base via the x402 protocol, settled by
Coinbase's CDP facilitator only after a successful answer (a 400/404/422 is never charged). The free site is unaffected.
All three are listed in Coinbase's x402 Bazaar (and so agentic.market): position and allocate-plan since their first settled payments on 2026-10-26, cross-chain-plan since its first on 2026-10-28 (the call that took three attempts: see the 500-character description limit in CLAUDE.md). They are described for agents at /llms.txt and /openapi.json.
Endpoint | Price | What it answers |
| $0.05 | Where does this sAERO position stand: power, lock, idle vs allocated, the 47-hour re-allocation wait, what it earns per day now vs the best split of Base gauges for its own size, and a stay / switch / allocate / unknown recommendation. |
| $0.10 | The unsigned, already-simulated |
| $0.25 | The ordered, unsigned |
These answer something the free /api/gauges and /api/gauge-fees reads can't: a chain read keyed to one position, and calldata that
satisfies the Voter's rules (full overwrite per chain, exact total, ascending addresses). The old weekly-vote /api/v1/forecast earned
almost nothing because the free site served the same payload; keep new paid routes on the "free can't do this" side.
Requires three env vars to activate; without all three each paid route serves a clean 501 rather than accepting payment:
Var | ||
| Base address you control | Where payments land: never generated or held by this codebase |
| Coinbase Developer Platform API key | |
| Same place | Paired secret |
sAERO allocator: ranked gauges, best split, positions read in the browser, allocate and return-to-idle from your wallet
Fee pace measured from on-chain releases, with weight snapshots, power flow, steadiness, new-incentive flags and a 90-day daily record
Paid x402 endpoints for agents (v1/position, v1/allocate-plan, v1/cross-chain-plan), /llms.txt and /openapi.json, listed in the x402 Bazaar
Two agent skills: re-allocate a position only when it is worth it, and check or prepare a veAERO to sAERO upgrade (read-only, irreversible, verified against Aero's contracts)
A gauge whose fee pace is a burst is marked spiky and its APR shown as a range
Per-position wait explanation, calendar reminder, earned-fees read, Autopilot-key handling, and what staying costs per day
Allocating a position across chains (best split or your own percentages), returning power, moving it between chains and picking gauges inside a chain, each step simulated first; Arc is a seventh chain
A paid cross-chain plan for agents (v1/cross-chain-plan)
Claiming rewards: not built, because Aero's claim is callable only by a position's operator or Aero's orchestrator
A move-or-stay backtest: prototyped and dropped, the record was too short and fees too lumpy; retry with more of the daily record
Figures are estimates from recent onchain fee releases, not forecasts or financial advice. Always review a transaction in your wallet before signing it.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| pool | Yes | Pool (lp) address | |
| epochs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses ordering and the in-progress epoch, but does not mention read-only nature, authentication requirements, or rate limits. For a read-only historical tool, this is adequate but not comprehensive.
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?
A single, well-structured sentence that front-loads the purpose and includes all key details without waste.
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 description is sufficient for a simple tool with two parameters and no output schema. It explains what data is returned and ordering, though it could mention that it returns rows or a list.
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 covers 50% of parameters (pool with description). The description adds context that pool refers to 'one Aerodrome pool', but does not add meaning for the 'epochs' parameter beyond schema constraints. Baseline 3 is appropriate.
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 clearly states it provides per-epoch history for one Aerodrome pool, listing specific data types (votes, AERO emissions, trading fees, bribes/incentives) and ordering (newest first). This distinguishes it from sibling tools that focus on predictions, allocation, or scanning.
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 when to use (when historical pool data is needed) but does not explicitly state when not to use or mention alternatives. However, the context of sibling tools makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max pools to return | |
| sortBy | No | predicted_fees | |
| refresh | No | Force a fresh onchain snapshot |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses data caching (~5 min) and mentions the key output field. However, it does not state whether the tool is read-only, permissions needed, or potential side effects. It provides moderate transparency.
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?
Two sentences with precise language. No redundant words. Purpose is stated upfront, followed by key output explanation and caching note.
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 description adequately explains what the tool does and the main output for a 3-parameter tool with no output schema. It could benefit from a brief note on return structure or error conditions, but overall it's sufficient for agent understanding.
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 description coverage is 67% (limit and refresh have descriptions, sortBy lacks description but enum values are self-explanatory). The description adds minimal extra parameter meaning beyond schema, mostly contextualizing the output rather than parameters.
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 clearly states the action ('Forecast... and compare') and resource ('top Aerodrome pools'). It distinguishes from siblings (pool_history, recommend_allocation, etc.) by specifying it's about next-epoch demand vs current allocation.
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 explains the key output (predictiveEdgePct) and its interpretation (positive edge = under-incentivized), giving context for when to use. It implicitly suggests this tool for identifying under-incentivized pools, but lacks explicit when-not-to-use or alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It states the tool reports status (read-only) but does not explicitly confirm it has no side effects or require special permissions. The behavior is implied but not fully transparent.
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 sentence that is front-loaded and free of unnecessary words. It efficiently communicates the tool's purpose without redundancy, earning a high score for conciseness.
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?
Given the tool's simplicity (zero parameters, no output schema, no nested objects), the description provides sufficient context. It describes the tool's function and the specific mechanism it belongs to, making it complete for an agent to understand its utility.
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?
The input schema has zero parameters and 100% coverage, so the description's role is to explain what information the tool returns. It adds meaning beyond the schema by specifying that it reports whether 'live contracts are wired into this server', which clarifies the output's semantic content.
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 clearly states that the tool reports the status of the direct Predictive Allocation submission path, specifically whether live contracts are wired into the server. It distinguishes from sibling tools (e.g., pool_history, recommend_allocation) by being a status check rather than a data query or action tool.
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?
No explicit when-to-use guidance is given. The description implies it should be used to check system connectivity, but it does not specify when this is preferable to alternatives or mention prerequisites. This is acceptable for a simple read-only tool, but could be more helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| veNftId | Yes | veAERO NFT token id that holds the voting power | |
| allocations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full burden. It discloses the tool does not sign transactions and returns data for external signing, and notes voting constraints. This adequately discloses behavioral traits beyond basic purpose.
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?
Two sentences plus a note. Front-loads the action and output format, then adds constraints. Every sentence is informative with no wasted words.
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?
Covers input, output, usage constraints, and the tool's role in a broader signing flow. No output schema exists, but description explains return values. Sibling tool names confirm differentiation. Complete for decision-making.
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 50% (veNftId has description, allocations does not). Description adds meaning by summarizing parameters as 'veAERO NFT id + pool weights', clarifying the allocation structure. It doesn't detail constraints like maxItems, but the schema covers those.
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?
Description clearly states the tool builds unsigned calldata for a specific function (Aerodrome Voter.vote()), specifying verb, resource, and input. Sibling tools are about prediction and scanning, so this tool's distinct purpose is evident.
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?
Description implies usage context for voting calldata preparation, and includes important constraints (once per epoch, not final hour). It does not explicitly contrast with siblings, but the context is clear enough given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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%.
| Name | Required | Description | Default |
|---|---|---|---|
| refresh | No | ||
| maxPools | No | ||
| objective | No | voter_roi |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns weights summing to 100% and mentions a 25% concentration cap for voter_roi. However, it does not state whether the tool is read-only, whether it requires authentication, or any side effects. The refresh parameter is not explained, which is a gap for behavioral understanding.
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 two sentences long, front-loading the purpose and then detailing the objectives. Every sentence adds value, and there is no redundant or extraneous information. It is optimally concise for the information provided.
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?
Given 3 parameters, no annotations, and no output schema, the description is moderately complete. It explains the output (weights summing to 100%), covers the two modes, and mentions the concentration cap. However, it lacks explanation for refresh and maxPools, and does not detail the return format beyond the sum constraint. Additional context on these gaps would improve completeness.
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 description coverage is 0%, so the description must compensate. It explains the objective parameter in detail (the two enum values and their behaviors), but does not explain the refresh boolean or maxPools integer parameters. For a 3-parameter tool, covering only one well is partial but the most critical parameter is covered, so a middle score is appropriate.
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 clearly states that the tool produces concrete incentive-allocation recommendations across Aerodrome pools, and explains the two possible objectives. This distinguishes it from sibling tools like pool_history (historical data) and predict_demand (demand prediction), making its purpose unambiguous.
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 explains the two objectives (protocol_efficiency and voter_roi) and their behaviors, providing some guidance on which to choose. However, it does not explicitly state when to use this tool over siblings or provide exclusions/alternatives. The guidance is implicit in the objective descriptions but lacks completeness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max pools to return | |
| minTvlUsd | No | Minimum pool TVL in USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It describes the tool as scanning for live data and sorting by staked TVL. It does not explicitly state read-only nature or any side effects, but the verb 'scan' implies a read operation. The description adds value over no description but lacks explicit behavioral guarantees.
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 two sentences long with no wasted words. It front-loads the core action and output fields, then provides usage guidance. Every sentence adds value.
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?
Given the tool has no output schema, the description lists the main return fields (live TVL, staked TVL, fee tier, emissions) and states the sort order. It also mentions the platform (Aerodrome on Base) and ties to sibling tools implicitly. A minor gap is not describing each field in detail, but for a scan tool this is sufficient.
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 description coverage is 100%, meaning the input schema already documents parameters (limit, minTvlUsd) with descriptions and defaults. The tool description does not add additional meaning to these parameters beyond what is in the schema, so baseline score of 3 is appropriate.
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 clearly states the action ('Scan'), the resource ('Aerodrome (Base) gauge-enabled pools'), and the returned fields (live TVL, staked TVL, fee tier, emissions). It distinguishes itself from siblings by positioning as a market overview tool before predicting demand.
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 gives explicit usage context: 'Use this for a market overview before predicting demand.' This implies it is a preliminary step to predictive tools like predict_demand. It does not specify when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0pool_historypredict_demandpredictive_allocation_statusprepare_vote_calldatarecommend_allocationscan_poolsScored 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.
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
23-in-1 MCP server: EVM tx simulator, funding rate arb, macro radar, swap calldata & security.
MCP server for Boson Protocol — on-chain agentic commerce for physical & digital goods.
Official Aave MCP for V3 and V4 markets, positions, governance, and transaction preparation.
