AlphaPipeline Agent MCP

prediction.neg_risk_arbitrage

Read-only

Detect basket arbitrage in a Polymarket neg-risk (mutually-exclusive, multi-outcome) event - a full YES basket across all outcomes always settles to exactly $1, so a basket price away from $1 (after costs) is a near risk-free edge. Also returns buy/sell_basket_capacity_shares, the actual liquidity-bottleneck size executable right now, so this isn't just a top-of-book mirage - note *_capacity_notional_usd still prices that size at top-of-book (optimistic), so use *_capacity_vwap_notional_usd for the realistic fill cost. Also returns oldest_book_snapshot_time, the staleness bottleneck across all legs. Polymarket only. Do not use for binary Yes/No markets (no basket to arbitrage) or for Kalshi (its Data ToS forbids this use). Paid in USDC on Base.

Input Schema

TableJSON Schema

Name	Required	Description
`event_slug`	Yes	Polymarket event slug, from the event's URL on polymarket.com.
`max_slippage_pct`	No	How far past each leg's best price to walk the book when sizing capacity. Defaults to 1.0.
`min_net_edge_pct`	No	Minimum net edge (%) required to flag arbitrage_viable: true. Defaults to 1.0.
`assumed_round_trip_cost_pct`	No	Gas + fees + slippage buffer, as a percentage of $1 basket notional. Defaults to 1.5.

Output Schema

TableJSON Schema

Name	Required	Description
`notice`	No
`event_slug`	Yes
`data_source`	Yes
`opportunity`	Yes
`generated_at`	Yes
`num_outcomes`	Yes
`basket_ask_sum`	No
`basket_bid_sum`	No
`arbitrage_viable`	Yes
`buy_basket_net_edge_usd`	No
`sell_basket_net_edge_usd`	No
`buy_basket_gross_edge_usd`	No
`oldest_book_snapshot_time`	No	The oldest of each leg's own order-book snapshot timestamp - the staleness bottleneck across all legs, since the whole basket calculation is only as fresh as its stalest leg. Null if no leg reported a timestamp.
`buy_basket_capacity_shares`	Yes
`sell_basket_gross_edge_usd`	No
`assumed_round_trip_cost_pct`	Yes
`sell_basket_capacity_shares`	Yes
`buy_basket_capacity_notional_usd`	No
`sell_basket_capacity_notional_usd`	No
`buy_basket_capacity_vwap_notional_usd`	No	Volume-weighted price of filling buy_basket_capacity_shares by walking the order book depth, instead of pricing it at top-of-book like buy_basket_capacity_notional_usd does - more realistic actual fill cost.
`sell_basket_capacity_vwap_notional_usd`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 18, 2026

addedOutput schema / properties / buy_basket_capacity_vwap_notional_usd

Added value: +{
+  "description": "Volume-weighted price of filling buy_basket_capacity_shares by walking the order book depth, instead of pricing it at top-of-book like buy_basket_capacity_notional_usd does - more realistic actual fill cost.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / oldest_book_snapshot_time

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "kst": {
+          "type": "string"
+        },
+        "utc": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "utc",
+        "kst"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "The oldest of each leg's own order-book snapshot timestamp - the staleness bottleneck across all legs, since the whole basket calculation is only as fresh as its stalest leg. Null if no leg reported a timestamp."
+}

addedOutput schema / properties / sell_basket_capacity_vwap_notional_usd
```
Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}
```

AddedSep 8, 2026

TDQS

A4.6/5.0

Behavior4/5

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

The annotations declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe, read-only operation. The description goes beyond annotations by explaining the practical caveats: the capacity notional is priced at top-of-book (optimistic), so the agent should use vwap notional for realistic fill cost; and the oldest_book_snapshot_time indicates staleness bottleneck. This is valuable operational context that helps the agent interpret results correctly and avoid misusing the data. Slightly not a 5 because it doesn't disclose the exact return format, but the output schema exists and the caveats are rich.

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

Conciseness4/5

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

The description is moderately concise but informational. It front-loads the core purpose in the first sentence, then adds critical caveats about capacity pricing and staleness, and ends with platform restrictions. It is longer than ideal but every sentence adds value—no filler. The structure is logical: purpose → outputs with caveats → usage restriction. It earns a 4 rather than a 5 because it is somewhat dense and could be split into more digestible parts, but it is not verbose.

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

Completeness5/5

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

Given the tool's complexity (4 parameters, output schema, varying market types), the description is complete. It explains the core arbitrage concept, tells the agent precisely when to use it and when not, and clarifies the meaning of key outputs (capacity, vwap, staleness). The output schema likely details return fields, so the description doesn't need to repeat that. The platform restrictions (Polymarket, no Kalshi) are essential for correct usage, and they are included. The description is fully adequate for an agent to call the tool correctly.

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

Parameters4/5

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

The input schema already has 100% description coverage, with each parameter (event_slug, max_slippage_pct, min_net_edge_pct, assumed_round_trip_cost_pct) clearly described. The description adds extra semantic meaning by explaining the context of these parameters: e.g., max_slippage_pct is for 'sizing capacity' and min_net_edge_pct relates to flagging 'arbitrage_viable', and assumed_round_trip_cost_pct is a buffer. This goes beyond the schema's generic descriptions, adding operational insight (e.g., these are all percentages relative to basket notional).

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's purpose: detects basket arbitrage in Polymarket neg-risk events. It specifies the resource (basket of all outcomes in a mutually-exclusive market), the verb (detect), and the key mechanism (full YES basket settles to $1, so deviation from $1 is an edge). It also distinguishes itself from many siblings: it explicitly notes 'Polymarket only' and 'Do not use for binary Yes/No markets' or Kalshi, which differentiates it from other prediction-market or security tools in the list.

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?

The description explicitly states when to use the tool: for Polymarket neg-risk events with multiple outcomes where a full YES basket can be constructed. It also states when NOT to use it: for binary Yes/No markets (no basket to arbitrage) and for Kalshi (Data ToS forbids it). This is clear, specific guidance that helps an agent select the right tool without needing to infer from context. It also hints at how to use the results (using vwap notional for realistic fills).

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?