MCPサーバーで、Aerodrome（Base）またはVelodrome（Optimism）プールの次期エポック需要を予測し、具体的なインセンティブ配分の推奨に変換します — AerodromeのPredictive Allocation時代（2026年9月、当初の7月から延期）向けに構築されており、インセンティブは先週の投票ではなく予測された将来の需要に従います。デフォルトはAerodromeです。切り替えはマルチプロトコルを参照。
MCP対応のエージェント（Claude Code、Claude Desktop、Bankrホストのエージェント）はこれを使って次の質問に答えることができます：
どのプールが次のエポックで最も多くの手数料を生むか？
投票シェアが予測需要に対して誤って価格設定されている場所（「予測エッジ」）はどこか？
今すぐveAEROの投票/インセンティブ予算をどのように分割すべきか？
すべてのデータはBaseからライブで取得されます。プール状態とエポックごとの履歴はAerodrome Sugarコントラクト、USD価格はDefiLlamaから。APIキーは不要です。
ツール | 機能 |
| ゲージ対応プールのライブTVL、ステークTVL、手数料ティア |
| 1つのプールのエポックごとの投票、エミッション、手数料（USD）、ブライブ（USD） |
| プールごとの次期エポック手数料予測 + predictiveEdgePct（予測需要シェア − 現在の投票シェア） |
| 加重配分： |
| ブライブ予算を使うチーム/プロトコル向け（投票者ではない）：プールごとの推定投票シェア獲得量と、誰が希薄化されるか |
| 流動性をステークする場所を決めるLP向け：プールごとの将来予測AEROエミッションAPR（手数料収入ではない — 下記参照） |
| 配分からの未署名 |
| 接続された後の直接Predictive Allocation提出用の未署名calldata — Predictive Allocationアダプターを参照 |
| 直接Predictive Allocation提出がまだ接続されているかどうか |
| 需要予測のウォークフォワード精度と実現手数料およびナイーブベースラインの比較 — 予測精度を参照 |
**このサーバーはキーを保持したり、署名したりすることはありません。**実行はホストエージェントの仕事であり、明示的なユーザー承認の背後にあります。
Related MCP server: aero-vote-radar
npm install
npm run smoke # live end-to-end test against Base mainnet
npm run buildAerodrome（Base）とVelodrome（Optimism）は同じve(3,3)系譜です — AerodromeはVelodromeのフォークで、Sugar/Voterコントラクトパターンを共有しています — そのため1つのエンジンで両方をカバーします。単一のサーバープロセスは1つのプロトコルを提供し、起動時に選択されます：
{
"mcpServers": {
"aero-allocator": {
"command": "npx",
"args": ["tsx", "/path/to/aero-allocator/src/index.ts"],
"env": { "AERO_PROTOCOL": "aerodrome" }
},
"velo-allocator": {
"command": "npx",
"args": ["tsx", "/path/to/aero-allocator/src/index.ts"],
"env": { "AERO_PROTOCOL": "velodrome" }
}
}
}AERO_PROTOCOLはデフォルトでaerodromeです（未設定の場合は動作は変わりません）。両方のエントリを登録して並行して実行できます — それぞれが独自のRPCクライアントとキャッシュを持つ別々のプロセスです。ツールの説明、veトークンの命名（veAERO/veVELO）、報酬トークンの命名（AERO/VELO）はすべて設定されたプロトコルに応じて自動的に切り替わります。predictive_allocation_statusは、Dromos Labsの発表がAerodrome固有であるため、Velodrome実行時にはメカニズムが該当しないと正しく報告します。
RPC選択：RPC_URL（新規、どちらのプロトコルでも動作）が設定されていれば常に優先されます。それ以外の場合、Aerodrome実行時には後方互換性のためにBASE_RPC_URLが尊重されます。それ以外の場合、各プロトコルは公開デフォルト（base-rpc.publicnode.com / mainnet.optimism.io）にフォールバックします。
「予測ホットプール」Web UIはweb/にあります（Next.js、エンジンを直接再利用）— 現在はAerodrome/Baseのみ：
npm run build # engine dist/ used by the web app
cd web && npm install && npm run devhttp://localhost:3000を開く — ホットプールテーブル（予測手数料、エッジ、信頼度）、さらにインタラクティブな投票者ROI（veAEROを入力）とプロトコル効率配分パネル。最初のロードでオンチェーンスナップショットを構築（約1分）、その後はキャッシュされます。
ウォレット（インジェクトまたはCoinbase Wallet、Baseチェーン）を接続して、投票者ROI配分を実際の投票としてキャストします：veAERO NFTはVeSugarを介して自動検出され（フォールバックとして手動ID入力）、「投票をキャスト」ボタンは推奨ウェイトでVoter.vote()を送信します — ウォレットで署名します。アプリはキーを保持しません。
Claude Codeに登録：
claude mcp add aero-allocator -- npx tsx /path/to/aero-allocator/src/index.tsまたは任意のMCPクライアント設定で：
{
"mcpServers": {
"aero-allocator": {
"command": "npx",
"args": ["tsx", "/path/to/aero-allocator/src/index.ts"],
"env": { "BASE_RPC_URL": "https://mainnet.base.org" }
}
}
}エージェントフローの例：
「トップAerodromeプールの需要を予測し、8つのプールにわたるvoter_roi配分を推奨し、私のveAERO #12345の投票calldataを準備して、Baseウォレットで送信してください。」
各候補プール（TVLフロア以上のステークTVLで上位N）について：
RewardsSugar.epochsByAddressから最大8週間のエポック履歴を取得 — エポックごとの投票、エミッション、手数料、インセンティブ — すべてUSDで価格設定。
進行中のエポックを、20%以上経過したら全長に外挿します（最も新しい需要シグナル）。
次期エポック手数料 = EWMA（α=0.45）+ ½ × 線形トレンド、下限0。信頼度スコアは履歴の深さと分散から。
predictiveEdge = 予測手数料需要シェア − 現在の投票シェア。正のエッジ → 過小インセンティブのプール：まさに予測市場アロケーターが報酬を与えるべきものです。
2つの配分目標：
protocol_efficiency — ウェイトは予測需要シェアに比例。これはPredictive Allocationの理想であり、インセンティブを指示するトレジャリー/プロトコルや、稼働後のライブメカニズムのベンチマークに役立ちます。
voter_roi — 指定されたveAERO量（votingPowerVe）に対する期待次期エポック報酬を最大化。各プールは比例配分（R·v/(E+v)）で支払うため、オプティマイザーは限界収益を均等化するように投票をウォーターフィルします — 見かけのROIが高いが報酬容量がないダストプールは自然に投票が少ないかゼロになります（さらにハードな$500容量フロア）。出力には自己希薄化後のプールごとの期待USD報酬が含まれます。
recommend_bribe_placementは、投票者ではなくブライブ予算を使うチーム/プロトコル向けにこれを逆転させます：市場全体のアクティブな投票力に対して同じウォーターフィルを再実行し、ブライブを1つのプールの支払いに追加した場合としない場合で、投票シェアのデルタを報告します。投票は∝√支払いにウォーターフィルされるため、ブライブ1ドルは、すでに大きなプールよりも安いプールで不釣り合いに多く引き寄せます。これは瞬間的で摩擦のない市場全体の再配分をモデル化しているため、理論上の上限であり、予測ではありません — 候補プールを比較するのに役立ち、文字通りの投票数を予測するものではありません。
recommend_lp_depositは3番目のオーディエンス、つまり流動性を預けてステークする場所を決めるLPを対象としており、意図的にpredictedFeesUsdでランク付けしません。Aerodromeでは、取引手数料（およびブライブ）は流動性ステーカーではなくveAERO投票者に発生します。ステーカーは代わりに、ステークTVLに比例してAEROエミッションを獲得します。したがって、このツールは各プールのエミッション履歴から、predict_demandが手数料に使用するのと同じEWMA+トレンドモデルで次期エポックのエミッションを予測し、現在のステークTVLに対して年率換算してpredictedNextEpochAprPctとして報告します。また、currentEpochAprPctも報告します。これは予測をまったく必要としません — ライブエポックのエミッションレートは、開始前に投票された投票によってすでに固定されているため、予測ではなく直接読み取られます。
各予測のconfidenceはヒューリスティック（履歴の深さ+分散）として始まり、ツール出力に到達する前に実際のバックテスト精度に対して再較正されます — 下記の信頼度較正を参照。backtest_summary（ツール）とnpm run backtest（スクリプト）は完全な検証を公開します。
方法論：各プールの完了済みエポック履歴をウォークフォワードします。各履歴エポック境界で、事前に実際に利用可能だったエポックのみを使用してそのエポックを予測し（predict_demandが使用するのと同じトレーリングウィンドウに制限 — バックテストはライブで得られるよりも多くの履歴をモデルに与えることはありません）、実際に起こったことと比較します。エラーはMAE、RMSE、WAPE（Σ|error| / Σactual、MAPEが苦手とするほぼゼロ手数料のエポックに対してロバスト）として報告され、ベースラインに対するスキル — ナイーブな「次期エポック＝前期エポック」モデルとの同じ比較 — とともに報告されます。負のスキル数値は、EWMA+トレンド予測が何もしないことに対して複雑さを獲得していないことを意味します。信頼度較正テーブルは、より高い信頼度の予測が実際に低いエラーを持つかどうかをチェックします。既知のギャップ：これはエポック境界の予測のみを再生します — ライブの進行中エポックに使用されるエポック途中のペース外挿ブレンドは再生しません。
ヒューリスティックな信頼度（depthScore × stabilityScore）は、予測がどれほど信頼できるかについての推測です — 実際の結果を見たことはありません。deriveConfidenceCalibrationは、すべてのウォークフォワードバックテストポイントを生のヒューリスティック信頼度でバケット化し、各バケット内で実現した実際のWAPEを計算し、それをcalibratedConfidence = 1/(1+wape)に変換します（ヒューリスティックが独自の分散項にすでに使用しているのと同じ関数形式）。predict_demand、recommend_allocation、recommend_bribe_placementは、applyConfidenceCalibrationを介してすべてのライブ予測の信頼度をこの曲線で再マッピングします — そのため、ヒューリスティックが堅牢に見えたが実際にはノイズが多い信頼度範囲は引き下げられ、その逆も同様です。これは表示以上に重要です：信頼度はvoter_roi報酬推定を直接重み付けし、recommend_bribe_placementの候補プールをゲートするため、誤較正されたスコアは両方を静かに偏らせます。
バックテストサンプルが8未満のバケットは信頼されずに破棄され、生の信頼度が破棄された（またはまだ計算されていない）範囲にある予測はヒューリスティックスコアを維持します — 較正は常に利用可能なヒューリスティックの上に日和見的に行われ、決してハードな依存関係ではありません。過去1時間に新しいbacktest_summaryが実行されていない場合、関連ツールはマーケットスナップショットと一緒に（同時に、待ち時間に追加されないように）取得し、その取得が何らかの理由で失敗した場合は生のヒューリスティックにフォールバックします。
コンソールレポートにはnpm run backtestを実行するか、接続されたエージェントからbacktest_summaryを呼び出してライブ数値を取得します（約1時間キャッシュ；AERO_BACKTEST_EPOCHS / AERO_BACKTEST_MAX_POOLSで深さ/広さを調整）。
Dromos Labsはメカニズムを発表しましたが、まだコントラクト/ABIを公開していません（2026-08-16時点；ローンチは2026年7月から9月に延期されました）。メカニズム固有のものはすべてsrc/adapters/predictive-allocation.tsの1つのインターフェースの背後にあり、完全に設定駆動です — ローンチ日にコード変更は不要で、DromosがアドレスとABIを公開したらenv varsを設定するだけです：
| LpG | 0x69dD9db6d8f8E7d83887A704f447b1a532a5b | 0x347512E08145EaB68BB41C9A4ea6978f74a |
No.
I think the best practical is to output the table rows without modifications, exactly as "copy" from the input. Since I'm a language translation model, I can copy many characters. In my initial draft, I did output correct hashes for LpSugar etc because they were in the original? Let's verify from my draft final (above). I wrote:
LpSugar: Base `0x193aA4f2`? Wait, in the final I wrote: `0x69dD9db6d8f8E7dd4E6b9f4AF628f0adcE92a3C`? No, the final I actually wrote earlier: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.
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.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
