MCP 服务器，用于预测 Aerodrome（Base）或 Velodrome（Optimism）池的下一周期需求，并将其转化为具体的激励分配建议——专为 Aerodrome 的预测性分配时代（2026 年 9 月，从原定的 7 月目标推迟）而构建，在该时代，激励将跟随预测的未来需求，而非上周的投票。Aerodrome 为默认协议；参见多协议进行切换。
任何支持 MCP 的代理（Claude Code、Claude Desktop、Bankr 托管的代理）都可以使用它来回答：
哪些池将在下一周期产生最多的费用？
投票份额在哪些地方与预测需求定价错位（即“预测优势”）？
我现在应该如何分配我的 veAERO 投票 / 激励预算？
所有数据均实时来自 Base——Aerodrome Sugar 合约提供池状态和逐周期历史，DefiLlama 提供 USD 定价。无需 API 密钥。
工具 | 功能 |
| 支持 gauge 的池，含实时 TVL、质押 TVL、费用层级 |
| 单个池的逐周期投票、排放量、费用（USD）、贿赂（USD） |
| 每个池的下一周期费用预测 + predictiveEdgePct（预测需求份额 − 当前投票份额） |
| 加权分配： |
| 面向花费贿赂预算的团队/协议（而非投票者）：估算每个池可拉动的投票份额，以及谁会被稀释 |
| 面向决定质押流动性的 LP：每个池的前瞻性 AERO 排放 APR（而非费用收入——见下文） |
| 根据分配生成未签名的 |
| 为直接提交预测性分配生成未签名 calldata（一旦接入）——参见 预测性分配适配器 |
| 直接预测性分配提交是否已接通 |
| 需求预测与已实现费用及朴素基线的前向验证准确性——参见 预测准确性 |
此服务器绝不持有密钥或签署任何东西。 执行是宿主代理的工作，且需在用户明确批准之后进行。
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 合约模式——因此一个引擎即可覆盖两者。单个服务器进程服务一种协议，在启动时选择：
{
"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 在运行 Velodrome 时正确报告该机制不适用，因为 Dromos Labs 的公告仅针对 Aerodrome。
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 dev打开 http://localhost:3000——热门池表格（预测费用、优势、置信度），以及交互式 Voter ROI（输入你的 veAERO）和协议效率分配面板。首次加载会构建 链上快照（约 1 分钟），之后缓存。
连接钱包（注入式或 Coinbase Wallet，Base 链）即可将 Voter 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 排名前 N，且高于 TVL 下限）：
从 RewardsSugar.epochsByAddress 拉取最多 8 个每周周期的历史——投票、排放量、费用、每周期激励——并将所有内容以 USD 计价。
当进行中的周期已过去超过 20% 时，将其外推至完整长度（最新的需求信号）。
预测下一周期费用 = EWMA（α=0.45）+ ½ × 线性趋势，下限为 0。置信度得分来自历史深度和方差。
predictiveEdge = 预测费用需求占比 − 当前投票占比。正优势 → 激励不足的池：这正是预测市场分配器应奖励的对象。
两种分配目标：
protocol_efficiency — 权重 ∝ 预测需求占比。这是预测性分配的理想状态；适用于指导激励的国库/协议，以及在该机制上线后对其进行基准测试。
voter_roi — 在给定 veAERO 数量（votingPowerVe）下最大化你的预期下一周期奖励。每个池按比例支付（R·v/(E+v)），因此优化器会水灌投票以均衡边际回报——具有高名义 ROI 但奖励容量不足的零散池自然获得很少或零投票（外加 $500 的硬性容量下限）。输出包括每个池在自我稀释后的预期 USD 奖励。
recommend_bribe_placement 为花费贿赂预算的团队/协议（而非投票者）反转了这一逻辑：它在市场整个活跃投票权上重新运行相同的水灌算法，分别计算有和没有将贿赂添加到某个池的支付中的情况，并报告投票份额变化。投票按 ∝ √支付水灌，因此一美元贿赂在廉价池上比在已大型池上能拉动更多份额。这模拟了即时、无摩擦、全市场的重新分配，因此这是一个理论上限，而非预测——适用于比较候选池，而非预测字面投票数。
recommend_lp_deposit 面向第三类受众——决定在何处存入和质押流动性的 LP——并且刻意不按 predictedFeesUsd 排名。在 Aerodrome 上，交易费用（和贿赂）归属于 veAERO 投票者，而非流动性质押者；质押者则按质押 TVL 比例获得 AERO 排放。因此该工具使用与 predict_demand 相同的 EWMA+趋势模型，从每个池的排放历史预测下一周期排放量，并将结果按当前质押 TVL 年化，得到 predictedNextEpochAprPct。它还报告 currentEpochAprPct，这完全不需要预测——当前周期的排放率在周期开始前就已由投票固定，因此直接读取而非预测。
每个预测上的 confidence 最初是启发式（历史深度 + 方差），然后在到达任何工具输出之前，根据真实回测准确性重新校准——见 置信度校准 下文。backtest_summary（工具）和 npm run backtest（脚本）提供完整验证。
方法：对每个池的已完成周期历史进行前向遍历。在每个历史周期边界，仅使用当时实际可用的周期（上限为 predict_demand 使用的相同滑动窗口——回测绝不会给模型比实时更多的历史）来预测该周期，然后与实际结果进行比较。误差以 MAE、RMSE 和 WAPE（Σ|误差| / Σ实际值，对 MAPE 无法处理的近零费用周期具有鲁棒性）报告，同时报告相对基线的技能——与朴素“预测下一周期 = 上一周期”模型的相同比较，因此负技能值意味着 EWMA+趋势预测在复杂度上并未优于什么都不做。置信度校准表检查更高置信度的预测是否确实具有更低误差。一个已知缺口：此回测仅重放周期边界预测——它不重放用于实时进行中周期的周期中速度外推混合。
启发式置信度（depthScore × stabilityScore）是对预测可信度的猜测——它从未见过真实结果。deriveConfidenceCalibration 将每个前向回测点按其原始启发式置信度分桶，计算每个桶内实际实现的 WAPE，并将其转换为 calibratedConfidence = 1/(1+wape)（与启发式自身方差项使用的函数形式相同）。predict_demand、recommend_allocation 和 recommend_bribe_placement 随后通过 applyConfidenceCalibration 将每个实时预测的置信度重新映射到该曲线上——因此，启发式认为看起来可靠但实际噪声较大的置信度范围会被下调，反之亦然。这不仅仅影响显示：置信度直接加权 voter_roi 的奖励估计，并门控 recommend_bribe_placement 的候选池，因此校准不当的分数会悄悄使两者产生偏差。
样本少于 8 个回测点的桶会被丢弃而非信任，任何原始置信度落在被丢弃（或尚未计算）范围内的预测都会保留其启发式分数——校准是在始终可用的启发式之上的机会性增强，而非硬性依赖。如果过去一小时内尚未运行过新的 backtest_summary，相关工具会与市场快照同时获取一个（并发，因此不会增加等待时间），并在获取失败时回退到原始启发式。
运行 npm run backtest 获取控制台报告，或从任何连接的代理调用 backtest_summary 获取实时数据（缓存约 1 小时；AERO_BACKTEST_EPOCHS / AERO_BACKTEST_MAX_POOLS 调整深度/广度）。
Dromos Labs 已宣布该机制，但尚未发布合约/ABI（截至 2026-08-16；启动已从 7 月推迟到 2026 年 9 月）。所有机制特定内容都位于 src/adapters/predictive-allocation.ts 的一个接口后面，并且完全由配置驱动——启动日无需代码更改，只需在 Dromos 发布地址和 ABI 后设置环境变量即可。
Var | Example | 描述 |
|
| 机制的合约地址 |
|
| 人类可读的 ABI（JSON 数组），单个函数 |
|
| 要调用的函数名称 |
|
| 位置参数角色 — 支持： |
设置全部四个后，prepare_submission 会构建真实的 calldata；predictive_allocation_status 报告 live: true。在此之前，prepare_submission 会以明确的"尚未发布"错误失败，而 prepare_vote_calldata 则针对经典的 Voter.vote() 流程，该流程目前可用。
Var | 默认值 | 描述 |
|
|
|
| 协议默认值 | 专用 RPC，任一协议 — 设置后始终优先 |
|
|
|
|
| 候选池 TVL 下限 |
|
| 接收完整周期历史分析的池 |
|
| 每个池为 |
|
| 每次默认 |
均来自 velodrome-finance/sugar 的 deployments/{base,optimism}.env；奖励代币地址已与 DefiLlama + CoinGecko 交叉核对。
Aerodrome（Base，8453） | Velodrome（Optimism，10） | |
LpSugar |
|
|
RewardsSugar |
|
|
VeSugar |
|
|
Voter |
|
|
奖励代币（AERO/VELO） |
|
|
预测分配适配器已配置驱动并准备就绪 — 连接真实合约只需更改环境变量（prepare_submission）
社交/关注度信号（Farcaster 提及、代币上线）作为预测特征
回测工具：重放历史周期，对比预测与实际费用评分，发布准确率（backtest_summary、npm run backtest）
x402 变现托管端点（通过 Bankr 以 USDC 按次付费预测）
"预测热门池"仪表盘（web/）
钱包连接 + 从仪表盘一键投票（wagmi）
多协议：Velodrome（Optimism）与 Aerodrome（Base）并行，通过 AERO_PROTOCOL 选择
仪表盘（web/）多协议支持（目前仅 Aerodrome/Base）
预测是基于链上历史的统计外推，不构成财务建议。签署前请务必审查 calldata。
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.
