AlphaPipeline Agent MCP

dex.liquidity_slippage

Read-only

Use this tool to calculate expected DEX price slippage, pool liquidity depth, and optimal routing before executing an on-chain token swap. GeckoTerminal-backed pool analytics with constant-product slippage estimation for the requested trade_size_usd, plus a slippage_tiers array with the same estimate at fixed $1,000/$5,000/$10,000 sizes so an agent can gauge depth at a glance without extra calls. Do not use for centralized exchange (CEX) orderbooks or contract risk analysis. Paid in USDC on Base.

Input Schema

TableJSON Schema

Name	Required	Description
`network`	No	GeckoTerminal network id, e.g. base, eth. Defaults to base.
`pool_address`	No	Specific DEX pool contract address (optional if token_address is given).
`token_address`	No	Token contract address - the most liquid pool is auto-selected (optional if pool_address is given).
`trade_size_usd`	Yes	Hypothetical trade size in USD to estimate slippage for.

Output Schema

TableJSON Schema

Name	Required	Description
`notice`	No
`network`	Yes
`pool_name`	No
`data_source`	Yes
`generated_at`	Yes
`pool_address`	No
`pool_fee_pct`	No	Swap fee tier of the selected pool, parsed from pool_name. Disclosed for reference only - not subtracted from the slippage estimate.
`liquidity_usd`	No
`token_address`	No
`slippage_tiers`	No
`trade_size_usd`	Yes
`volume_24h_usd`	No
`price_impact_model`	Yes
`quote_token_symbol`	No	Parsed from pool_name (e.g. 'USDC' from 'WETH / USDC 0.05%').
`assumed_gas_cost_usd`	No	Flat per-swap gas estimate for this network, not a live gas quote.
`estimated_slippage_pct`	No
`quote_token_is_stablecoin`	No	If false or null, this pool isn't USD-quoted - an extra hop is needed to reach USD, not accounted for in the slippage estimate.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 18, 2026

addedOutput schema / properties / assumed_gas_cost_usd

Added value: +{
+  "description": "Flat per-swap gas estimate for this network, not a live gas quote.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / pool_fee_pct

Added value: +{
+  "description": "Swap fee tier of the selected pool, parsed from pool_name. Disclosed for reference only - not subtracted from the slippage estimate.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / quote_token_is_stablecoin

Added value: +{
+  "description": "If false or null, this pool isn't USD-quoted - an extra hop is needed to reach USD, not accounted for in the slippage estimate.",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}

addedOutput schema / properties / quote_token_symbol

Added value: +{
+  "description": "Parsed from pool_name (e.g. 'USDC' from 'WETH / USDC 0.05%').",
+  "type": [
+    "string",
+    "null"
+  ]
+}

AddedSep 8, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is a safe read operation. The description adds valuable behavioral context: it's GeckoTerminal-backed, uses constant-product slippage estimation, and includes a slippage_tiers array for quick depth assessment without extra calls. It also mentions the payment requirement. This exceeds the baseline set by annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. The first sentence states the core purpose, and the second adds key details (GeckoTerminal-backed, slippage tiers, exclusions, payment) in a compact manner. It is front-loaded and each clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The presence of an output schema covers return values, and the description explicitly mentions the slippage_tiers output array. It also notes the cost and exclusions. It does not mention network defaults or how pool/token selection works, but those are covered in the schema. For a tool with multiple parameters and a clear purpose, this is nearly complete, missing only minor edge-case details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters are fully documented in the schema. The description does not add any parameter-specific semantics beyond referencing trade_size_usd in the main text. Per the rubric, a baseline of 3 is correct when the schema carries the full parameter documentation burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool calculates DEX price slippage, pool liquidity depth, and optimal routing, naming the specific resource (GeckoTerminal-backed pool analytics) and action. It differentiates from CEX tools by explicitly saying 'Do not use for centralized exchange (CEX) orderbooks,' which distinguishes it from any potential sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit when-to-use guidance ('before executing an on-chain token swap') and explicit exclusions ('Do not use for centralized exchange (CEX) orderbooks or contract risk analysis'). It also notes a cost implication ('Paid in USDC on Base'), which helps agents decide whether to invoke it. This is strong usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All AlphaPipeline Agent MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?